Domanda:
È garantito che un JPG produca gli stessi pixel?
Wayne Werner
2016-10-16 05:27:10 UTC
view on stackexchange narkive permalink

So che ci sono molti vantaggi nello scattare in RAW, ma al momento sembra che JPG funzioni bene per me. Le dimensioni dei file sono molto più piccole e darktable sembra funzionare bene con loro (anche se abbastanza interessante sembra che in realtà sia più veloce con la modifica dei file RAW, ma potrebbe essere solo un'allucinazione).

Per quanto ne so, il modo in cui funziona darktable è creare un file collaterale contenente le modifiche da apportare al file JPG originale, quindi in teoria le modifiche non sono distruttive (cioè non ricomprime l'immagine in JPG ogni volta).

Considerato tutto ciò, ero curioso: lo stesso file JPG è garantito per produrre gli stessi pixel ogni volta che viene renderizzato? Ad esempio, supponiamo di avere un file JPG salvato con una qualità del 98%. Se lo apro al 100% di zoom, avrà gli stessi pixel quando lo apro in darktable come quando lo apro in Google Chrome? O quando lo apri in Photoshop? E i file con una compressione più elevata, ad es. Qualità al 50%?

Alcuni encoder consentono di scegliere tra DCT a virgola mobile e intero. Qualcuno che sa di cosa stanno parlando (non io in questo caso!) Può chiedere se questo potrebbe essere * memorizzato * con valori in virgola mobile? O è solo un calcolo intermedio?
Ci sarebbero differenze tra loro, sarebbero piccole ma decisamente differenti dal punto di vista matematico.
Sette risposte:
#1
+18
Aaganrmu
2016-10-21 13:51:07 UTC
view on stackexchange narkive permalink

Risposta breve

No, non è garantito che la decodifica sia sempre la stessa. Tuttavia, è garantito che le differenze saranno molto, molto piccole.

Specifiche ISO

Le specifiche ISO (International Organization for Standardization) per JPEG hanno le seguenti specifiche per i decoder (enfasi mia):

Un decodificatore deve

a) con accuratezza appropriata , convertire in dati di immagine ricostruiti qualsiasi dato di immagine compressa con parametri all'interno dell'intervallo supportato dall'applicazione e che rispettano la sintassi del formato di interscambio specificata nell'Allegato B per i processi di decodifica incorporati dal decodificatore;

b) accetta e memorizza correttamente qualsiasi tabella- dati di specifica conformi al formato abbreviato per la sintassi dei dati di specifica della tabella specificata nell'allegato B per i processi di decodifica incorporati dal decodificatore;

c) con appropriata precisione , convertire per ricostruire i dati di immagine qualsiasi dato di immagine compressa conforme al formato abbreviato per la sintassi dei dati di immagine compressa specificata nell'Allegato B per i processi di decodifica incorporati dal decodificatore, a condizione che i dati di specifica della tabella richiesti per la decodifica dei dati dell'immagine compressa siano stati precedentemente installati nel decodificatore.

Adeguata accuratezza è molto severo. Qualsiasi convertitore che segua queste specifiche deve essere confrontato con un algoritmo di riferimento. Per un singolo pixel, ogni componente può differire solo di un bit dal riferimento. Inoltre, l'errore (quadrato) su ogni blocco di 8x8 pixel e sull'intera immagine deve essere molto basso.

Ma perché dovrebbe essere diverso?

A differenza di bmp o png, un jpeg non memorizza i pixel stessi ma una descrizione dell'immagine. Per ricostruire i singoli pixel viene utilizzato un complesso algoritmo matematico. Dopo ogni passaggio, l'algoritmo memorizza il risultato in memoria. È qui che le cose possono andare storte: un valore in memoria ha una certa precisione, la precisione della macchina. Per questo motivo il valore deve essere arrotondato. Sebbene le specifiche assicurino che venga utilizzata una precisione minima, non esiste un massimo. L'arrotondamento può quindi essere diverso per ciascuna implementazione. Può anche dipendere dall'hardware utilizzato, poiché alcuni processori utilizzano più bit di precisione di quanto richiesto. Alcuni dei primi processori Pentium lo sbagliavano.

Piccolo esempio semplificato: calcolare 5 * 0,12 per addizione ripetuta.

Memorizzando valori intermedi usando una cifra di precisione, un computer potrebbe farlo : 0,12 + 0,12 = 0,24, memorizzare il risultato intermedio come 0,2 (arrotondamento per difetto). Quindi calcolare 0,2 + 0,12 = 0,32, memorizzare come 0,3 (di nuovo, arrotondando per difetto). Continua questo schema e il risultato sarà 0,5 invece del risultato atteso di 0,6. Se fosse stata utilizzata una precisione maggiore (due cifre, ad esempio), il risultato sarebbe stato diverso.

Credo che questa sia la risposta corretta. Ho provato un paio di app comuni per vedere se riuscivo a rilevare differenze di 1 bit, ma finora ho fallito.
Ho scoperto che il mio precedente fallimento era dovuto solo alla mia inesperienza con l'editor di immagini che avevo a portata di mano. Una volta che ho capito come migliorare correttamente le differenze di immagine, erano evidenti. Ho lasciato la mia risposta per dimostrare.
Bene, hai davvero le prove.
Il fatto che esista uno standard ISO non significa che sia comunemente rispettato dalle implementazioni del mondo reale.
#2
+9
Mark Ransom
2016-10-21 22:08:06 UTC
view on stackexchange narkive permalink

No, non puoi dipendere che le immagini JPEG decodificate siano identiche bit per bit.

Ad esempio, ho provato a visualizzare l'immagine nella parte superiore di questa pagina in due browser diversi: Chrome 53.0.2785.143 e Internet Explorer 11.0.9600.18426. sembrano identici, ma ho inserito gli screenshot in un editor di immagini e ho ingrandito la differenza. Puoi vedere che non sono la stessa cosa.

Ecco l'immagine originale:

Original image

Ed ecco il differenza tra i due rendering del browser, migliorata:

Enhanced difference

Cosa succede se lo apri in Chrome in due diverse schede: ti viene presentata un'immagine identica?
@WayneWerner L'ho provato proprio ora, e sì, erano identici. Come mi aspetto che siano. Sono abbastanza sicuro che le differenze siano dovute ai dettagli negli algoritmi di decodifica di software diversi, come dettagliato in un'altra risposta.
L'hai provato anche con un PNG, nel caso Chrome e Internet Explorer usassero una gestione del colore diversa?
@LoganPickup no, non l'ho fatto, ma è una buona idea.
#3
+4
null
2016-10-16 06:27:06 UTC
view on stackexchange narkive permalink

è garantito che lo stesso file JPG produca gli stessi pixel ogni volta che viene renderizzato?

Sì. È solo un elenco di numeri che rappresentano i valori del colore (in modo intelligente per renderlo piccolo). Non ci sono informazioni "prodotte" nel processo di apertura di un file jpeg che sarebbero diverse tra due applicazioni.

E i file che hanno una compressione più alta, ad es Qualità al 50%?

Quindi i numeri nell'elenco saranno diversi. (più zeri) Oltre a questo, non c'è differenza.

Questo è vero per quanto riguarda la parte di decompressione. C'è però un grande avvertimento: un codice di gestione del colore diverso può produrre risultati diversi durante la conversione nello spazio colore di destinazione, in particolare se un'app specifica la compensazione del punto di nero e un'altra no. E questo non tiene nemmeno conto di qualsiasi troncamento del calcolo intermedio che potrebbe o non potrebbe verificarsi.
Quindi, con lo stesso tasso di compressione, un hash md5 delle immagini generate dovrebbe rimanere uguale indipendentemente da quante volte eseguiamo il processo di compressione sull'immagine originale?
#4
+4
Euri Pinhollow
2016-10-16 22:17:10 UTC
view on stackexchange narkive permalink

La compressione e gli interni JPEG stessi non influenzano la riproducibilità di file già compressi: produrrà lo stesso output di pixel in programmi funzionanti correttamente dato che

  • lo spazio colore di una fotografia corrisponde al colore spazio del sistema di gestione del colore
  • stai visualizzando l'immagine con una scala del 100%, ovvero l'output da pixel a pixel sul monitor

Se, ad esempio, l'immagine Il file contiene dati AdobeRGB, può produrre dati pixel diversi nei sistemi di colore sRGB perché è possibile utilizzare algoritmi diversi per la conversione da AdobeRGB a sRGB e possono utilizzare una precisione diversa per i calcoli. È molto probabile che Photoshop e Chrome utilizzino algoritmi diversi per la conversione del colore.

Molti browser non sono configurati correttamente per scopi colorimetrici e potrebbero non utilizzare affatto il profilo del monitor e potrebbero visualizzare l'immagine in modo completamente diverso da Photoshop.

Quando l'immagine viene ridimensionata, la differenza tra gli algoritmi di ridimensionamento verrà visualizzata in modo simile.


Potrebbe essere complicato ma probabilmente qualcosa che vorresti sapere.

#5
+2
James Snell
2016-10-17 18:40:16 UTC
view on stackexchange narkive permalink

La maggior parte degli schemi di codifica JPEG non sono concepiti per essere esattamente accurati, sono "percettivamente privi di perdite". Tale principio verrà applicato nelle implementazioni sia degli algoritmi del codificatore che del decodificatore.

È ragionevole aspettarsi che in un decodificatore vengano implementate alcune ottimizzazioni che favoriscono le prestazioni rispetto alla precisione, che la gestione del colore potrebbe non essere implementata a tutto e che la conversione RGB-Y'CrCb non sarà identica tra i decoder.

JPEG è pensato per essere "abbastanza buono", le differenze sarebbero sottili e questo è l'output che ci si dovrebbe aspettare. Lo stesso principio si applicherebbe indipendentemente dal livello di compressione applicato al file sorgente.

#6
+1
xiota
2018-07-21 06:39:16 UTC
view on stackexchange narkive permalink

@Aaganrmu è generalmente corretto. Non c'è alcuna garanzia che un particolare file JPEG verrà renderizzato esattamente nello stesso modo ogni volta che viene aperto , anche dallo stesso programma .

In pratica, a meno che un programma non sia stato aggiornato, l'apertura dello stesso file con lo stesso programma produrrà gli stessi risultati. Molti programmi utilizzano anche le stesse librerie di decodifica e produrranno gli stessi risultati. Sarebbe uno sforzo eccessivo per i programmatori introdurre intenzionalmente variazioni nell'algoritmo JPEG per produrre risultati diversi ogni volta che viene aperto un file. Inoltre, non è ciò che gli utenti si aspetterebbero o vorrebbero. (Ciò significa ignorare i profili di colore e la correzione, che è un passaggio separato dopo la decodifica.)

La possibilità di variazione proviene da input diversi potenzialmente risultanti lo stesso output come risultato di trasformazioni, arrotondamenti e quantizzazione che si verificano come parte dell ' algoritmo JPEG. Queste operazioni sono anche la fonte di artefatti JPEG.

JPEG variations

I decoder JPEG knusperli e jpeg2png sono progettati per ridurre gli artefatti JPEG entro i vincoli consentiti dall'algoritmo JPEG. Producono un output che dovrebbe fornire gli stessi dati che erano stati inseriti se riqualizzati con le stesse impostazioni. (Se comprendo correttamente il loro funzionamento, ignorano le differenze che possono essere introdotte da errori di arrotondamento.) Di conseguenza, impiegano più tempo per la decodifica e il loro output è diverso (migliore?) Da quello di altri decoder.

Ecco i ritagli al 100% per mostrare la differenza tra libjpeg (a sinistra) e jpeg2png (a destra):

jpeg2png example

#7
-2
WayneF
2016-10-16 21:02:35 UTC
view on stackexchange narkive permalink

Un pixel è solo un colore, un colore medio campionato da quella piccola area di pixel. Il colore è come vediamo i dettagli. Vediamo un cavo di alimentazione nero che attraversa un'immagine di un cielo blu solo perché il colore è diverso. Il colore è il dettaglio.

JPG Quality 50 è solo 50, solo un numero, NON è 50%.
JPG 100 non è 100% di nulla. 100 è JPG abbastanza buono, ma è ancora JPG.

Gli artefatti JPG (causati da un fattore di qualità inferiore) alterano il colore dei pixel. Il pixel è di un colore diverso e un pixel è solo colore, quindi è un pixel diverso.

La codifica (creazione) di JPG è spesso diversa in ogni programma. Esistono diverse opzioni, assunte in modo diverso nei diversi programmi. La qualità 80 in un programma è improbabile che corrisponda alla qualità 80 in un altro programma.

La mia ipotesi è che la decodifica (visualizzazione) di JPG sia standard, mostrando ciò che è stato codificato.

JPG è meglio oggi di esso una volta lo era, ma ci sono ancora artefatti JPG.

Un tipo di artefatto JPG è che JPG cerca di fare in modo che il colore nei blocchi di 8x8 pixel sia lo stesso colore se fossero già di un colore simile. Una bassa qualità JPG tende a mostrare quei blocchi di 8x8 pixel in aree di colore simile (cieli, muri, ecc.).

Un altro tipo di artefatto JPG è una sfocatura o un'eco di spigoli vivi sfalsati leggermente rispetto al bordo originale .

Vedi http://www.scantips.com/basics09b.html per alcuni esempi di artefatti JPG.

Una bassa qualità JPG può creare email e Internet più piccolo e più veloce, ma per le nostre fotografie reali, semplicemente non sembra esserci una buona ragione per cui vorremmo una bassa qualità JPG. :)



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...