Tutte le immagini digitali non sono in definitiva solo valori di pixel compresi tra 0 e 255?

Ho alcune domande incredibilmente basilari (stupide?) Sulle immagini; in particolare, formati di immagine e valori di pixel.

Perdonami, non sono un fotografo. Sono solo qualcuno che lavora con le immagini e per me sono solo righe e colonne di numeri.

Le mie domande sono:

Se al centro, le foto sono solo 3 canali di valori di pixel [0, 255] X RBG, allora come potrebbe esserci qualche differenza tra due formati di immagini? Voglio dire, cosa rende un RAW diverso da un TIFF: non sono tutti limitati a valori compresi tra 0 e 255? Un numero è un numero: non dovrebbe esserci solo un formato set possibile? Oppure, non dovrebbero essere bloccate due immagini con la stessa altezza e larghezza con le stesse dimensioni del file?

Inoltre, dal punto di vista numerico, cosa rende qualcosa di simile a un'immagine a 16 bit diversa dalle immagini a 32 bit? Ancora una volta, un'immagine è solo un array con valori interi compresi tra 0 e 255.

Continuando con questa prospettiva che un'immagine sul filesystem di un computer è solo una matrice di numeri interi a 3 canali compresa tra 0 e 255, a che serve comprimere un'immagine, un formato con perdita di dati come, ad esempio, JPG? Supponiamo che l'algo di compressione cambi alcuni valori di pixel da 254 a 255 o altro. Così? In che modo ciò consente di risparmiare sulla dimensione del file o influire sulla qualità visiva?

So che ci sono molti modi diversi per memorizzare i dati delle immagini. Ma non sto chiedendo altro che un'immagine RBC di base a 3 canali. Tutto quello che so è che se qualcuno mi passa uno di questi, ora ho una serie di numeri. Non ho motivo di sapere perché un array di numeri potrebbe essere diverso da qualche altro array di numeri da 0 a 255. Spero che abbia senso. Questa domanda non è limitata al formato RAW! Piuttosto, si tratta di qualsiasi array di valori di pixel

Siamo spiacenti, ma la premessa di base è errata: un'immagine può essere codificata come una matrice di pixel RBG con 8 bit per valore, ma ci sono molti altri modi:

• un canale con un bit / canale (bianco e nero puro),
• un canale con x bit / canale (formati in scala di grigi, x sarà generalmente 8 o 16, con valori 256 o 65536),
• vari formati basati su palette (cfr. GIF)
• a colori con (almeno in teoria) tutti i canali che desideri con qualsiasi profondità di bit richiesta.

E questo è per l'immagine memorizzata nella RAM del computer durante la modifica / visualizzazione. Sto ignorando i vari formati di immagine RAW esistenti (qui e nel resto di questo post).

Per la fotografia , i più comuni sono 3 canali con 8, 16 o 32 bit / canale (in genere interi, ma almeno alcuni programmi funzionano internamente con numeri in virgola mobile a 32 bit). Spesso c'è un quarto canale (alfa), specialmente quando il programma consente l'uso di livelli. E da qualche parte, le dimensioni dell'array di immagini devono essere memorizzate.

Ci sono vari motivi per questi diversi formati. Per il formato in memoria, una considerazione importante era la dimensione dei dati e la velocità (molto più veloce per manipolare un canale a 8 bit rispetto a 4 canali a 32 bit). Oggi sono meno importanti, ma abbiamo ottenuto una gestione completa del colore con vari spazi colore. Alcuni di questi (ad es. Prophoto RGB) richiedono almeno 16 bit / canale per mantenere le differenze tra i colori vicini abbastanza piccole da evitare strisce visibili. E man mano che i trattamenti diventano più complicati, ci sono vantaggi nell'utilizzare numeri in virgola mobile a 32 bit (in cui i colori sono codificati con valori compresi tra 0,0 e 1,0 e il trattamento consente valori intermedi al di fuori di questo intervallo).

Se si desidera poter archiviare l'immagine su file e ricaricarla negli stessi dati in memoria, è necessario utilizzare almeno un numero di bit per canale pari al formato im-memory e è necessario memorizzare informazioni su dimensioni dell'immagine, profondità di bit e spazio colore.

Agli utenti di quelle immagini piace anche memorizzare alcune informazioni aggiuntive sull'immagine (didascalia, titolo, chi ha scattato l'immagine, ecc ...). Ancora una volta vari modi per memorizzare queste informazioni.

Quindi ci sono diversi modi per comprimere i dati dell'immagine per l'archiviazione dei file. Uno dei più semplici è RLE (Run Length Encoding), dove si memorizzano un conteggio e un valore di pixel ogni volta che si incontra un valore di pixel ripetuto. Altri, come jpeg, sono molto più complicati, ma danno anche molta più compressione. Ad esempio, jpeg usa una trasformazione del coseno e getta via le informazioni ad alta frequenza (meno visibili), offrendo alti tassi di compressione a costo della perdita di informazioni (c'è di più, ma sta diventando troppo lungo così com'è).

Ciò offre già molti modi per archiviare le informazioni sul disco, ma in qualunque modo tu scelga, il formato deve essere ben specificato per consentire una corretta interpretazione nel caricamento dell'immagine.

Quindi vi è uno sviluppo costante, ad esempio in tecniche di compressione senza perdita, che i formati esistenti non possono sempre gestire.

Quindi finiamo con una varietà di formati di file, con vari compromessi tra fedeltà delle informazioni memorizzate, spazio su disco occupato e velocità di lettura, scrittura e trasmissione (confronta le dimensioni di un TIFF non compresso e un jpg di buona qualità) .

Se viene gestita un'immagine in memoria, sarà sotto forma di uno o più array. A quel punto, il formato del file originale non dovrebbe più svolgere un ruolo . Presumo che tu abbia gestito i tuoi dati con 8 bit / canale.

Ma dovrai sapere se hai un'immagine elaborata o un'immagine grezza, poiché ci sono due importanti differenze tra quelle:

• le immagini non elaborate in genere hanno 1 colore per pixel , e i pixel sono generalmente disposti in un array Bayer con 2 pixel verdi, 1 rosso e 1 pixel blu per quadrato di 4 pixel. I valori sono proporzionali all'intensità della scena (tranne i valori molto bassi e molto alti).
• le immagini elaborate possono essere organizzate come una matrice 2D di record contenente 3 valori numerici o come piani di colore (3 array 2D, uno per ciascuno di R, G, B). Inoltre, i valori di solito non sono proporzionali alle intensità della scena . Peggio ancora, la relazione esatta tra i valori dei pixel e l'intensità della scena dipende dall'elaborazione che l'immagine ha avuto. E l'equilibrio tra i colori è stato regolato per corrispondere alla risposta dell'occhio umano (il bilanciamento del bianco, il rosso e il blu sono amplificati rispetto al verde).

Quindi, se ottieni un'immagine non elaborata con 3 valori di colore per pixel, quell'immagine non elaborata ha già subito un trattamento (almeno o demosaicing o semplice binning di 4 pixel grezzi su 1 pixel di immagine). Se questo è accettabile, dipenderà dalla tua applicazione.

Se al centro, le foto sono solo 3 canali di valori pixel [0, 255] X RBG,

Ma le foto non sono "solo 3 canali di valori di pixel" anche "al centro". Gli schermi di computer sono in genere costituiti da una matrice di pixel RGB, quindi se si desidera visualizzare un'immagine sullo schermo di un computer, a un certo punto è necessario mappare tutti i dati di immagine che si hanno in una matrice di pixel RGB, ma tali dati sono solo un particolare rendering dei dati dell'immagine. I dati nell'immagine potrebbero non essere affatto costituiti da un flusso di valori di pixel. Per ottenere valori di pixel da un'immagine, devi sapere come vengono formattati i dati.

allora come potrebbe esserci qualche differenza tra due formati di immagini? Voglio dire, cosa rende un RAW diverso da un TIFF: non sono tutti limitati a valori compresi tra 0 e 255?

Questi sono due buoni esempi, perché nessuno di questi formati contiene necessariamente una matrice rettangolare di valori RGB.

RAW non è affatto un singolo formato: è una sorta di nome generico per i file che contengono dati registrati direttamente da un sensore di immagine. Pertanto, un file RAW potrebbe contenere una sequenza di valori che rappresentano le tensioni lette dai vari siti dei sensori. Questi siti sono come i pixel dell'immagine, ma sono senza pixel RGB. Per ottenere pixel RGB da un file RAW, è necessario interpretare tali dati nel contesto delle informazioni sul sensore, le impostazioni della fotocamera al momento, ecc. In altre parole, è possibile aprire un file RAW in un editor esadecimale e guarda tutto quello che vuoi, ma non troverai un singolo valore RGB.

TIFF sta per formato di file immagine con tag , ed è un formato molto interessante perché può contenere molte rappresentazioni diverse di un'immagine. Un singolo file TIFF potrebbe contenere la "stessa" immagine in diverse dimensioni, come una miniatura, un'immagine con risoluzione dello schermo e immagine con risoluzione di stampa e potrebbe anche avere versioni a colori e in scala di grigi. Sapevi che i fax in genere inviano i loro dati come file TIFF? Per estrarre i pixel RGB da un file TIFF, è necessario comprendere non solo il formato TIFF, ma anche il formato della particolare rappresentazione dell'immagine all'interno di quel file.

Un numero è un numero: non dovrebbe esserci solo un formato set possibile?

No. Esistono molti formati di immagine diversi perché ognuno risponde a una serie di esigenze diverse. La compressione con perdita di JPEG è ottima per ottenere file di immagini molto piccoli, ma non è buona per le immagini che dovranno essere modificate più volte. Alcuni formati utilizzano l' interlacciamento , il che rende molto veloce la lettura dell'immagine a diverse risoluzioni. E così via ... ogni formato offre il proprio mix di vantaggi e compromessi.

Oppure, non dovrebbero essere bloccate due immagini con la stessa altezza e larghezza con le stesse dimensioni del file?

No, sarebbe terribile. Se la dimensione di ogni file di immagine dovesse essere essenzialmente width * height * 3(assumendo il colore a 24 bit), sprecheresti molto spazio di archiviazione. La maggior parte delle foto contiene molta ridondanza, ovvero regioni in cui lo stesso colore viene ripetuto più volte. Per risparmiare spazio di archiviazione, spesso ha senso eliminare tali informazioni ridondanti. Un modo per farlo, ad esempio, è la codifica della lunghezza della corsao RLE. Ad esempio, se hai una regione di 4195 pixel consecutivi che sono tutti bianchi, è molto più efficiente codificare che come "i successivi 4195 pixel sono tutti {255, 255, 255}" invece di archiviare semplicemente quei pixel bianchi in il file. RLE è effettivamente utilizzato in alcuni formati di immagine, ma molti formati hanno schemi molto più sofisticati che consentono di risparmiare molto più spazio e ciò significa che è possibile memorizzare molte più immagini su un disco rigido o una scheda di memoria. Inoltre, rende molto più veloce l'invio dell'immagine a qualcun altro.

Continuando con questa prospettiva che un'immagine sul filesystem di un computer è solo una matrice di numeri interi a 3 canali compresa tra 0 e 255, a che serve comprimere un'immagine, un formato con perdita di dati come, ad esempio, JPG?

Il punto è che rende il file molto più piccolo. La compressione JPEG riduce spesso la dimensione di un file di un fattore pari o superiore a 10. Ciò significa che puoi adattare più immagini su un determinato dispositivo di archiviazione, puoi copiarle più velocemente, puoi aprirle più velocemente e puoi caricarle e scaricarle più velocemente. La memorizzazione della stessa immagine (o quasi) in uno spazio molto più piccolo utilizza le risorse in modo più efficiente e quindi riduce i costi. Pensateci su larga scala: è probabile che una percentuale molto grande delle informazioni disponibili su Internet sia costituita da immagini e filmati e senza compressione avremmo bisogno di più o più grandi data center e consumeremmo molta più energia.

Supponiamo che l'algo di compressione cambi alcuni valori di pixel da 254 a 255 o altro. Così? In che modo ciò consente di risparmiare sulla dimensione del file o influire sulla qualità visiva?

Considera il mio esempio RLE sopra. Supponiamo che tu abbia una foto che include un grande muro bianco, quindi grandi aree della tua foto sono tutte dello stesso colore, tranne per il fatto che c'è una dispersione di pixel leggermente più scuri, appena visibile nell'immagine. Quei pixel riducono l'efficacia della compressione. Invece di poter semplicemente dire "i prossimi 500.000 pixel sono tutti {243, 251, 227}", devi eseguire la lunghezza per codificare molti più blocchi molto più piccoli, perché ogni tanto ti imbatti in uno di quei pixel leggermente diversi. Se si consente all'algoritmo di compressione di apportare piccole modifiche, cambiando forse qualsiasi pixel di non più dell'1% o del 2%, è possibile ottenere un rapporto di compressione molto più elevato senza cambiare sensibilmente l'immagine. È un compromesso: tu ' rinunciare a una piccola quantità di informazioni nell'immagine originale in cambio di una grande riduzione delle dimensioni del file. Il punto esatto in cui si desidera tracciare tale linea può cambiare, quindi i formati con perdita di dati come JPEG consentono all'utente di scegliere il livello di compressione che desidera.

Oltre alla fantastica risposta di @ remco , voglio aggiungere perché ci sono codec diversi per (approssimativamente) lo stesso scopo.

I codec sono progettati per:

• Sii senza perdita contro perdita
• Codifica veloce vs. riduci dimensione file
• En / decodifica asimmetrica vs. simmetrica
• Sii compatibile con il software
• Essere percettivamente quasi senza perdite in diversi livelli / situazioni di compressione
• Dispone di funzionalità che altri codec non offrono, tra cui:
  • essere esenti da royalty
  • supporto per i livelli
  • supporto per canale alfa (es. RGBA) / trasparenza
  • offrire una visualizzazione Web veloce
  • supporta una profondità di bit elevata (er)
  • supporta più spazi colore (RGB / CMYK)
  • supporto per metadati / versioning / ...

Alcune di queste cose si escludono a vicenda. E per questo motivo, ci rimane una moltitudine di codec.

Alcuni esempi

Nota: né l'elenco dei codec è completo, né vengono menzionate tutte le loro funzionalità (o la mancanza di esso). Se questa risposta dovesse rivelarsi utile per qualcuno, potrei aggiungere qualche informazione in più (ed essere un po 'più preciso).

Forse il formato più comunemente noto è JPEG . È un formato ampiamente supportato, ma vecchio. Utilizza DCT (Discrete Cosine Transformation), quindi mentre offre una qualità abbastanza buona con le sue impostazioni di massima qualità, il blocco apparirà con quelli inferiori.

Quindi JPEG 2000 è arrivato per sostituire JPEG: si basa sulla trasformazione Wavelet, quindi mentre offre all'incirca la stessa qualità di JPEG nelle impostazioni di qualità superiore, offre una qualità molto migliore nelle impostazioni di qualità inferiore (i blocchi sono un po 'sfocati ). Inoltre, JPEG 2000 offre regioni di interesse (alta qualità in un'area dell'immagine, qualità inferiore altrove) e supporto a 16 bit. (Inoltre, alcune altre cose.) Sfortunatamente (?), Poiché è più costoso dal punto di vista computazionale rispetto a JPEG e a causa di alcuni problemi di licenza, JPEG 2000 non è ampiamente supportato come JPEG.

PNG è un altro formato ampiamente conosciuto: è senza perdita di dati e supporta canali alfa, ma non offre supporto per spazi colore non RGB (come CMYK). Pertanto, si tratta di un formato "solo online".

Quindi ci sono i formati VFX come OpenEXR . Tutto ruota intorno alla qualità e alla velocità: OpenEXR è senza perdita di dati, supporta fino a 64 bit e codifica / decodifica rapidamente. È utilizzato principalmente nel settore VFX come formato intermedio.

TIFF è un altro formato senza perdita che è abbastanza popolare tra i fotografi. Per la compressione, offre nessuno / ZIP / RLE / LZW / JPEG. Supporta fino a 32 bit. Con la sua compressione selezionabile, è abbastanza adattivo, ma a causa della sua mancanza di perdita, è più di un formato offline.

HEIF è uno degli ultimi codec di immagini. Utilizza la stessa compressione di HEVC / h.265 e pertanto dovrebbe fornire un rapporto di compressione migliore rispetto a JPEG. Tuttavia, poiché è abbastanza nuovo e poiché è soggetto a brevetti, non è ampiamente supportato come uno dei precedenti.

Immagini RAW ^{Vedi anche} non sono immagini reali, in realtà: sono più un contenitore per i dati grezzi (da cui il nome) di lettura del sensore. Solo con un software che sa interpretare i dati è possibile ottenere un'immagine. Questo è anche il motivo per cui i convertitori RAW come Lightroom / Capture One / DarkTable / ... necessitano di aggiornamenti per supportare le nuove fotocamere che utilizzano contenitori già specificati come * .CR2 per Canon. È anche il motivo per cui un RAW a 14 bit offre più opzioni di modifica rispetto a un TIFF a 32 bit esportato dallo stesso RAW.

Intermisision: Lossless vs lossy

Non sono ancora sicuro di cosa tu stia davvero chiedendo, quindi ho pensato che non sarebbe male aggiungere una piccola spiegazione su lossless vs lossy.

La compressione senza perdita funziona eseguendo la codifica run-length (RLE) / Huffman coding / ... per comprimere i dati. I dati stessi non vengono modificati, ma salvati in un pacchetto più piccolo. Ad esempio, prendi RLE: supponiamo che abbiamo un bitstream del canale R (da pixel 0,0a pixel 0,11) di 255,255,255,255,255,215,215,235,100,000,000,000- RLE lo codificherebbe come 52552215123511003000- questo è molto più piccolo e poiché sappiamo che è salvato in gruppi di 4 cifre e che il la prima cifra è il contatore e le ultime tre cifre sono il valore, quindi possiamo ricostruire il pieno 255,255,255,255,255,215,215,235,100,000,000,000.

La compressione con perdita , d'altra parte, cerca di comprimere anche più di quanto possa fare senza perdita. Per fare questo, i codec con perdita di solito cercano di rimuovere le cose che la nostra percezione non riesce a ottenere. Prendiamo, per esempio, i YUV( YCbCr, davvero) il modello JPEG (e quasi ogni codec video) usi: Y = Luminance, Cb = Chrominance Blue, Cr = Chrominance Red. Un essere umano non può distinguere tra una 4:2:0(ogni pixel ha un valore di luminanza, ma i colori vengono salvati alternativamente in blocchi di 2x2) e un'immagine 4:4:4(ogni pixel ha luminanza e entrambi i canali di colore) codificata. Ciò è dovuto alla fisiologia del nostro occhio : non possiamo vedere differenze di colore così come possiamo vedere differenze di luminanza.

Funziona bene per la maggior parte del tempo, ma confrontalo con un file MP3: quasi nessuno può distinguere tra 192kbps e 320kbps, ma scende sotto 64kbps e le cose si fanno brutte rapidamente. Inoltre, la ricodifica ridurrà ulteriormente la qualità, poiché potrebbero apparire artefatti indesiderati (ad es. In JPEG, piccoli blocchi di codifiche di alta qualità saranno considerati come dettagli dell'immagine in ulteriori codifiche).

Linea di fondo

Se non ti interessano i formati di immagine o le loro caratteristiche, uno andrà bene. Con impostazioni di qualità abbastanza elevate, è possibile e prevedibile che non vedrai nemmeno una differenza tra di loro.

Se, tuttavia, hai bisogno di una funzionalità specifica, potrebbe esserci (e quasi sicuramente: sarà) un codec che ha quello coperto.

Se al centro, le foto sono solo 3 canali di valori di pixel [0, 255] X RBG

Questo è un presupposto seriamente rotto e il resto della tua domanda non è semplicemente rispondibile senza staccarti da esso.

Voglio dire, cosa rende un RAW diverso da un TIFF: non sono tutti limitati a valori compresi tra 0 e 255?

Il termine "raw" può riferirsi a due cose diverse, un'immagine "camera raw" o un file che contiene dati di immagini raw senza intestazioni.

Un'immagine "camera raw" memorizza i dati grezzi appena escono dal sensore. La maggior parte dei sensori per fotocamere moderni ha ADC con più di 8 bit, ma raccolgono anche dati di intensità per un solo colore in ogni posizione. La geometria può essere distorta dall'obiettivo, i valori di intensità dell'ADC potrebbero non fare un buon lavoro nel riflettere la percezione dell'intensità di un essere umano, i componenti del colore potrebbero non corrispondere esattamente a quelli usati dal monitor e così via.

È necessario un complicato processo di mappatura che coinvolge l'interpolazione per trasformare i dati dei sensori grezzi in un'immagine RGB di buona qualità e non esiste un modo giusto per farlo. Inoltre, a causa della necessità di interpolare i componenti di colore, l'immagine RGB potrebbe risultare più grande dei dati grezzi.

La conversione può essere (e spesso avviene) nella fotocamera, ma molti fotografi cercano di salvare i dati grezzi in modo che possano modificare l'elaborazione dopo il fatto.

Tiff è un formato di file complesso che può memorizzare immagini in un'ampia varietà di formati diversi con un'ampia varietà di metadati. In pratica, tuttavia, viene solitamente utilizzato per archiviare immagini RGB o CMYK non compresse o senza perdita di compressione.

I file che contengono dati di immagini non elaborati senza intestazioni vengono usati raramente perché devi conoscerne il formato e le dimensioni prima di poterli leggere. Alcuni strumenti di elaborazione delle immagini li supportano però.

Inoltre, dal punto di vista numerico, cosa rende qualcosa di simile a un'immagine a 16 bit diversa dalle immagini a 32 bit?

Sfortunatamente "n bit" può significare due cose diverse. Può significare che tutti i componenti del colore sono stipati in un numero di bit (ad esempio 5 bit per il rosso, 5 bit per il blu e 6 bit per il verde per 16 bit o 8 bit per il rosso, 8 bit per il verde, 8 bit per il blu e 8 bit di alpha per 32 bit) o ​​at può significare che ogni componente di colore ha n bit di informazioni in ogni posizione di pixel.

Continuando con questa prospettiva, un'immagine sul filesystem di un computer è solo una matrice di numeri interi a 3 canali compresa tra 0 e 255

Ancora una volta questa prospettiva è semplicemente sbagliata.

Un file è una sequenza di byte, ma quei byte non sono quasi mai "solo un array di numeri interi a 3 canali compreso tra 0 e 255"

Potresti memorizzare un'immagine del genere. Alcuni strumenti supportano persino la lettura e la scrittura di tali file, ma il problema è che significa che devi conoscere il file prima di poterlo leggere. Supponiamo che tu abbia un file di dimensioni pari a 3000 byte, hai 1000 pixel RGB a 24 bit? 3000 pixel in scala di grigi a 8 bit? 3000 pixel a 8 bit da un pallete? In che ordine sono i componenti del colore? che forma ha l'immagine? i componenti del colore sono nell'ordine RGB o BGR? A meno che non si conoscano le risposte a queste domande, non è possibile leggere in modo significativo tale file.

Quindi i formati di immagine pratici in genere iniziano con una o più intestazioni che identificano il tipo di file, le dimensioni dell'immagine e il modo in cui vengono archiviati i dati reali dell'immagine. Possono anche contenere metadati opzionali.

a che serve comprimere un'immagine in un formato con perdita di dati, ad esempio JPG? Supponiamo che l'algo di compressione cambi alcuni valori di pixel da 254 a 255 o altro. Così? In che modo ciò consente di risparmiare sulla dimensione del file o influire sulla qualità visiva?

Gli algoritmi di compressione non si limitano a "cambiare valori", codificano le informazioni in un modo completamente diverso, ad esempio JPEG può essere approssimativamente descritto come

• Converti i dati da RGB a YUV
• (facoltativamente) ridurre la risoluzione dei canali cromatici di un fattore 2 in una o entrambe le dimensioni
• Dividi i dati per ciascun canale in blocchi 8x8.
• Converti i blocchi nel dominio della frequenza usando una trasformazione del coseno discreta
• Quantizzare i risultati, preservando le informazioni a bassa frequenza e riducendo la precisione delle informazioni ad alta frequenza.
• Codifica i numeri risultanti come una sequenza di byte utilizzando uno schema di codifica a lunghezza variabile (codifica huffman o codifica aritmetica)
• Salvare quei byte nel file insieme alle intestazioni appropriate.

D'altra parte, i formati compressi senza perdita di dati si basano spesso su un algoritmo di compressione dei dati per scopi generici, ma a volte completano poi con una pre-elaborazione specifica dell'immagine, ad esempio PNG sembra.

• Converti i dati in uno dei formati supportati (ad esempio un bit ciascuno per rosso, verde e blu in quell'ordine)
• Per ogni riga dell'immagine esegue processi di "filtraggio", ci sono opzioni di filtraggio server (incluso nessun filtro) ma l'obiettivo generale è quello di prendere le informazioni specifiche dell'immagine che un pixel è probabilmente simile ai suoi vicini e codificare in un modo che "sgonfia" può affrontare.
• Comprimi i dati filtrati usando l'algoritmo di compressione "deflate" per scopi generici.
• Salvare quei byte nel file insieme alle intestazioni appropriate.

Esistono diversi motivi per cui questa ipotesi non è corretta e si riducono tutti a una cosa:

Quale scala stai attualmente usando?

E questo può essere ulteriormente scomposto:

Che cosa è 255?

Il "colore" non è una proprietà dell'universo fisico. È una sensazione che sorge nella mente. E questo include cose come "blu", "verde" e "rosso". Una scala da 0 che significa "niente blu" a 255 che significa "tutto il blu!" in realtà non può avere 255 rappresentare l'ideale platonico del blu , perché ... non esiste una cosa così perfetta nel mondo reale. Quindi, significa:

• il tipo più blu di cose che puoi fare sul dispositivo di fronte a te?
• quanto più vicino alla corrispondenza ideale al blu puro dal punto di vista del sistema di visione umano, anche se la maggior parte degli schermi e le combinazioni stampante / inchiostro / carta non possono rappresentarlo?
• un blu abbastanza buono che è probabile che sia ragionevolmente rappresentato su una vasta gamma di dispositivi?
• un blu che è al di fuori della gamma della visione umana, ma che consente alla tua tripla copertura RGB la maggior parte dei colori che si trovano nella gamma?

Sembra artificioso? No! Questi sono in realtà esempi reali . Dai un'occhiata a queste rappresentazioni di ogni scelta. L'area curva è una porzione 2D dello spazio colore della visione umana e il triangolo mostra l'area che può essere rappresentata con una scelta particolare per il rosso, il verde o il blu.

Innanzitutto, ecco il profilo per lo schermo del mio laptop, che è piuttosto rappresentativo degli attuali dispositivi di fascia media:

Ora, ecco lo spazio Adobe RGB. Nota quanto è più grande di ciò che il mio schermo può mostrare!

Quindi, ecco sRGB: lo spazio defacto standard e predefinito di solito viene assunto quando non viene specificato nulla. È pensato per essere "abbastanza buono" nella maggior parte delle situazioni.

E infine, ProPhoto RGB, che utilizza colori immaginari come primari, al fine di rendere il triangolo abbastanza grande da adattarsi a quasi tutta la visione umana.

Ora getta il colore della luce stessa e l'adattamento cromatico : la capacità del sistema di visione umana di adattare la percezione all'ambiente. In realtà, non solo abilità: cosa succede se lo vuoi o no . "Blu puro" significa che la cosa sembra blu come può essere sotto questa luce a incandescenza? Quale dovrebbe essere il valore se invece fotografiamo alla luce del sole?

Quindi "255" può significare molte cose diverse.

Che cosa è 0?

Questo è abbastanza semplice: quanto è necessario il nero per essere 0? È vantablack nero? Se lo è, ma tutte le sfumature effettive nella tua scena sono molto meno estreme , vuoi davvero "sprecare" un sacco di potenziali valori per una gamma dinamica che non è nella tua scena e che, come il colore, può non sarai nemmeno rappresentato da alcun dispositivo o stampante a cui hai accesso?

Qual è la tua curva?

Quindi, una volta ottenuti gli endpoint, come si passa da uno all'altro? La percezione umana della luminosità è decisamente non lineare . Nella tua scala 0-255, 100 dovrebbe essere due volte più luminoso di 50 o dovrebbe essere un fattore maggiore? La differenza percettiva tra, diciamo, 3 e 4 dovrebbe essere uguale a quella tra 203 e 204?

Se decidi di utilizzare un sistema di archiviazione dei log, tale curva dovrebbe essere ottimizzata per adattarsi alla visione umana, o per l'ottimizzazione dei dati o per qualcos'altro?

Ci sono molte possibilità, per molte esigenze diverse.

Alla compressione

Tu chiedi.

Supponiamo che l'algo di compressione cambi alcuni valori di pixel da 254 a 255 o altro. Così? In che modo ciò consente di risparmiare sulla dimensione del file o influire sulla qualità visiva?

I moderni algoritmi di compressione sono più complicati di così, ma questo fornisce un buon esempio. Userò esadecimale FFper rappresentare 255 e FEper rappresentare 254, e immagino che stiamo usando la codifica della lunghezza della corsa come forma di compressione. E per semplicità, supponiamo che il bianco e nero invece del colore. Detto questo, se abbiamo una fila di dati che assomiglia a questo:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

possiamo comprimerlo in modo molto semplice

16×FF 

... che è un risparmio abbastanza evidente. Fondamentalmente possiamo memorizzare 16 byte in due (uno per il conteggio, due per i dati). Ma supponiamo di avere:

FF FF FE FF FE FF FF FF FF FF FE FE FE FF FE FE

Ora, la codifica run-length ci dà:

2×FF 1×FE 1×FF 1×FE 5×FF 3×FE 1×FF 2×FE

... che non è affatto un risparmio, e in effetti potrebbe aver aumentato le dimensioni del file. Ma se arrotondiamo tutti i FEvalori a FF, torniamo al primo caso, con una significativa riduzione delle dimensioni, con un impatto piccolo ma probabilmente difficile da notare sulla qualità del file.

Naturalmente questo è un banale, esempio forzato, ma tutti gli algoritmi di compressione lossy condividono questa caratteristica fondamentale: la perdita dei dati rende più facile utilizzare un formato di archiviazione più compatto, con, si spera, non troppo percepito il cambiamento.

Su profondità di bit

Inoltre, dal punto di vista numerico, cosa rende qualcosa di simile a un'immagine a 16 bit diversa dalle immagini a 32 bit? Ancora una volta, un'immagine è solo un array con valori interi compresi tra 0 e 255.

Quindi ..... un array di valori interi compresi tra 0 e 255 è un array a otto bit . (2⁸ = 256.) Con tre canali, questa è un'immagine a 24 bit; alcuni formati hanno anche un canale di trasparenza ("alfa"), per 32 bit. Si può anche usare un valore più alto per canale, che di solito è ciò che intendiamo quando diciamo "profondità a 16 bit". Ciò significa che l'array va da 0-65535 (2¹⁶ = 65536) anziché a 0-255. Generalmente in un tale schema, questo è fondamentalmente solo un moltiplicatore in cui il valore più alto rappresenta la stessa cosa su ogni scala, ma la profondità di bit più elevata offre più sfumature possibili. (Vedi questa risposta per ulteriori informazioni al riguardo.) Esistono anche alcuni formati di file specializzati che utilizzano float a 64 bit (!) Invece di numeri interi per i valori o altri tipi di dati a seconda del caso d'uso, ma il concetto di base è lo stesso .

No, un'immagine non è solo valori RGB nell'intervallo 0-255. Anche se ignori i formati di archiviazione, esistono molti modi per descrivere il colore. Ecco alcuni esempi:

• Componenti rosso, verde e blu (RGB)
• Componenti ciano, magenta, giallo e nero (CMYK)
• Tonalità, saturazione e luminosità / valore (HSL / HSV)
• La quantità di luce che colpisce un gruppo di sensori in una fotocamera
• La quantità di luce e la sua direzione quando colpisce i sensori (in una fotocamera a campo chiaro )

I primi due sono i più comunemente usati per la visualizzazione su monitor e per la stampa, rispettivamente.

Inoltre, un'immagine non è solo pixel, ma anche metadati. Potrebbero essere cose come la larghezza in numero di pixel, la larghezza fisica se dovessi stamparla, un'immagine in miniatura o persino la posizione geografica della fotocamera quando l'immagine è stata scattata.

La tua premessa non è sbagliata: qualsiasi immagine può essere rappresentata usando una matrice N-dimensionale di valori finiti. Personalmente, generalizzo l'uso di una geometria discreta anziché di una matrice, ma l'essenza è la stessa. Ma questo è il contenuto, non il file.

Tuttavia, i formati di file sono diversi. Fondamentalmente, ci sono diversi modi per rappresentare quella stessa immagine, come le persone menzionate: bmp, png, jpg, ecc. Naturalmente, una volta decodificate, due versioni codificate senza perdita della stessa immagine porteranno alle stesse matrici.
Pensalo come un file .txt compresso con zip. Con la stranezza aggiunta che una codifica senza perdita di dati restituirebbe un testo che non è lo stesso dell'originale, ma molto vicino, quasi come una versione stupida del testo.

Rimanendo con l'analogia del testo, supponiamo che tu abbia lo stesso testo, salvato come .txt, .docx, .pdf, ecc. Perché tutti i file non sono esattamente uguali, se il contenuto è lo stesso? (Ok, txt non ha formattazione, ma gli altri lo fanno).

A proposito, controlla come la codifica Netpbm sia davvero diversa da JPEG .

Per quanto riguarda i formati RAW e TIFF, per quanto ne so, la risposta (come altri hanno già detto) è che in realtà non usano sempre gli stessi spazi colore (ad esempio i file RAW potrebbero usare più bit per pixel in modo da poter memorizzare informazioni sul colore più fini) .

Ma per arrivare al nocciolo della tua domanda - a volte ci sono immagini che sono memorizzate in formati diversi, ma ognuna alla fine rappresenta esattamente la stessa matrice di numeri.

Un buon esempio di una ragione di ciò sono le differenze di compressione tra un file PNG e un file TIFF.

I file PNG usano un particolare algoritmo di compressione. Ciò significa che un'immagine non verrà semplicemente memorizzata come un grande elenco di numeri per ciascun pixel. Esempio semplificato: potrebbe memorizzare qualcosa che dice "in questo blocco di pixel 10x10, tutti i pixel sono di colore XYZ". Quindi, invece di archiviare tali informazioni 100 volte, le memorizza una volta, oltre a un po 'di informazioni sulla regione a cui si applicano le informazioni.

Il problema è quindi di recuperare l'array originale di numeri (che rappresentano i colori), in modo da poterlo mostrare o modificarlo o altro, è necessario un software che sappia interpretare le informazioni compresse.

I file PNG usano sempre lo stesso algoritmo di compressione, quindi è facile per il software supportare tutti i file PNG validi. D'altra parte, alcune immagini hanno una struttura che non si presta all'algoritmo di compressione di PNG, quindi alcuni dei tuoi file PNG potrebbero finire per essere piuttosto grandi.

I file TIFF, d'altra parte, supportano molti diversi algoritmi di compressione. In effetti, può persino memorizzare diverse parti dell'immagine compresse in modo diverso. E supporta 'estensioni', quindi puoi comprimere le immagini usando metodi proprietari. Quindi forse la metà superiore dell'immagine verrà compressa utilizzando un metodo simile a PNG, ma questo non comprimerà molto bene la metà inferiore, quindi la metà inferiore viene compressa con un metodo diverso.

Quindi i file TIFF sono più flessibili: potresti essere in grado di memorizzare esattamente lo stesso array di numeri usando meno byte. Ma il software necessario per decodificare l'immagine sarà più complicato e potrebbe non funzionare in modo coerente con ogni file TIFF che viene lanciato, ad esempio potresti salvare un file TIFF in un software e non essere in grado di aprirlo utilizzando un altro software, anche se funziona ancora nell'originale.

Quindi chiedi

Ma non sto chiedendo altro che un'immagine RBC di base a 3 canali. Tutto quello che so è che se qualcuno mi passa uno di questi, ora ho una serie di numeri. Non ho motivo di sapere perché un array di numeri potrebbe essere diverso da qualche altro array di numeri da 0 a 255.

Per consegnartelo, qualcuno doveva sapere come l'immagine era memorizzata e come tradurla in una matrice di numeri. (O forse alcuni software stanno facendo quella traduzione per te all'insaputa di te).

Puoi provare a salvare un'immagine come PNG e di nuovo come TIFF o GIF e guardarla in un visualizzatore esadecimale per vedere come ciascuno di essi rappresenta lo stesso array di numeri in modo diverso. Oppure leggi i dettagli su come i file PNG e i file TIFF sono rappresentati internamente per darti un'idea di ciò che deve essere integrato nel software per leggere matrici identiche di numeri in modo diverso.

Bitmap

Una bitmap (BMP) è essenzialmente ciò che descrivi, una matrice di numeri che rappresentano i colori dei pixel. Ad esempio qualcosa del genere

1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1

Compressione senza perdita

Ora definiamo uno schema di compressione. Nel nostro schema di compressione, avremo una matrice di coppie di numeri. Per esempio

3, 1, 1, 0, 7, 1

Ora, la prima cosa che voglio sottolineare è che questo schema di compressione rappresenta gli stessi pixel del primo array. Il primo array ha tre 1 seguiti da un singolo 0 e quindi da sette 1. Ed è quello che rappresentiamo qui. Questo formato è più breve, in quanto rappresenta più pixel con due numeri. Il formato bitmap deve utilizzare un numero per ciascun pixel.

Ovviamente questa è una visione in qualche modo semplificata di un'immagine (ad esempio è solo una riga) e uno schema di compressione. Ma spero che questo ti permetta di vedere come uno schema di compressione cambia il formato di un'immagine. Ecco come si riferisce una GIF a un BMP. GIF utilizza uno schema di compressione chiamato Lempel-Ziv-Welch invece di questo semplicistico.

Quello che abbiamo descritto qui è uno schema di compressione senza perdite. Un problema con gli schemi di compressione senza perdita di dati è che per alcuni input, la forma codificata potrebbe essere più lunga dell'originale. Ad esempio per

1, 0, 1, 0, 1

La codifica è

1, 1, 1, 0, 1, 1, 1, 0, 1, 1

Bene, era inutile. Abbiamo inserito il doppio del tempo.

Un'altra compressione senza perdita

Consideriamo ora un diverso schema di compressione. In questo, rappresenteremo l'immagine come cerchi sovrapposti. Per ogni cerchio, definiremo un centro, un raggio e un colore.

La nostra prima bitmap sarebbe diventata

5, 5, 1, 3, 0, 0

Questa è la stessa lunghezza del nostro primo metodo di compressione.

E il nostro secondo potrebbe essere neanche

2, 2, 1, 2, 1, 0, 2, 0, 1

Si tratta di tre cerchi centrati sull'elemento centrale (che nel conteggio dei computer è il numero 2, poiché i computer iniziano a contare su 0). Un cerchio ha raggio 2 e colore 1. Quindi aggiungiamo un cerchio di colore 0 e raggio 1. Infine, abbiamo un cerchio di colore 1 e raggio 0. A passi, questo sarebbe

1, 1, 1, 1, 1
1, 0, 0, 0, 1
1, 0, 1, 0, 1

O

2, 2, 1, 1, 0, 0, 3, 0, 0

Questo è lo stesso cerchio iniziale ma coperto da due cerchi di punti. A passi sarebbe

1, 1, 1, 1, 1
1, 0, 1, 1, 1
1, 0, 1, 0, 1

Questi sono entrambi uno più corto della prima versione codificata ma ancora più lungo dell'originale.

Potresti chiederti perché sto parlando di cerchi e non di intervalli. Il motivo principale è che i cerchi sono più vicini all'utilizzo di immagini bidimensionali reali.

Compressione in perdita

Abbiamo anche il concetto di schemi di compressione con perdita. Questi schemi di compressione senza perdita di dati possono essere ripristinati nell'array bitmap originale. Gli schemi di compressione con perdita di dati potrebbero non essere reversibili.

Consideriamo una versione con perdita del nostro metodo cerchie. In questo, useremo una semplice regola. Non memorizzeremo alcun cerchio con un raggio inferiore a 1. Quindi, nelle nostre ultime due codifiche, avremmo invece

2, 2, 1, 2, 1, 0

e

2, 2, 1

che sono nuovamente convertiti in pixel

1, 0, 0, 0, 1

e

1, 1, 1, 1, 1

La prima versione è solo un elemento più lungo dell'originale. La seconda versione è più breve. Entrambi sono validi, quindi l'algoritmo è libero di svilupparli entrambi e scegliere quello più corto.

Descriviamo le immagini con regole più restrittive come di qualità inferiore.

Questa rappresentazione di immagini come raccolte sovrapposte di forme circolari è simile al modo in cui funziona il gruppo di esperti fotografici congiunti o il formato JPEG . Le sue forme sono ellissi piuttosto che cerchi, ma l'idea è simile. Piuttosto che il nostro metodo semplicistico, utilizza la trasformazione del coseno discreto per codificare le immagini.

A differenza di GIF, JPEG è in realtà un modo diverso di rappresentare l'immagine. GIF è ancora pixel. Sono semplicemente memorizzati in un modo diverso. JPEG è forme. Per visualizzare un JPEG, convertiamo quindi le forme in pixel perché è così che funzionano gli schermi. In teoria, potremmo sviluppare uno schermo che non ha funzionato in questo modo. Invece di pixel, potrebbe produrre forme in modo da abbinare meglio il formato JPEG. Ovviamente, quello schermo non sarebbe in grado di mostrare bitmap. Per visualizzare un BMP o GIF, dovremmo convertire in JPEG.

Se converti una GIF standard, ad esempio 300x300 pixel, la converti in un JPEG e accendi la qualità fino in fondo, le forme di base che usa dovrebbero essere visibili. Molti JPEG evitano questi artefatti iniziando con un'immagine a risoluzione molto più elevata.

I JPEG si ridimensionano bene perché sono forme piuttosto che pixel. Quindi, se inizi con un'immagine 8000x8000, la converti in JPEG e la visualizzi come immagine 300x300, gran parte dei dettagli persi sarebbero comunque andati persi. Se hai convertito prima la bitmap 8000x8000 in una bitmap 300x300 e poi in JPEG, i risultati saranno spesso di qualità inferiore.

MPEG

Abbiamo parlato di immagini fisse. Il formato Moving Picture Experts Group o MPEG utilizza lo stesso tipo di compressione di JPEG, ma fa anche qualcos'altro. Mentre un modo semplice di fare video è inviare una sequenza di immagini fisse, MPEG in realtà invia un fotogramma, seguito da un certo numero di fotogrammi che elencano le modifiche e finiscono con un fotogramma finale. Poiché la maggior parte dei frame è simile al frame precedente, l'elenco delle modifiche è spesso più piccolo di una seconda immagine.

La sequenza normalmente non è così lunga, diciamo cinque fotogrammi. Ma aiuta a rendere lo stream più piccolo di quanto sarebbe altrimenti.

semplificazioni

Ho ignorato molto. Le mie immagini hanno solo due colori (1 bit), non i 256 di un'immagine a 8 bit e certamente non i 4.294.967.296 di un'immagine a 32 bit. Anche con immagini a 8 bit, tieni presente che spesso puoi scegliere diverse tavolozze per l'immagine. Quindi due bitmap a 8 bit con le stesse sequenze possono rappresentare immagini che sembrano diverse (stessa forma ma colori diversi).

Le mie immagini sono file singole, non bidimensionali. La maggior parte delle immagini avrà una dimensione di riga specifica memorizzata, rendendo le matrici bidimensionali.

Non ho provato a rappresentare le codifiche effettive. Sono molto più complessi di quelli che ho usato. L'ho fatto perché volevo essere in grado di descrivere le codifiche in questo post. Non sono convinto di poter spiegare Lempel-Ziv tanto meno la più complessa raffinatezza di Lempel-Ziv-Welch in un'unica risposta. E non capisco le trasformazioni di Fourier abbastanza bene da spiegarle a lungo.

Questa è davvero una versione semplificata della gestione effettiva delle immagini. Tuttavia, ritengo che ai fini didattici sia più facile da comprendere rispetto alla realtà più complessa, pur continuando a colpire i punti essenziali.

Diciamo che era vero, che ogni pixel era solo tre numeri (rosso, verde e blu) ciascuno nell'intervallo 0-255. Altri risponditori hanno iniziato contestando (correttamente) tale ipotesi, ma per semplicità diciamo solo che è vero.

Ricordo (ma purtroppo non riesco a trovare online) un cartone tratto da un libro di testo linguistico: due antichi intagliatori di pietra egiziani sono seduti sfiniti sul fondo di un enorme muro sul quale hanno scolpito un numero molto grande di figure in marcia. Uno sta dicendo all'altro: "Sicuramente ci deve essere un modo più semplice per scrivere, 'Il faraone aveva 100.000 soldati?'". Tieni a mente quell'idea.

Supponiamo ora che la prima riga dell'immagine contenga 1800 pixel neri. Come sarebbe rappresentato?

0 0 0    0 0 0     0 0 0   ....

Quindi, quanto spazio di archiviazione richiederebbe? Ogni valore è un byte. Tre byte per pixel, 1800 pixel nella riga, quindi già 5400 byte per riga. Quindi un'immagine con dimensioni 1800 x 1200 deve occupare 1200 volte tanto, che supera i 6 megabyte. Quindi ora andiamo a fare una ricerca di immagini di Google e a scaricare un paio di immagini 1800x1200 — diciamo, .pngun'immagine e .jpgun'immagine. Guarda le dimensioni del file: sono 6 MB? In nessun caso, di solito è molto più piccolo di così. E questa è una cosa desiderabile, ovviamente, tutto quello spazio risparmiato e tempi di download più brevi ....

Quindi cosa sta succedendo? La chiave è che, anche se hai tanti numeri da memorizzare, ci sono diversi modi di rappresentarequei numeri nel file. C'è un esempio di una rappresentazione più efficiente proprio qui nella mia risposta, due paragrafi fa. Ho scritto le parole "1800 pixel neri". Sono 17 caratteri e quindi non devono occupare più di 17 byte, tuttavia descrivono perfettamente le stesse informazioni esatte per le quali pensavamo di aver bisogno di 5400 byte. E potresti certamente fare meglio di 17 byte (e anche risparmiare molto sforzo nell'implementazione di codifica / decodifica) se non usassi la lingua inglese per codificare queste informazioni, ma piuttosto una lingua più specifica. Quindi ora, già, abbiamo inserito più di un formato di compressione dell'immagine: uno che usa parole inglesi e uno che è più efficiente di così. Vedi dove sta andando?

OK, dici, funziona se un intero gruppo di pixel adiacenti ha lo stesso colore. E se non lo facessero? Bene, certo, dipende dal contenuto dell'immagine particolare: maggiore è la ridondanza , più facile è comprimere le informazioni. Ridondanza significa che parti dell'immagine possono essere previste abbastanza bene se si conoscono già altre parti. Compressione significa solo scrivere il minimo indispensabile per ricostruire le informazioni. Non tutte le possibili immagini hanno ridondanza, ma qualsiasi immagine reale che abbia significato per l'occhio e il cervello umani, nonostante sia più complessa del mio esempio di puro nero, tenderà comunque ad avere abbastanza ridondanza. E ci sono molti modi diversi di comprimere. Alcuni metodi di compressione sono senza perdita, il che significa che le informazioni possono essere ricostruite per essere matematicamente identiche all'originale, come nel mio esempio di fila nera di pixel. La maggior parte dei .pngfile utilizza un metodo di compressione senza perdita di dati. Alcuni metodi sono in perdita : la ricostruzione non è perfetta, ma gli errori sono nascosti in modo tale che l'occhio umano e il cervello difficilmente li notano. La maggior parte dei .jpgfile sono in perdita.

I dettagli di come si riconoscono schemi complicati di ridondanza e di come si scrivono descrizioni compresse efficienti, sono altamente matematici e non banali, motivo per cui c'è spazio per così tanti formati diversi là fuori, corrispondenti a diverse strategie di compressione. Ma spero che tu ottenga il principio.

Un paio di commentatori sopra hanno fatto ipotesi ragionevoli su dove potrebbe essere sorto il tuo malinteso. Nella tua domanda, sembra che la compressione cambi solo leggermente i valori dei pixel (e alcuni metodi di compressione con perdita di dati lo fanno in alcuni punti, ma solo come un effetto collaterale indesiderato) senza cambiare il layout delle informazioni. Quando aprite il file e guardate il contenuto dell'immagine (ad esempio, come una matrice di numeri in Matlab o come immagine sullo schermo in Photoshop) non state guardando il contenuto del file compresso, ma piuttosto la ricostruzione, che ha lo stesso layout dell'originale (non sarebbe molto una ricostruzione se non ricreasse correttamente il layout). La procedura di apertura del file ha decompresso le informazioni dal file in una rappresentazione non compressa completa in memoria. Se si confrontano due ricostruzioni non compresse , in effetti non c'è nulla da distinguere tra i due diversi formati di immagine da cui provengono (tranne gli eventuali errori di ricostruzione).

Sì, ma come arrivare a questi 1 e 0 è molto diverso.

Farò un esempio, ma è falso e si suppone che illustri più che essere accurati. Tieni presente che tutte le immagini digitali sono rappresentate in binario a un certo livello.

A complicare le cose, ci sono diversi canali. CMYK, RGB, B&W, solo per citarne alcuni. Non ci penseremo. Esistono anche diverse fasi, come acquisizione, archiviazione e visualizzazione. Ci occuperemo di questo, anche se l'esempio dovrebbe dimostrare di non essere accurato. Se vuoi esempi precisi, dovrai cercare un sacco di documenti tecnici.

Quindi, nel nostro campione, vedremo un'immagine in bianco e nero.

00067000
00067000
00567800
04056090
40056009

I numeri rappresentano quanto è forte il "Nero". Ecco come la fotocamera ha catturato l'immagine. È una fotocamera decente, quindi è anche il modo in cui memorizza l'immagine.

Ora memorizza l'immagine su un computer, ma occupa molto spazio, quindi la comprimeremo. Oltre a mescolarlo, sappiamo anche che la maggior parte delle persone non è in grado di rilevare una differenza di 1 livello di nero, quindi elimineremo alcuni.

302730
302730
204820
*04056090
1420262019

Ora è così che memorizziamo l'immagine su disco. Occupa meno spazio e ci consente di produrre gran parte dell'immagine originale.

Ora diciamo che vogliamo stamparlo su una stampante. La stampante stampa solo un livello di nero, quindi un computer traduce l'immagine compressa memorizzata in linguaggio stampante.

00011000
00011000
00111100
01011010
10011001

Questo stampa un'immagine dall'aspetto ragionevole, ma puoi vedere, anche nell'esempio, una mancanza di qualità extream. Ma hey è colpa della stampante.

Infine, vai a stampare l'immagine su una buona stampante con 10 livelli di nero. Come la tua fotocamera. Quindi usi l'immagine memorizzata e compressa.

00077000
00077000
00888800
04056090
40066009

Come puoi vedere l'immagine è "migliore" ma è stata leggermente modificata rispetto all'originale.

In qualsiasi momento hai ragione che è tutta la forza di un canale. E a parte l'immagine compressa, che deve essere decompressa comunque, rimane piuttosto fedele.

Tuttavia, il formato compresso perde molte "informazioni". Queste informazioni sono importanti? Bene, dipende dall'artista e dal pubblico. Esistono diversi compromessi tra risparmio di spazio, tempo di elaborazione, qualità dell'immagine finale / memorizzata e necessità. Acquisisco la maggior parte dei miei documenti in un colore nero perché è tutto ciò di cui ho bisogno. Tuttavia, le mie foto di nozze sono nel formato ENORME RAW perché non so mai quando vorrò una grande ristampa di quelle. Detto questo, quando li trasferisco (foto) su una cornice digitale, li converto in JPEG per risparmiare spazio. Diversi canali, diversi filtri e diversi metodi di compressione sono tutti una serie di compromessi. È come una versione digitale del triangolo delle stampanti.

Ti fornirò un po 'di informazioni supplementari mentre ho lavorato con il rilevamento delle immagini e la codifica / compressione, anche se per lo più immagini in movimento.

Nella sua forma di base, un'immagine (QUALSIASI immagine) visualizzata su uno schermo particolare È effettivamente solo una matrice identica di numeri. Quei numeri possono essere tutti 0-255 o 0-65535 o 0-qualunque-32-bit-è-ho-dimenticato-go-google-it.

MA ci sono così tanti modi per MEMORIZZARE e TRASPORTO che le informazioni, molti di loro sono semplicemente prodotti di tecnologie perse nella notte dei tempi.

Inoltre, un dettaglio che non ho visto nessuno degli altri pedanti qui menzionati è che i dati del sensore di immagine veramente RAW da una fotocamera digitale potrebbero essere RGrGbB in uno schema bayer o qualcosa del genere che deve essere elaborato almeno un po 'per rendere qualsiasi senso per il bulbo oculare umano Mk.1. È probabile che non lo otterrai mai nemmeno in un formato RAW salvato dalla tua DSLR perché è inutile fino a quando non lo converti in una bella griglia di pixel RGB o YUV, che siano profondi 8, 16, 32 o undici miliardi di bit.

Le cose su cui ho lavorato usano YUV internamente per qualsiasi motivo, presumo che sia più facilmente elaborato dai codec poiché gli umani percepiscono la luminosità con molta più sensibilità del colore.

Per leggere la buona notte prima di andare a letto, consultare la sezione "Formato immagine della cornice": http://focus.ti.com/lit/ug/sprufg8b/sprufg8b.pdf

Comunque ... tornando alla tua domanda originale sulla differenza tra file di immagini non compressi come TIFF / RAW / IFF / PNG.

Generalmente il motivo per cui esistono è che, molte lune fa, ogni produttore di computer / sistema operativo / stampante ha presentato una propria serie di requisiti leggermente diversi per un certo modo di archiviare / inviare immagini.

Quindi, RAW, come discusso da altri in questo thread, è un termine generico per diverse cose salvate da diverse fotocamere digitali, usando qualsiasi carico di dati che il produttore della fotocamera ritenesse importante, in base alle caratteristiche che la loro fotocamera potrebbe o potrebbe avere in futuro. Quindi, anche se il bit dei dati dell'immagine principale potrebbe essere molto simile, il "pacchetto" attorno ad esso che descrive l'immagine e tutte le impostazioni della fotocamera ecc. In modo che un file non venga compreso da un altro produttore.

Tradizionalmente questo è così che possono farti (o, più probabilmente, fotografi professionisti) utilizzare il loro software proprietario (e talvolta costoso) per elaborare queste immagini di qualità superiore, altrimenti potresti iniziare a utilizzare software costoso di altre persone. Inoltre, forse Adobe Photoshop vuole supportare il loro formato, quindi forse possono caricare Adobe $$$ per quelle informazioni in modo che più fotografi professionisti acquistino PS e magari acquistino quella marca di fotocamera perché PS ora lo supporta. Accogliente!

RAW memorizza anche le informazioni su come trasformare quel particolare gruppo di dati in un'immagine visualizzabile dall'uomo, mettendo semplicemente tutte le modifiche che è necessario apportare ai dati affinché l'immagine appaia "giusta".

TIFF era un formato di immagine iniziale che, tra le altre cose, veniva utilizzato per inviare dati grafici alle stampanti (quando le stampanti con funzionalità grafiche iniziarono a diventare accessibili). Era abbastanza semplice, quindi facile da elaborare sul piccolo microprocessore economico all'interno della stampante.

IFF (sì, è una cosa) era un formato simile usato sui computer Amiga, credo che sia stato inventato da loro o da uno dei popolari pacchetti di colori. Ma lo sto usando qui come esempio perché, sebbene memorizzi i dati delle immagini bitmap come gli altri, supportava dati non compressi o RLE, profondità variabili da 1-bit mono a 8-bit a 256 colori (ma con una tavolozza RGB 3x8-bit tra cui scegliere per ciascuno dei colori) così come modalità speciali chiamate Mezzitoni e Hold-And-Modify che consentono molti più colori di quelli che altre macchine dell'epoca potevano gestire. Oh, e supportava anche l'animazione (come GIF) in modo che un file IFF potesse memorizzare un numero qualsiasi di frame, con ritardi variabili tra i frame, e ogni frame poteva avere una propria tavolozza. Quindi, IFF includerebbe dati extra per gestire tutto questo rispetto, per esempio, a un file TIFF.

PNG è un altro formato di immagine senza perdita di dati, che memorizza nuovamente i dati bitmap, ma supporta alcune funzionalità funky come un canale alfa a 8 bit per la trasparenza variabile su un'immagine (utile sulle pagine Web), quindi il "payload" dei dati dell'immagine potrebbe apparire molto simile ma il wrapper attorno è diverso e il payload potrebbe contenere RGBA anziché solo dati RGB per pixel.

Quindi, sono descritti 4 diversi formati di file di immagini: potresti archiviare un'immagine HD a colori di esempio di un gatto in uno dei 4 e sembrerebbe identico, ogni pixel sullo schermo avrebbe il valore ESATTO STESSO e non ci sarebbe NO differenza di qualità tra i 4 ... ma i 4 file sarebbero probabilmente diversi per dimensioni, layout, e sarebbe più facile o più difficile da caricare ed elaborare per il software.

Spero che aiuti!

Ho pensato di entrare qui con le informazioni che avrebbero dovuto essere nella prima risposta a questa domanda.

I pixel di un'immagine non vengono memorizzati in un byte, a meno che l'immagine non sia monocromatica, ovvero solo in bianco e nero.

Se hai un'immagine truecolor, ogni pixel è rappresentato da 16 bit o 2 byte - come un valore. Se hai un'immagine a 32 bit, ogni pixel richiede 32 bit o 4 byte, sempre come valore singolo.

abbastanza interessante, i file di immagini e suoni e ogni altro tipo di dati in un computer si riducono a bit di 1 e 0. È solo interpretandoli in blocchi della dimensione corretta che il significato viene estratto da essi.

Ad esempio, un'immagine, un documento di parole e un file mp3 hanno tutti lo stesso contenuto di dati di base (un mucchio di byte) e ognuno di essi potrebbe essere interpretato come uno degli altri tipi: potresti interpretare un documento di Word come un suono file e sentiresti qualcosa, ma non sarebbe musica. Potresti sicuramente interpretare un file audio come un'immagine e mostrerebbe qualcosa, ma non sarebbe un'immagine coerente.

Quindi, per riassumere, un computer conosce solo i bit: un bit è 1 o 0. Tutte le immagini, i suoni, i documenti, i filmati, i video, le registrazioni, i giochi, le telefonate, i messaggi di testo e qualsiasi altra cosa etichettata come digitale hanno lo stesso esatto contenuto - un gruppo di 1 e 0. Gli 1 e gli 0 diventano immagini, suoni e documenti e tutto il resto perché il codice che li legge sa leggere quei bit in gruppi ed elaborarli di conseguenza.

Ecco perché abbiamo immagini come immagini a 16 e 32 bit e file audio a 16 e 24 bit. Più bit usi per un pixel o un campione sonoro, più espressivi puoi essere: 16 bit possono definire solo 64k colori unici, ma 32 bit possono definire oltre 4 milioni di colori unici. Un'immagine monocromatica utilizza 1 bit per pixel: è attivata o disattivata.

Con i file audio, più bit usi per campione, più dettagliata e sfumata può essere la registrazione.

Non ho letto l'intero thread, ma mi sembra che molte persone si stiano dimenticando dei formati di immagini vettoriali. Quelle non sono matrici di pixel, perché il concetto di pixel non esiste nemmeno in un tale formato. Spetta al renderer capire come produrre l'immagine su uno schermo o qualsiasi altro supporto.

Anche senza menzionare domini di colore, compressione, dimensioni dei bit e formato del canale, esiste una serie di formati di file totalmente diversi dalle pixel map. Eppure i formati vettoriali sono anche molto "migliori" nel rappresentare determinati tipi di immagini, tipicamente prodotte da un computer e non da una fotocamera.

A questa domanda è stata data una risposta abbastanza dettagliata prima. Tuttavia, nonostante ci sia molta teoria presentata nelle risposte, ritengo che ci siano alcuni argomenti di base, in genere legati alla programmazione informatica che richiedono maggiori chiarimenti. Devo dichiarare che sono un ingegnere del software. Dopo aver letto la domanda mi sono reso conto che c'è stato un malinteso sui tipi di dati di programmazione di base che hanno generato questa domanda.

La prima domanda qui è:

Inoltre, dal punto di vista numerico, cosa rende qualcosa di simile a un'immagine a 16 bit diversa dalle immagini a 32 bit? Ancora una volta, un'immagine è solo un array con valori interi compresi tra 0 e 255.

Come presentato prima: No non lo è. Un'immagine non è solo una matrice di valori interi compresi tra 0 e 255. In realtà può essere un array singolo o multidimensionale da 0 a 65535 valori, un array da 0 a 4294967295 o persino un array di bit (un bit può contenere 0 o 1 valori, tutto qui) che viene convertito dal software in grado di leggere i file di immagine in numeri interi secondo varie regole di codifica.

Per comprenderlo ulteriormente, come affermato in precedenza, penso che sia necessaria una discussione sui tipi di dati di programmazione di base. Proverò a spiegarli nel modo più semplice possibile in modo che tutti comprendano i problemi legati alla memorizzazione dei valori interi nei file dei computer.

Nella programmazione informatica utilizziamo alcuni tipi di dati primitivi di base per scrivere valori in file, leggerli dai file nella memoria del computer, manipolare tali valori utilizzando vari tipi di dati specifici di linguaggi di programmazione e infine salvarli in file. I numeri interi nella programmazione per computer non sono solo numeri interi. Esistono tutti i tipi di numeri interi, dipende dal linguaggio di programmazione che stiamo utilizzando e dalla quantità di memoria necessaria per ciascuno di essi. In genere, nella maggior parte dei linguaggi di programmazione abbiamo i seguenti tipi di dati (e modi per manipolarli):

• BIT - tenendo premuto 0 o 1
• UINT8 - numero intero senza segno a 8 bit: possono contenere valori compresi nell'intervallo [da 0 a 255].
• INT8 - numero intero con segno a 8 bit - possono contenere valori compresi nell'intervallo [-126-127].
• UINT16 - numero intero senza segno a 16 bit: possono contenere valori compresi nell'intervallo [da 0 a 65535].
• INT16 - numero intero senza segno a 16 bit: possono contenere valori compresi nell'intervallo [da -32768 a 32767].
• UINT32 - Numero intero senza segno a 32 bit: possono contenere valori compresi nell'intervallo [da 0 a 4294967295].
• INT32 - Numero intero senza segno a 32 bit: possono contenere valori compresi nell'intervallo [−2147483648 ... 2147483647].
• O una combinazione di tutti quei tipi di dati in un formato più complesso. Ad esempio un UINT16 (16 BIT) con 3 valori diversi, i primi 4 BIT con valori compresi tra 0 e 127, il BIT successivo con 0 o 1 e così via.

Inoltre, c'è qualcosa che i programmatori devono affrontare quando leggono o scrivono tipi di dati interi da file. L'endianessa.L'endianness si riferisce all'ordine sequenziale in cui i byte (UINT8 dalla nostra tabella) sono disposti in valori numerici più grandi quando memorizzati in memoria o file. L'endianità è di interesse nell'informatica perché due formati contrastanti e incompatibili sono di uso comune: i valori possono essere rappresentati in formato big-endian o little-endian, a seconda che bit o byte o altri componenti siano ordinati dal big-end (il più significativo bit) o ​​l'estremità piccola (bit meno significativo). In poche parole puoi memorizzare un valore come questo 0000000011011111 o ... come questo 1101111100000000 a seconda dell'ordine endian che hai scelto. E sei libero di scegliere qualsiasi ordine adatto al tuo scopo. Non ci sono altre regole che si creano quando si progetta un formato di file immagine.

Si noti che nella programmazione per computer numeri interi utilizzano più o meno spazio, dipende dal valore. Come se avessi bisogno di più carta per scrivere 255255255 hai bisogno di più BIT per scrivere un valore maggiore. Successivamente, quando si desidera leggere il valore, è necessario conoscere esattamente le regole create durante la scrittura. Altrimenti è impossibile per te capire come leggere solo un array con valori interi compresi tra 0 e 255 perché semplicemente non sai dove sono memorizzati quei numeri e come quei numeri sono memorizzati, dato che hai così tante scelte (BIT, UINT8 , UINT16, UINT32 o una combinazione di tutti quei tipi di dati del computer). E non dimenticare, Endianness. Se non sai che i dati sono stati scritti usando l'ordine big-endian o little-endian non puoi leggere il valore corretto.

A causa di queste immagini non sono MAI solo un array con valori interi compresi tra 0 e 255. Alcuni di essi sono array di UINT16 (immagini a 16 bit) altri sono array di UINT32 (immagini a 32 bit) o ​​altri sono array di UINT8 (immagini a 8 bit). Alcuni programmatori di computer molto creativi possono persino usare tipi firmati che ti vivono con array di INT8, il che significa una matrice di valori tra -126 e 127.

In realtà quando leggi un file di immagine, uno dei primi dati che incontri è di solito alcuni BIT che rappresentano la larghezza e l'altezza dell'immagine. E quelli non sono solo alcuni valori 0-255. Questi sono anche alcuni tipi di dati scelti dal programmatore. Alcuni programmatori riterranno che 16 BIT siano enogh per la memorizzazione di una larghezza massima dell'immagine di 65535 pixel, perché stanno progettando un formato immagine usato in un gioco per conservare alcune immagini di piccoli pulsanti. Alcuni altri programmatori possono utilizzare un valore a 32 bit qui che consente di memorizzare immagini fino a una larghezza e un'altezza di 4294967295. Alcuni pazzi programmatori della NASA possono persino utilizzare 64 bit per archiviare una foto enorme della galassia fino a 18446744073709551615 pixel.Se non conosci le regole, non puoi leggere quei "valori" come li chiami. Perché non sai dove iniziano nel file di immagine e dove finiscono. Quindi finisci con un mucchio di BIT di cui non capisci niente.

Ecco perché l'universo è pieno di così tanti formati di immagini diverse. Perché non esiste una soluzione standard per scrivere alcuni valori interi in un file. È la scelta del programmatore interamente basata su molti fattori come l'Endianess della macchina su cui stai lavorando, il linguaggio di programmazione che stai usando per progettare l'implementazione del formato file originale e molte altre cose come lo scopo del formato immagine (come chiaramente affermato prima da altre risposte).

Un pratico formato file semplice di un'immagine in bianco e nero che contiene un solo valore 166 per rappresentare un'immagine 4x2 pixel:

L'immagine (1 - pixel nero, 0 - pixel bianco):

1010 
0110

Questo formato di file utilizza 1 BIT per PIXEL memorizzato come SINGOLO valore intero 8 bit 166 (10100110). È tutto. Non viene utilizzato alcun array di valori 0-255 ma 8 valori 0 o 1 diversi memorizzati come valore 166.

Se hai usato un array di 0-255 valori per ogni pixel * 3 volte per RGB, otterrai un'immagine 24 volte più grande. Questo formato di file ha appena risparmiato 24 volte lo spazio su disco necessario per salvare un'immagine come questa o 24 volte meno la memoria del computer necessaria per leggere e conservare questa immagine nella RAM del computer quando si utilizza questa immagine, ad esempio nel motore di gioco 3D ad alte prestazioni per disegna qualcosa sullo schermo con esso (texturing migliaia di particelle di polvere che volano intorno potrebbero essere un buon candidato :)).