Quali fattori causano o impediscono la "perdita generazionale" quando i JPEG vengono ricompressi più volte?

Per anni, ho creduto che ricomprimere più volte i file JPEG avrebbe degradato gradualmente la sua qualità fino a quando non fossero un disastro irriconoscibile, come fanno le fotocopie delle fotocopie. Ciò ha un senso intuitivo perché JPEG è un formato con perdita di dati. Ci sono anche altre domande e risposte che affermano che è così:

• Quale qualità dell'immagine viene persa quando si salva nuovamente un'immagine JPEG in MS Paint?

• La semplice apertura e chiusura di un file JPEG riduce la qualità dell'immagine?

Tuttavia, ho anche letto che ricomprimere i JPEG allo stesso livello di qualità non peggiorerà la qualità dell'immagine. Ciò è in contrasto con il graduale degrado descritto altrove.

Cosa succede tecnicamente quando un JPEG viene ricompresso?  Cosa si sta perdendo e come? L'immagine si trasformerà davvero nel disordine innevato che appariva in televisione? Che dire di quei video che mostrano immagini che si sfaldano dopo essere state ricompresse più volte?

(Per favore, non limitatevi a ondeggiare a mano e fare appello al concetto generale di perdita.)

(Questa domanda e le risposte che ha attratto finora si concentrano sui fattori tecnici (impostazioni specifiche e manipolazioni dell'immagine) che causano o impediscono il degrado dell'immagine quando un file JPEG viene ricompresso più volte.)

Quasi tutte le perdite di qualità dell'immagine si verificano la prima volta che un'immagine viene compressa come JPEG. Indipendentemente da quante volte un JPEG viene ricompresso con le stesse impostazioni , le perdite generazionali sono limitate all'errore di arrotondamento.

• I confini dell'MCU rimangono intatti (blocchi 8x8).

• Il sottocampionamento Chroma è disabilitato.

• DQT costante (stessa impostazione di qualità).

Tuttavia, gli errori di arrotondamento possono essere elevati per ogni iterazione in cui i criteri sopra indicati non sono soddisfatti ed è prudente conservare i backup di tutti i file originali.

L'algoritmo di compressione JPEG

1. Converti spazio colore. Se lo si desidera, sottocampionare le informazioni sul colore (campionamento cromatico) (Perdita) . Se non ricampionato, la perdita di informazioni è il risultato di un errore di arrotondamento .

2. Segmentazione. Dividi ogni canale in blocchi 8x8 (MCU = Unità di codifica minima). (Senza perdita di dati)

   Nota: se il sottocampionamento chroma è abilitato, le MCU possono effettivamente essere 16x8, 8x16 o 16x16, in termini di immagine originale. Tuttavia, le MCU sono ancora tutti blocchi 8x8.

3. Trasformazione di coseno discreta (DCT) su ogni MCU. La perdita di informazioni è il risultato di un errore di arrotondamento .

4. Quantizzazione.  Il valore in ciascuna cella dell'MCU è diviso per un numero specificato in una tabella di quantizzazione (DQT). I valori sono arrotondati per difetto, molti dei quali diventano zero. Questa è la parte con perdita principale dell'algoritmo.

5. Scansione a zig-zag. Riorganizzare i valori in ciascuna MCU in una sequenza di numeri seguendo uno schema a zig-zag. Gli zeri che si sono verificati durante la quantizzazione verranno raggruppati insieme. (Senza perdita di dati)

6. DPCM = Modulazione del codice dell'impulso differenziale. Converti le sequenze numeriche in un modulo più facile da comprimere. (Senza perdita di dati)

7. RLE = Esegui codifica lunghezza. Gli zeri consecutivi sono compressi. (Senza perdita di dati)

8. Entropia / Huffman Coding. (Senza perdita di dati)

Ricompressione di JPEG

Si noti che il downsampling dei canali di colore e la quantizzazione sono gli unici passaggi intenzionalmente con perdita di dati . Mettendo da parte l'errore di arrotondamento per ora, tutti gli altri passaggi sono senza perdita. Una volta avvenuta la quantizzazione, l'inversione e la ripetizione del passaggio danno risultati identici. In altre parole, la riquantizzazione (con lo stesso DQT) è senza perdita .

In linea di principio, è possibile creare un algoritmo di ricampionamento privo di perdite dopo il primo passaggio. Tuttavia, con l'implementazione in ImageMagick, i colori possono cambiare drasticamente prima che venga raggiunto lo stato stazionario, come si vede nell'immagine.

Date le condizioni ottimali, ricomprimere un JPEG con le stesse impostazioni di qualità comporterebbe esattamente lo stesso JPEG. In altre parole, ricomprimere JPEG è potenzialmente senza perdita di dati . In pratica, la ricompressione dei file JPEG non è senza perdita, ma soggetta e limitata da un errore di arrotondamento. Sebbene gli errori di arrotondamento spesso alla fine convergano a zero , in modo da ricreare la stessa identica immagine, il sottocampionamento di Chroma può comportare cambiamenti di colore significativi.

Dimostrazione (stessa impostazione di qualità)

Ho scritto il seguente bashscript, che utilizza ImageMagick per ricomprimere ripetutamente un file JPEG con una determinata impostazione di qualità:

#!/usr/bin/env bash
n=10001; q1=90
convert original.png -sampling-factor 4:4:4 -quality ${q1} ${n}.jpg

while true ; do
   q2=${q1}            # for variants, such as adding randomness
   convert ${n}.jpg -quality ${q2} $((n+1)).jpg
   #\rm $((n-5)).jpg   # uncomment to avoid running out of space
   n=$((n+1))

   echo -n "$q2  "
   md5sum ${n}.jpg
done

Dopo averlo lasciato funzionare per alcune centinaia di iterazioni, ho eseguito md5sumi risultati:

d9c0d55ee5c8b5408f7e50f8ebc1010e  original.jpg

880db8f146db87d293def674c6845007  10316.jpg
880db8f146db87d293def674c6845007  10317.jpg
880db8f146db87d293def674c6845007  10318.jpg
880db8f146db87d293def674c6845007  10319.jpg
880db8f146db87d293def674c6845007  10320.jpg

Possiamo vedere che, in effetti, l'errore di arrotondamento è converto a zero e la stessa immagine viene riprodotta, ancora e ancora .

L'ho ripetuto più volte con immagini e impostazioni di qualità diverse. Di solito, viene raggiunto lo stato stazionario e la stessa immagine esatta viene riprodotta ripetutamente.

Che dire dei risultati di @ mattdm ?

Ho provato a replicare i risultati di mattdm usando Imagemagick su Ubuntu 18.04. L'originale era una conversione grezza in TIFF in Rawtherapee, ma sembra non essere più disponibile. Al suo posto, ho preso la versione ingrandita e l'ho ridotta alla sua dimensione originale (256x256). Poi ho ripetutamente ricompresso a 75 finché non ho ottenuto la convergenza. Ecco il risultato (originale, 1, n, differenza):

I miei risultati sono diversi. Senza il vero originale, la ragione della differenza è impossibile da determinare.

Che dire del montaggio di @ ths ?

Ho ricompresso l'immagine dall'angolo in alto a sinistra del montaggio fino alla convergenza a 90. Questo è il risultato (originale, 1, n, differenza):

Dopo aver abilitato il sottocampionamento cromatico, i colori cambiano quando viene raggiunto lo stato stabile.

Modifica tra un numero limitato di impostazioni

Modificando la variabile q2, l'impostazione della qualità può essere limitata a un insieme di valori distribuiti uniformemente.

q2=$(( (RANDOM % 3)*5  + 70 ))

Per un numero limitato di opzioni di impostazione, alla fine può essere raggiunto l'equilibrio , che si vede quando i valori md5 iniziano a ricorrere. Sembra che più grande è l'insieme, più tempo impiega e peggiore diventa l'immagine, prima di raggiungere l'equilibrio.

Ciò che sembra accadere all'equilibrio è che il coefficiente DCT prima della quantizzazione deve essere divisibile per tutti (o la maggior parte) dei valori quantistici. Ad esempio, se si passa tra due DQT in cui il coefficiente DCT è diviso alternativamente per 3 e 5, l'equilibrio sarà raggiunto quando il coefficiente DCT è divisibile per 15. Questo spiega perché il calo di qualità è molto maggiore della differenza tra le impostazioni originali.

Modifica tra un numero maggiore di impostazioni

Eeyore non è felice quando q2viene cambiato in questo modo:

q2=$(( (RANDOM % 9)  + 90 ))

Per creare un video, utilizzare ffmpeg:

rename 's@1@@' 1*.jpg
ffmpeg -r 30 -i %04d.jpg -c:v libx264 -crf 1 -vf fps=25 -pix_fmt yuv420p output.mp4

Guardare le prime 9999 iterazioni è quasi come guardare bollire l'acqua. Potrebbe voler raddoppiare la velocità di riproduzione. Ecco Eeyore dopo 11999 iterazioni:

Cosa succede se i limiti dell'MCU cambiano?

Se i cambiamenti si verificano un numero limitato di volte, è probabile che la ricompressione ripetuta raggiunga uno stato stabile. Se si verificano cambiamenti ad ogni iterazione, l'immagine probabilmente si degraderà in modo simile a quando cambia DQT.

• Questo è ciò che accade nei video che ruotano un'immagine con dimensioni non divisibili per 8.

Che mi dici della modifica?

L'effetto della ricompressione dopo la modifica dipende dalla particolare modifica eseguita. Ad esempio, il salvataggio con la stessa impostazione di qualità dopo aver ridotto gli artefatti JPEG reintrodurrà gli stessi artefatti. Tuttavia, l'applicazione di una modifica localizzata, come un pennello correttivo, non influirebbe sulle aree che non sono state toccate.

Il calo maggiore della qualità dell'immagine si verifica la prima volta che il file viene compresso con una determinata impostazione di qualità. Successivamente la ricompressione con la stessa impostazione non dovrebbe introdurre alcun cambiamento maggiore dell'errore di arrotondamento. Quindi mi aspetterei che i cicli di modifica-salvataggio di una determinata impostazione di qualità assomiglino a qualsiasi altra immagine salvata con la stessa impostazione di qualità (fintanto che i confini dell'MCU rimangono intatti e il sottocampionamento cromatico è disabilitato ).

E quei video?

• Implementazione JPEG difettosa? ( Salvataggio di 500 volte con Photoshop al 10/12. )

• Modifica delle impostazioni di qualità. (La maggior parte dei video.)

• Distruggere i confini della MCU. (Ritaglio o rotazione )

• Altre manovre che riducono la qualità dell'immagine o interferiscono con l'algoritmo JPEG?

Posso sovrascrivere i miei originali con JPEG ricompressi?

È prudente conservare i backup di tutti i file originali, ma se si sovrascrive accidentalmente uno, il danno è probabilmente limitato. Andrebbe anche bene lavorare in JPEG con il sottocampionamento chroma disabilitato.

JPEG non può essere utilizzato per immagini che utilizzano più di 8 bit per colore.

La perdita di ricompressione è reale, specialmente quando si lavora con livelli più alti di compressione JPEG.

In teoria, se si salva nuovamente un file JPEG con gli stessi parametri esatti e si è allineato il ritaglio a 8 × 8 blocchi, il degrado dovrebbe essere minimo. Tuttavia, se stai utilizzando un alto livello di compressione, vedrai un'ulteriore perdita, perché i manufatti introdotti dalla compressione iniziale sono modifiche permanenti all'immagine e verranno ricompressi, causando più manufatti.

Se si salva nuovamente con un livello di compressione basso (alta qualità, come "100" in Gimp o 11 o 12 in Photoshop), sarà difficile notare eventuali artefatti aggiunti di recente. Non renderà l'immagine migliore , ma non significativamente peggiore. Tuttavia, vi introdurrà cambiamenti attraverso l'intera immagine.

Come test rapido, ho usato ImageMagick per ricomprimere un'immagine JPEG più e più volte al 75%. Gli esempi seguenti vengono caricati come file PNG per evitare un'ulteriore ricompressione e sono stati raddoppiati quando li ho convertiti in PNG per rendere l'effetto più ovvio. (Gli originali utilizzati nel test non sono stati raddoppiati.) Dopo otto ricampionamenti, l'effetto si è convertito in un risultato perfettamente stabile, dove la ricompressione si traduce nuovamente in un file identico bit per bit.

Ecco l'originale non compresso:

Ecco il risultato di andare al 75% JPEG:

Ed ecco che è stato salvato:

Quel singolo secondo di salvataggio provoca una grande quantità di ulteriore degrado!

Ed ecco l'immagine convergente finale (8 ° passaggio):

Ancora una volta, i colori sono sicuramente ancora più spenti, compresi alcuni modelli di falsi colori, e gli artefatti a blocchi saltano di più. L'algoritmo converge, ma in una versione significativamente degradata. Quindi, non farlo.

Ma ecco la stessa cosa con un livello di qualità del 99%, dopo 9 passaggi (il punto in cui converge quindi ulteriori passaggi sono identici):

Qui, la differenza si registra a malapena. (Voglio dire letteralmente; confrontali pixel per pixel con la versione non compressa e la deviazione è solo un rumore casuale molto leggero.) Quindi, se tornassi a quella prima immagine del 75% e poi rispedissi al 99%? Bene, questo, (dopo solo una volta):

Salvare ad alta qualità è decisamente visibilmente migliore che salvare con gli stessi parametri, con mia grande sorpresa. Ma c'è un evidente nuovo degrado attorno alla rifinitura rosa e agli occhi. Con la versione riciclata delle stesse impostazioni, gli artefatti JPEG vengono esagerati con ogni ricompressione. Con la bassa risoluzione e la bassa qualità che ho scelto, risulta essere peggio che ricomprimere tutto in modo diverso.

Su quei video: ho trovato questo uno dei migliori successi di Google. Si noti che nella descrizione si dice:

Questo è ciò che accade se si ricodifica più volte un'immagine JPEG, con impostazioni casuali di alta qualità (85 o superiore).

Enfasi aggiunta : questo spiega perché non vi è alcuna convergenza, perché invece di salvare con le stesse impostazioni o salvare con una qualità super alta, vengono utilizzate ogni volta impostazioni casuali .

Il secondo video che ho trovato dice:

Un'immagine JPEG è stata copiata e ruotata di un giro completo per ogni immagine. [...] (596 azioni "ruota in senso orario")

Quindi, ancora una volta, è stato fatto qualcosa per mantenere l'accumulo degli errori.

In ogni caso, per un pratico fotoritocco , vale la pena ricordare che il risparmio del 75% una volta è molto peggio che salvarlo al 99% un milione di volte . Nel mio caso di esempio, i manufatti al 75% sono così evidenti che l'ulteriore degrado è come scaricare l'acqua nell'oceano. Se si salva a un livello abbastanza alto da rendere questi artefatti non realmente visibili, salvare di nuovo con le impostazioni originali è una buona strategia. Naturalmente, se riesci a continuare a lavorare sempre con originali non compressi, stai meglio.

Se per qualche motivo devi (o preferire fortemente) solo lavorare con JPEG, imposta la fotocamera per il salvataggio nella massima qualità possibile , anche se non noti la differenza nei file iniziali. Vedi Vale la pena usare le impostazioni di qualità Premium JPEG di Pentax? per ulteriori informazioni al riguardo, non necessariamente specifiche per Pentax.

La ricompressione ha un effetto misurabile sulla qualità dell'immagine e tale effetto è molto più pronunciato quando si modificano i tassi di compressione.

Come un rapido controllo qui come alcuni valori SSIM per le operazioni eseguite su un'immagine di prova contenente una combinazione di funzioni di linea e caratteristiche continue. Ho selezionato JPG95 perché è quello che mi è stato insegnato a utilizzare nella scuola di fotografia pubblicitaria e JPG83 perché è comune tra i fornitori di contenuti digitali.

• Salva immagine Tiff come JPG95 - .9989
• Salva immagine Tiff come JPG83 - .9929
• Salva di nuovo l'immagine JPG95 come JPG95 10 volte - .9998
• Salva di nuovo l'immagine JPG83 come JPG83 10 volte - .9993
• Salvare nuovamente JPG95 come JPG83 quindi salvare nuovamente come JPG95 - .9929
• Salva JPG95 come JPG83, quindi JP83 a JP92, quindi JPG92 a JPG86 - .9914

Quindi la quantità di somiglianza strutturale persa per il salvataggio di 10 volte con la stessa compressione è 1/10 di quella persa risparmiandola con la qualità da tiff. Tuttavia, la perdita di qualità dovuta alla modifica della compressione JPG anche una volta è uguale alla qualità persa nel salvare l'immagine da Tiff a JPG.

Eseguirò questo test in altri modi e aggiornerò.

Metodologia : in ImageJ:

1. Converti Tiff RGB in scala di grigi a 8 bit
2. Salva JPG95 e JPG83 da Tiff Original
3. Effettuare ulteriori operazioni di salvataggio come specificato
4. Carica le immagini di confronto e usa il plug-in dell'indice SSIM

NOTA: molte persone che guardano i valori SSIM per la prima volta li leggono come percentuali e presumono che la differenza sia piccola. Questo non è necessariamente vero. I valori SSIM devono essere confrontati l'uno rispetto all'altro piuttosto che considerati come una varianza da 1.

Niente come una sperimentazione. Il seguente script bash (scritto su Linux, potrebbe funzionare su OSX se si dispone di ImageMagick ):

• a partire da una prima immagine (denominata step000.jpg)
• prende un file JPEG, aggiunge un punto bianco (per dimostrare che si tratta di una nuova immagine) e lo salva come (PNG senza perdita di dati)
• prende il PNG e lo ricomprime come JPEG (quindi non comprimiamo mai da JPEG a JPEG e non possiamo ipotizzare che il software copi solo blocchi codificati)
• crea un'immagine che mostra i diversi pixel tra i due JPEG
• sciacquare e ripetere, utilizzando l'output JPG del passaggio precedente

Il risultato è che:

1. non c'è molta perdita con elevate qualità JPG
2. gli errori di arrotondamento alla fine si risolvono, dopo un breve numero di generazioni, le cose non si degradano più.

Ovviamente tutto ciò presuppone che il JPEG sia salvato dallo stesso software con gli stessi parametri ogni volta.

#! /bin/bash
# Runs successive JPEG saves on an image to evaluate JPEG losses

# convert & compare command from imagemagick
# if you use a recent version of IM, set these variables to:
# compare="magick compare"
# convert="magick convert"
convert=convert
compare=compare

dotradius=2
defaultsteps=10
defaultquality=90 # default quality for "convert"

function usage {
        echo "Usage: $0 [quality [steps]]"
        echo ""
        echo "Where:"
        echo "       - 'quality' is the quality factor of the JPEG compression "
        echo "          (1-100, 100 is best, default is $defaultquality)"
        echo "       - 'steps' is the number of successive steps to perform"
        echo "         (default is $defaultsteps)"
        echo ""
        echo "Produces:"
        echo "   - successive saves of a JPEG image to test JPEG-induced losses."
        echo "   - compare images with the original file and the 1st JPEG save."
        echo ""
        echo "Starts from a 'step000.jpg' file in the current directory."
        exit 1
}

[[ -n "$3" ]] && { usage ; exit 1 ; }
steps=${1:-$defaultsteps}
quality=${2:-$defaultquality}    
dotcolor="white" # change this if the top of the image is too clear

echo "Running with $steps steps with quality $quality"

for step in $(seq $steps)
do 
    echo "Step $step of $steps"
    src=$(printf step%03d $(( $step - 1 )) ) 
    dst=$(printf step%03d $(( $step )) )
    dif=$(printf diff%03d $(( $step )) )
    # dot coordinates
    let cxc="2 * $dotradius * $step"
    let cxr="$cxc + $dotradius"
    let cyc="$dotradius * 2"
    let cyr="$dotsradius * 2"

    $convert $src.jpg -fill white -draw "circle $cxc,$cyc,$cxr,$cyr" $dst.png
    $convert $dst.png -quality $quality $dst.jpg
    rm $dst.png
    $compare $src.jpg $dst.jpg $dif.jpg
done

Per ora non mostrerò i risultati, preferisco lasciarti sperimentare con le tue foto. Con abbastanza commenti, aggiungerò un campione.