Link alla notizia: http://www.hwupgrade.it/news/software/14498.html

I fotografi professionisti hanno creato il OpenRaw Working Group il cui scopo sarà quello di sensibilizzare i vari produttori di macchine fotografiche nella realizzazione di un formato Raw unico

Click sul link per visualizzare la notizia.

Secondo me, il RAW sarà ( e per alcuni già lo è) l'equivalente del negativo analogico. In una ottica di ricerca di qualità e professionalità si può dire che il RAW stia al jpeg come il CD sta all'Mp3. Molto più comodi i compressi ma la politica del tutto e subito, anche se di bassa qualità, non avvantaggia una vera cultura baricentrica l'arte ma solo al suo consumo ( a volte cannibale).

Il RAW, in sé e per sé, non è niente, è una descrizione di un formato non compresso non postprocessato.Quello che appunto manca è un formato RAW standard: ogni casa ha la propria implementazioen di RAW incompatibile con le altre.

Il RAW serve per preservare i dati nel tempo
(per esempio tra 1000 anni come faranno
a leggere il contenuto di un file JPEG?),
ma non credo sia di nessuna utilita'
circa la quantita di informazioni preservate
rispetto ad altri formati:
esiste un formato libero da brevetti, copyright,
e quant'altro ed e' il PNG, e chiunque sa
che e' compresso e non-lossy.
Basterebbe che si mettessero d'accordo per includervi
i parametri della macchina fotografica se
necessari (tempo di esposizione, ottica, etc.)
e si potrebbe usare benissimo al posto del TIFF/LZW:
invece quante sono le macchine digitali
che lo supportano? ZERO.

I fotografi non vogliono immagini compresse, anche se lossless.

e si potrebbe usare benissimo al posto del TIFF/LZW:
invece quante sono le macchine digitali
che lo supportano? ZERO.

Sboglio o TIFF non permette più di 8 bit per ogni colore primario?

Tutti i formati RAW lavorano minimo a 12 bit per canale...

I fotografi non vogliono immagini compresse, anche se lossless.

Mi sembra una s**zata. Vero che nei formati compressi se perdi un
singolo bit e' probabile che la quantita di informazioni perduta e' molto piu'
elevata, ma lo stoccaggio necessario e' enorme.
5 Mpixel per 24 piani grafici fanno 15MB. E se,
come credo, arriveranno ben presto le macchine a 12 e 16 bit per pixel
per componente, ovvero a 36 e 48 bit di profondita' colore, e i 10-12MPixel
diventeranno lo standard, siamo ben presto a 70MB per foto in RAW.
Ossia un'intero DVD per "rullino" di 40-50 foto.

Sboglio o TIFF non permette più di 8 bit per ogni colore primario?

Tutti i formati RAW lavorano minimo a 12 bit...

Quello dipende dal CCD. Se il CCD e' a 12 allora se ne potranno immagazzinare
12. Ma nessuno ci vieta di fare il PNG a 48 bit di profondita' o 64bit
per componente o quelli che ci pare. Basta solo mettersi d'accordo, e
il PNG, a differenza di JPEG, JPEG2000 o similari, e libero da brevetti.
Purtroppo ai venditori di macchine fotografiche digitali non frega
nulla la standardizzazione, anzi, piu formati ci sono meglio e', cosi
uno stesso prodotto sei costretto ad acquistarlo 25 volte, altrimenti
nelle macchine fotografiche meno costose (per intenderci quelle da 200-300E),
avrebbero messo il supporto del PNG, invece che limitarsi al solo
JPEG-fine. In quelle piu' costose, ma siamo > 500-600E, qualcuno mette
il TIFF/LZW...

Inoltre per fare un formato RAW-open penso ci voglia
non piu' di un quarto d'ora.
Basta fare un formato in cui l'intestazione e' in
ASCII, che contiene minimo le informazioni circa
la risoluzione, e la profondita' e l'ordine. Il resto sono solo dati binari appesi.

Sboglio o TIFF non permette più di 8 bit per ogni colore primario?

Tutti i formati RAW lavorano minimo a 12 bit per canale...

Sono andato a ricontrollare. Il PNG permette gia' attualmente
16bit di profondita' per componente (quindi 48bit RGB).

il RAW è un formato compresso lossless

Mi sembra una s**zata. Vero che nei formati compressi se perdi un
singolo bit e' probabile che la quantita di informazioni perduta e' molto piu'
elevata, ma lo stoccaggio necessario e' enorme.
5 Mpixel per 24 piani grafici fanno 15MB. E se,
come credo, arriveranno ben presto le macchine a 12 e 16 bit per pixel
per componente, ovvero a 36 e 48 bit di profondita' colore, e i 10-12MPixel
diventeranno lo standard, siamo ben presto a 70MB per foto in RAW.
Ossia un'intero DVD per "rullino" di 40-50 foto.

Trovo giusto invece che ci sia un formato senza perdita di qualità e sopratutto standard,per quanto riguarda i MB occupati si è sempre liberi di usare altri formati e poi finiamola con la corsa ai Mpixel e pensiamo alla qualità!!!La verità è che è molto più facile alzare i Mpixel di una macchina fotografica e giustificarne banalmente il prezzo che fare una macchina con ottica perfetta!Allora si che anche una foto a 4 Mpixel si vedrebbe benissimo con formato non compresso!Io dei "poster" non me ne faccio nulla.

il RAW è un formato compresso lossless

Insomma decidiamoci. Se RAW e' compresso allora non si
dovrebbe chiamare RAW. E tanto meno serve creare un nuovo
formato compresso visto che ne esiste gia uno di compresso
lossless: ed e' il PNG, che e' gia' Open.

Se non e' compresso, come ho gia detto non ci vuole poi molto
a crearne uno standard. Come ho gia' detto basta
mettere dei TAG ASCII nel file che definiscano, la risoluzione,
l'ordine della profondita' (ossia se si mettono prima
le immagini per componente come se fossero 24 o 48 immagini in bianco
e nero) e l'ordine dei bytes (big/little endian).

Come ho gia' detto basta
mettere dei TAG ASCII nel file che definiscano, la risoluzione,
l'ordine della profondita' (ossia se si mettono prima
le immagini per componente come se fossero 24 o 48 immagini in bianco
e nero) e l'ordine dei bytes (big/little endian).

Praticamente, .xml :D

Trovo giusto invece che ci sia un formato senza perdita di qualità e sopratutto standard,per quanto riguarda i MB occupati si è sempre liberi di usare altri formati e poi finiamola con la corsa ai Mpixel e pensiamo alla qualità!!!La verità è che è molto più facile alzare i Mpixel di una macchina fotografica e giustificarne banalmente il prezzo che fare una macchina con ottica perfetta!Allora si che anche una foto a 4 Mpixel si vedrebbe benissimo con formato non compresso!Io dei "poster" non me ne faccio nulla.

Francamente non riesco a capire la tua affermazione.
Il formato PNG e' senza perdita di qualita' (seppur compresso).
L'algoritmo di compressione e' noto, collaudato e privo di alcun tipo di
vessazione legale. Lo leggi e lo salvi all'infinito e otterrai sempre lo stesso file. Ed e' standard ed e' open. Perche' dobbiamo sempre reinventare la ruota?

Quanto ai megapixel, il prezzo di vendita delle macchine
ha potuto raggiungere i prezzi che vediamo proprio perche' praticamente
non hanno praticamente ottica. Appena si mette un'ottica decente i prezzi
salgono esponenzialmente, come con le macchine tradizionali.

Praticamente, .xml :D

Si ma senza sapere l'XML, cosi', minimo:

XResolution: 2272
YResolution: 1704
Depth: 12
ByteOrder: BigEndian|LittleEndian
BitMapOrder: chunky | plane
Data: ASCII7|Ascii8|Binary
DATA
ò1234671n77z9x13kò1k23
213779813hhbbsfd7791982
1239812838812388123881
1328788888800182808018

che ci vuole? Eventualmente ci possono aggiungere
tutte le altre estensioni relative all'ottica, alla data
dello scatto, al tempo di esposizione, all'apertura del diaframma, etc.

Si ma senza sapere l'XML, cosi', minimo:

cut

che ci vuole? Eventualmente ci possono aggiungere
tutte le altre estensioni relative all'ottica, alla data
dello scatto, al tempo di esposizione, all'apertura del diaframma, etc.

Appunto... sono solo un pò di tag personalizzati, questa è una delle grandi potenzialità di xml ;)
Ed in questo modo si ha un formato standard scalabile all'infinito secondo le future necessità...


Mezz'ora per stabilire questi tag
Andiamo nella sezione programmazione del forum
Pigliamo due che ci sanno fare
Gli chiediamo di scrivere dei tool per convertire da/a un dato formato a questo
Formato RAW standard aperto creato :cool:

Appunto... sono solo un pò di tag personalizzati, questa è una delle grandi potenzialità di xml ;)
Ed in questo modo si ha un formato standard scalabile all'infinito secondo le future necessità...


...
Gli chiediamo di scrivere dei tool per convertire da/a un dato formato a questo
Formato RAW standard aperto creato :cool:


Non e' che ci vuole una scienza per scrivere un simile tool. Basta prendere
ImageMagick (che e' Open) e' c'e' gia' tutte le librerie per convertire a qualsivoglia
formato. Aggiungere il supporto per questo nuovo formato "RAWHW" (HW=hardware
upgrade) per ImageMagick credo che sia abbastanza semplice.

... almeno per come vorrei che fosse...
da quel poco che so il raw nonè altro che la diretta lettura del CCD o del Cmos, quindi dipente dalla tecnologia impiegata. Non basta definire solo la profondita di ogni singolo colore, (il tiff lavora anche a 16 bit canale sia in RGB che in CMYK) ma bisogna tener conto di come sono disposti i singoli pixel sul CCD e sulle loro peculiarità. Faccio un esempio, se non sbaglio la sony DSC-F828 ha un nuovo filtro CCD a 4 color... altri tipo Fuji a CCD con pixel di diversa forma e dimensione...
quindi a mio avviso unificare tutto su un formato Lossy è possibile ed esiste nel tiff, che ha tutta la profondità colore necessaria, senza contare ai fattori di compressione e agli spazi colore. Mentre se non si vuolestrozzare la tecnologia si considera il raw per quel che è ossia la lettura del ccd punto e basta.
La più degna descrizione del raw l'ha fatta un mio amico fotografo, per lui il raw è la "pellicola" prima dello sviluppo, lavorando in row si può "tirare" un po' lesposizionesenza perdere troppo di qualità e lavorare su altri parametri come la distorsione dell'ottica (Olympus)...

QUINDI A OGNUNO IL SUO RAW

bravo bluebox, almeno tu sai quello che scrivi. Ai fotografi non gliene frega niente di PNG o Jpeg, loro hanno bisogno di un formato ad altissima qualità, e cosa che penso nessuno abbia pensato ad altissima velocità. Aspettare un decimo di secondo per comprimere l'immagine per qualcuno non può voler dire niente, ma per un professionista può voler dire aver perso uno scatto. Il raw serve a questo, nessuna perdita d'informazione e salvataggio immediato della foto, e chissenefrega di quanto occupa, penso che la schedina di un fotografo parta dal Giga in su. Son d'accordo con bluebox che il raw sia strettamente legato all'hd della macchina, per questo penso sia difficile trovare un formato un'iversale

guarda che il formato che ti permette una raffica + veloce e + lunga e proprio il JPG...
Il JPG è uno standard di fatto e durera ancora per un bel pò e sara leggibile per un tempo acora + lungo. Il RAW dal canto suo ha il vataggio di una qualità maggiore (12/16 BIT, latitudine maggiore ecc.)ma con il rischio di una longevità non ben definita. Secondo me il RAW non è la soluzione.

basterebbe che i produttori rilasciassero le specifiche dei vari formati, in modo che chiunque possa lavorarci sopra, e che conservino il supporto a vecchi formati

guarda che il formato che ti permette una raffica + veloce e + lunga e proprio il JPG...
Il JPG è uno standard di fatto e durera ancora per un bel pò e sara leggibile per un tempo acora + lungo. Il RAW dal canto suo ha il vataggio di una qualità maggiore (12/16 BIT, latitudine maggiore ecc.)ma con il rischio di una longevità non ben definita. Secondo me il RAW non è la soluzione.
Tralasciando il fatto che il jpeg non è neanche lontanamente utilizzabile per un ambito professionale, per motivi qualitativi, è importante considerare il fatto che una volta che tu generi un jpeg significa che hai fatto una INTERPRETAZIONE delle informazioni che ti ha dato il sensore CCD. Ci sono regolazioni che vanno fatte PRIMA di generare l'immagine (non sono un esperto, ma credo che il bilanciamento del bianco si una di esse), quindi il formato RAW serve eccome.

bravo bluebox, almeno tu sai quello che scrivi. Ai fotografi non gliene frega niente di PNG o Jpeg, loro hanno bisogno di un formato ad altissima qualità, e cosa che penso nessuno abbia pensato ad altissima velocità. Aspettare un decimo di secondo per comprimere l'immagine per qualcuno non può voler dire niente, ma per un professionista può voler dire aver perso uno scatto. Il raw serve a questo, nessuna perdita d'informazione e salvataggio immediato della foto, e chissenefrega di quanto occupa, penso che la schedina di un fotografo parta dal Giga in su. Son d'accordo con bluebox che il raw sia strettamente legato all'hd della macchina, per questo penso sia difficile trovare un formato un'iversale

Lo volete capire che il PNG non perde informazioni?
Se un fotografo non arriva a capirlo credo che sappia tutto
di fotografia analogica ma ben poco di trattamento digitale
delle immagini... ;-)
Che poi dal formato raw al TIFF (non al PNG, perche' sono babbei e
e nessuno ha ancora implementato il PNG nel firmware delle
macchine digitali...) introducano dei
filtraggi, ma se dal CCD leggo un bit a ZERO o a UNO quello
sara' a zero o a uno anche nel PNG, TIFF, o qualunque altro
formato non lossy utilizzato. Se il CCD e' a 16bit di profondita' colore
per componente e nella memoria ti trovi il file con solo 8 bit di profondita',
quello e' comunque LOSSY, qualunque sia il formato scelto.
Ed e' un'altro discorso. E' chiaro che con immagini a 16bit di profondita'
colore si possono per esempio fare delle foto in notturna e rielaborarle praticamente
a giorno (mi ricordo un'immagine di una citta' notturna a 16bit
di profondita' colore e rielaborata con PhotoGenics a giorno, preservando
una quantita' incredibile di dettagli).

Quanto alla velocita', vero che la compressione porta via
tempo, ma anche il trasferimento di file di dimensioni
enormi, proprio perche non compresse, porta via altrettanto tempo.

Non è detto che il jpeg sia il migliore, ne il più veloce...

Il RAW essendo una lettura di CCD non richiede manipolazioni, quindi la velocità è relativa a quella di scrittura su memoria.

Io ho una canon G6, e uso spesso il RAW per poi affinare un po' le luci, e vedo che le dimensioni non sono tutte uguali, presumo quindi che venga effettuata una sorta di compressione dipo LZW.

Il RAw più grosso che ho con la mia 7MPixel è di 8.284Kb relativi a immagini a colori a 16bit.
I tiff convertiti sono dei 3072x2304 a 16 bit, il che equivale ad un raster di 42.467.328 Byte ossia 42 mega.
Un jepeg decente (10/1) sarebbe quindi un 4,2Mbyte.. ecche che quindi il raw è interessante e molto..

senza contare che in realta la mia è un 7megapixel, ma per tutti e tre i colori, quindi è un'interpolazione di qualcosa più di 2, rotti megapixel per colore.

Quindi il jpeg significa... scatta, rasterizza a 42mega, comprimi e salva circa la metà del raster, ma a sto punto se la memoria ce la fa vorrei salvare il raster magari a raffica (na 10 di scatti)

OK...
allora vediamo un pò:
2 fotografi professionisti freelance al bordo del campo dove si disputa Milan-Juve, tutti e 2 hanno una 1dMII, uno scatta in Raw e l'altro scatta in JPG, secondo te chi porta a casa la pagnotta?
Senza toglire nulla al "solito" professionista di fotografia naturistica che scatta la sua bella foto....naturalmente in RAW.

... qualcosa di molto diverso da un tiff, invece sarebbe interessante affinare un po' il Jpeg.
Lasciando stare il RAW che per forza di cose deve essere legato al CCD, è importante invece migliorare il più possibile il formato di interscambio "veloce per eccellenza". La fotografia si digitale si legherà sempre di più ad internet.

non ci sarà solo il reporter che deve spedire le foto per l'articolo, magari su quotidiano dove la qualità conta poco, ma presto molti di noi scatteranno, spediranno via mel e ritireranno/riceveranno lo scatto stampato su carta fotografica da un service o dal fotografo di fiducia.
Milioni di anni fa (all'epoca di corel photopaint 5 c'ere il formato wavelet, che se non sbaglio è parente del jpeg200 (tre volte più efficente)...
Spero, visto che ormai di anni ne son passati, che li diorri fotografi si dedichino a un vero formato di interscambio, piuttosto che incasinarsi la vita sul formato raw universale. Daltra parte pretendere che sony usi lo stesso raw di Fujitsu è come pretendere che Mamya (magari 645) usi gli stessi attacchi per le ottiche di canon per una reflex 35mm...

Non è detto che il jpeg sia il migliore, ne il più veloce...

Il RAW essendo una lettura di CCD non richiede manipolazioni, quindi la velocità è relativa a quella di scrittura su memoria.

Io ho una canon G6, e uso spesso il RAW per poi affinare un po' le luci, e vedo che le dimensioni non sono tutte uguali, presumo quindi che venga effettuata una sorta di compressione dipo LZW.

Il RAw più grosso che ho con la mia 7MPixel è di 8.284Kb relativi a immagini a colori a 16bit.
I tiff convertiti sono dei 3072x2304 a 16 bit, il che equivale ad un raster di 42.467.328 Byte ossia 42 mega.
Un jepeg decente (10/1) sarebbe quindi un 4,2Mbyte.. ecche che quindi il raw è interessante e molto..

senza contare che in realta la mia è un 7megapixel, ma per tutti e tre i colori, quindi è un'interpolazione di qualcosa più di 2, rotti megapixel per colore.

Quindi il jpeg significa... scatta, rasterizza a 42mega, comprimi e salva circa la metà del raster, ma a sto punto se la memoria ce la fa vorrei salvare il raster magari a raffica (na 10 di scatti)

Se le dimensioni non sono sempre uguali significa che comprime (non lossy, foss'anche
RLE, ma comprime) ed e' quindi improprio chiamarlo RAW. Le dimensioni
del RAW dovrebbero essere uguali alle dimensioni di quello che ti hai
chiamato "raster". Se comprime si fa una elaborazione. Ed elaborazione
per elaborazione tanto vale usare uno dei formati non-lossy standard
(il livello di compressione non-lossy, e quindi la conseguente
velocita' di compressione, si puo' impostare) e aggiungere ad essi i parametri del
CCD. La quantita' di informazioni e' la medesima, ma almeno si usa uno
standard.

... qualcosa di molto diverso da un tiff, invece sarebbe interessante affinare un po' il Jpeg.
Lasciando stare il RAW che per forza di cose deve essere legato al CCD, è importante invece migliorare il più possibile il formato di interscambio "veloce per eccellenza". La fotografia si digitale si legherà sempre di più ad internet.

non ci sarà solo il reporter che deve spedire le foto per l'articolo, magari su quotidiano dove la qualità conta poco, ma presto molti di noi scatteranno, spediranno via mel e ritireranno/riceveranno lo scatto stampato su carta fotografica da un service o dal fotografo di fiducia.
Milioni di anni fa (all'epoca di corel photopaint 5 c'ere il formato wavelet, che se non sbaglio è parente del jpeg200 (tre volte più efficente)...


Il wavelet (in italiano "ondine") non e' un formato. E' solo un metodo matematico
di approssimazione di una funzione. E' comunque di tipo "lossy". Il JPEG2000
utilizza le wavelets e permettono a parita di perdita di informazioni,
rapporti di compressione superiori, o se preferite, a parita' di dimensioni,
perdite di informazioni minori. Ma di formati ce ne sono altrettanti,
chi si ricorda la compressione frattale? Anche il formato ECW, utilizzato
per le mappe geografiche utilizza la compressione "wavelet".

per na foto da gazzetta basta una buona ottica e culo, ovvio che un fotoreporter se ne frega della qualità pura, ha bisogno di una macchina piuttosto che gli scarica na raffica, per becare il calcettino indovinato o la rissa di turno..per poi stampare su carta rosa ecc.

stessa cosa per chi cerca di beccare le tette della rifatta di turno, gli conta di più la tonnellata di ottica che ha sul cavalletto, che non il pocio che ha dietro.. poi dipente cosa uno vuol fare. Il mio famoso amico fotografo, come la stragrande maggioranza di suoi colleghi scatta con un D10 di canon in RAW magari per matrimoni o rievocazioni di auoto storiche, a fine cena di solito consegna gia foto scattate in chiesa e fuori, (il busines collaterale di mamme zie appassionati ecc.) ma visto che non ha tempo da perdere e soprattutto stampa su carta fotografica, ovvio che per portare a casa la pagnotta scatta in raw...

La mia comunque non vuole essere na guerra tra RAW e altro, ma semplicemente na disquisizione su formati e sulla in'unutilità per conto mio dio un Working Group dedicato al raw, ma piuttosto a un Working Group dedicato al JPEG2000 o wavlet, cosi il freelens che sta a bordo campo la foto se la manda via mms tre secondi dopo la fine dell'azione..

... ossia

.. da quel poco che ho capito il RAW non è un raster, ma la lettura dei dati del CCD, che poi sia zippato è un'altro paio di maniche. Appunto perche è la lettura di 2,39 Mpixel per colore, va ancora "rasterizzata" e è per questo che occupa un po' meno di un tiff.
Ho citato il "wavelet" a memoria perche a quell'epoca cosi veniva chiamato dalla corel, se non sbaglio l'estensione del file era .wvl ??

Tanto per chiarire un po' le idee:

http://www.adobe.com/products/photoshop/pdfs/understanding_digitalrawcapture.pdf

L'ambiguita' nasce dal fatto che si chiama RAW, una
cosa che non e' RAW. Per mettersi d'accordo
e' sufficiente usare uno dei formati di
compressione non lossy. E il candidato secondo
me e' il PNG. Quello su cui invece bisogna mettersi
d'accordo sono le informazioni aggiuntive
(esposizione, bilanciamenti vari, etc.).
Se poi i cervelloni dell'Adobe vogliano reinventare
la ruota, per poter imporre un formato open,
ma di cui vogliono avere comunque il controllo, quella
e' solo una presa per il C*LO in quanto dietro non
c'e' nessuna motivazione TECNICA.

Per le dispute tra TIFF e PNG. Il TIFF utilizza
l'algoritmo di compressione LZW, che e' brevettato,
mentre il PNG utilizza il Deflate. Come rapporti
di compressione sono simili, ma il PNG e' preferibile
in quanto non ha problemi di brevetti (che poi
in quasi tutti i paesi i brevetti
sull'algoritmo LZW sono scaduti, e' di poca
importanza. IBM per esempio dice di averne
ancora di brevetti che lo riguardano, anche
se non li fa valere).

il bello del raw è che contiene dati non processati, ma appunto "grezzi" cioè come li ha "visti" il ccd.. per ora ci sono tot algoritmi per ottenere immagini (anche tiff non compresse), chissà che in futuro non ne escano di migliori? oppure partendo dallo stesso negativo si possono ottenere foto digitali con ad es. esposizioni e correzioni del bianco diverse.. la maggior parte delle potenzialità del raw sta nell'embrionalità dei dati contenuti nei file..
fare queste cose con un tiff o peggio un jpeg è come prendere una fotografia già scattata, e rimanipolarla per ottenere un altro risultato.. la qualità non sarà mai uguale a quella che si ottiene partendo dal negativo

Per fare l'analogo musicale:
Il raw sono le tracce dei singoli strumenti, il cd è il png (o il tiff) e il jpg è l'mp3.
A seconda di come mixi (converti) i canali rgb del ccd ottieni un cd diverso.
Se equalizzi (applichi dei filtri) ad un cd (un png, un jpg è anche peggio) non riuschirai mai ad avere un risultato analogo ad un remix delle tre traccie (raw) originali.
Per questo un png anche se losses e con una risoluzione anche superiore all'originale raw (16bit vs 12bit) sarà sempre inferiore.

Ciao a tutti!

Inoltre per fare un formato RAW-open penso ci voglia
non piu' di un quarto d'ora.
Basta fare un formato in cui l'intestazione e' in
ASCII, che contiene minimo le informazioni circa
la risoluzione, e la profondita' e l'ordine. Il resto sono solo dati binari appesi.
Se è solo questo, esiste da decenni nel campo della computer grafica il famosissimo (!), usatissimo (!) e standard PPM: http://astronomy.swin.edu.au/~pbourke/dataformats/ppm/ :D

Francamente non riesco a capire la tua affermazione.
Il formato PNG e' senza perdita di qualita' (seppur compresso).
Puoi anche non comprimere i dati... ;)

Il wavelet (in italiano "ondine") non e' un formato. E' solo un metodo matematico
di approssimazione di una funzione. E' comunque di tipo "lossy".
Non è così: esistono centinaia di tipi di wavelet, e JPEG 2000 ne usa due, una di tipo reversibile (lossless) e una di tipo irrerversibile (lossy).

.. da quel poco che ho capito il RAW non è un raster, ma la lettura dei dati del CCD, che poi sia zippato è un'altro paio di maniche.
Sì, ma c'è una cosa che non avete considerato: esistono diversi CCD che trasmettono dati in maniera diversa.

Pensate che in uscita si trovino le componenti RGB belle e pronte? Niente di più sbagliato: la maggior parte dei CCD in uscita presenta i dati di un'immagine sostanzialmente "monocromatica" (guardandola "così com'è"), con le componenti colore memorizzate con il Boyer pattern.

Non solo: Sony lo scorso anno ha annunciato l'introduzione di CCD che hanno una QUARTA componente colore (sul Magenta, se non erro), per ottenere una maggior qualità nella ricostruzione del colore delle immagini.

Definire un formato universale per il formato RAW non è affatto facile e veloce...

Per le dispute tra TIFF e PNG. Il TIFF utilizza l'algoritmo di compressione LZW, che e' brevettato, mentre il PNG utilizza il Deflate.
Come rapporti di compressione sono simili, ma il PNG e' preferibile in quanto non ha problemi di brevetti (che poi in quasi tutti i paesi i brevetti sull'algoritmo LZW sono scaduti, e' di poca importanza. IBM per esempio dice di averne ancora di brevetti che lo riguardano, anche
se non li fa valere).
Non è così: TIFF permette di comprimere le immagini anche col formato ZIP / deflate. Come pure col formato JPEG, o col CCITT (mi sembra che si scriva così) usato per i fax.

Per fare l'analogo musicale:
Il raw sono le tracce dei singoli strumenti, il cd è il png (o il tiff) e il jpg è l'mp3.
A seconda di come mixi (converti) i canali rgb del ccd ottieni un cd diverso.
Se equalizzi (applichi dei filtri) ad un cd (un png, un jpg è anche peggio) non riuschirai mai ad avere un risultato analogo ad un remix delle tre traccie (raw) originali.
Per questo un png anche se losses e con una risoluzione anche superiore all'originale raw (16bit vs 12bit) sarà sempre inferiore.

Ciao a tutti!
Non è così: il PNG non ha ALCUNA PERDITA d'informazione rispetto al formato RAW utilizzato per i dati in uscita dal sensore della fotocamera digitale.

Il RAW, per un fotografo, sta come la registrazione live (il Master insomma, però ascoltandolo direttamente nella sala d'incisione mentre viene eseguito) di un pezzo che poi finirà dentro un CD. Ovvero il "primissimo" passo, nel cui frammezzo non esiste niente. Il formato RAW non è certo usato dal fotografo di strada (non almeno il 90% delle volte) o sportivo, ma è usato, per esempio, da chi fa servizi fotografici di moda, in uno studio. In questi casi molte volte non si salva nemmeno la foto su un supporto di memorizzazione ma viene riversata direttamente sul computer (Mac o, meno spesso, PC) direttamente dalla macchina fotografica (anche se quasi sempre insieme a questo si fa una foto in qualità inferiore da vedere immediatamente, tipo Polaroid, per poter avere cmq un'idea immediata di com'è venuta).

Non è così: il PNG non ha ALCUNA PERDITA d'informazione rispetto al formato RAW utilizzato per i dati in uscita dal sensore della fotocamera digitale.

Forse mi sono spiegato male

esempio:
sensore ccd con struttura:
RGBGRGBGRGB
GBGRGBGRGBR
BGRGBGRGBRG

tramite un algoritmo viene ricreata un'immagie che poi salvi come vuoi, diciamo in png:
PPPPPPPPPPP
PPPPPPPPPPP
PPPPPPPPPPP

dove P è un pixel che contiene le informazioni RGB.
Se io ho un png ma non so qual'è l'algoritmo utilizzato per la conversione ne so qual'è la macchina fotografica con cui è stata scattata non riesco a ricreare "l'immagine originale".
Ecco perchè perdo informazioni rispetto al raw.
A meno che nel png non inserisca i metadati giusti per la conversione...

... e la conversione sia reversibile. Non è detto che lo sia!

Non è così: esistono centinaia di tipi di wavelet, e JPEG 2000 ne usa due, una di tipo reversibile (lossless) e una di tipo irrerversibile (lossy).
Sei sicuro che JPEG 2000 usa le wavelet anche per la compressione lossless? Sto pensando al fatto che usando una codifica a 8 bit per i coefficienti della DCT in JPEG si ottiene comunque un errore che nel caso peggiore può essere di +/- 4. Salvare i coefficienti con precisione sufficiente ad evitare errori di approssimazione non conviene.
Non è detto che il discorso valga in generale per le wavelet: la wavelet Haar (la più semplice) è perfettamente reversibile.

Non ho esperienza nel campo della fotografia digitale, le uniche informazioni che ho sono solo utili ad un acquisto di una macchinetta fotografica digitale neanche professionale. Tuttavia mi sembra evidente che manchi un formato alternativo al jpg, supportato dalle fotocamere, per lo scambio delle immagini. Non è opportuno usare un jpg per conservare i propri ricordi visto che di qualità ne perde parecchia, e ricorrere a tanti Mpixel per un formato del genere mi sembra un pò inutile. D'altro canto l'unico formato che potrebbe essere usato sarebbe il raw, ma che di difetti ne ha uno gravissimo e cioè la sua futura ipotetica incompatibilità. Questo non è difetto da poco, cosa ci conservi? PNG non sarebbe alternativo ma complementare agli altri due, andrebbe a coprire quel segmento di richiesta di un formato affidabile (quanta qualità potrà mai perdere?) e duraturo, è open. Caratteristiche indispensabili per un segmento di fascia media che, secondo me, il jpg e raw non possono offrire. Non scontro dunque, ma cooperazione.

Forse mi sono spiegato male

esempio:
sensore ccd con struttura:
RGBGRGBGRGB
GBGRGBGRGBR
BGRGBGRGBRG

tramite un algoritmo viene ricreata un'immagie che poi salvi come vuoi, diciamo in png:
PPPPPPPPPPP
PPPPPPPPPPP
PPPPPPPPPPP

dove P è un pixel che contiene le informazioni RGB.
Se io ho un png ma non so qual'è l'algoritmo utilizzato per la conversione ne so qual'è la macchina fotografica con cui è stata scattata non riesco a ricreare "l'immagine originale".
Ecco perchè perdo informazioni rispetto al raw.
A meno che nel png non inserisca i metadati giusti per la conversione...

Finalmente ci capiamo. Non sto dicendo che il PNG attuale e' esaustivo,
ma che se al PNG aggiungiamo dei dati (o metadati come li chiami tu
tu) che sono le informazioni che mancano (esposizione, etc.) si possono
ottenere esattamente le stesse informazioni del RAW
(o meglio dei "raw", visto che RAW e' un termine generico
per indicare formati proprietari), e in piu', il formato e' standard.
Sto solo dicendo che il formato PNG (piuttosto che il DNG di Adobe)
sarebbe il candidato ideale per questo
tipo di informazioni.

L'unita' di informazione e' il bit, e dal CCD escono dei bit. Poi posso
fare tutte le trasformazioni che mi pare, e passare nello spazio RGB, CMY, YUV,
o qualunque altro, ma sono trasformazioni "invertibili". Ovvero
applicando le trasformazioni inverse ottengo esattamente lo stesso
stream di bit originale. Conta solo questo.

Se è solo questo, esiste da decenni nel campo della computer grafica il famosissimo (!), usatissimo (!) e standard PPM: http://astronomy.swin.edu.au/~pbourke/dataformats/ppm/ :D

Infatti mi sono ispirato sia al PPM che al modo in cui
vengono immagazzinati i dati in PostScript... ;-)

Non è così: TIFF permette di comprimere le immagini anche col formato ZIP / deflate. Come pure col formato JPEG, o col CCITT (mi sembra che si scriva così) usato per i fax.

Vero, ma l'hanno aggiunto dopo, tant'e' che tutti i produttori
di sw commerciale si ostinano a usare nei TIFF l'LZH piuttosto che il deflate... ;-)

Sì, ma c'è una cosa che non avete considerato: esistono diversi CCD che trasmettono dati in maniera diversa.

Pensate che in uscita si trovino le componenti RGB belle e pronte? Niente di più sbagliato: la maggior parte dei CCD in uscita presenta i dati di un'immagine sostanzialmente "monocromatica" (guardandola "così com'è"), con le componenti colore memorizzate con il Boyer pattern.


Se ci spieghi anche cos'e' il Boyer pattern?


Non solo: Sony lo scorso anno ha annunciato l'introduzione di CCD che hanno una QUARTA componente colore (sul Magenta, se non erro), per ottenere una maggior qualità nella ricostruzione del colore delle immagini.


Sembra quasi come le stampanti EPSON in Esacromia...
E allora vuol dire che si prende l'RGB del PNG e si estende in un formato:

RGBX1X2X3...Xn

Dove Xi rappresenta una componente arbitraria definita tramite la sua lunghezza
d'onda. Purtroppo mi sembra che la battaglia sia piu' che altro per l'imposizione
di un proprio formato...(casualmente l'Adobe vuole imporre il
proprio "DNG", digital negative...
(http://www.adobe.com/products/dng/pdfs/dng_spec.pdf), che
e' un'estensione del TIFF...).

... il RAW è legato al ccd, quindi per forza è proprietario, o per contro si deve uniformare la tecnicadi costruzione dei CCD, alias bisogna castrare la ricerca.

... per il resto quasi tutte le macchine salvano in tiff e in Jpeg, che tutto sommato sono più che sufficenti per quel che devono fare.. apsettando Jpeg2000 o simili ..

Il png è nato per soperire al gif, quando sebrava che compuserve ne volesse far valere i diritti, fa sicuramente di più, ma è prettamente per questo che è nato.

per concludere quindi se proprio si deve fare un expert group, lo si faccia per trovare un sostituto più evoluto del jpeg, magari con la possibilità diimpostare diversi spazi colore, compressini lossy e lossless, guardando soprattutto a qugi algoritmi che permettono di avere grande qualità, ma anche grande velocità digestione. Sarebbe scarsamente utileun algoritmo che mi salva un file da 8Mpixel in 200k senza perdità di qualità, se la macchina ci mette ore per salvarlo.

Bye

Forse mi sono spiegato male

esempio:
sensore ccd con struttura:
RGBGRGBGRGB
GBGRGBGRGBR
BGRGBGRGBRG

tramite un algoritmo viene ricreata un'immagie che poi salvi come vuoi, diciamo in png:
PPPPPPPPPPP
PPPPPPPPPPP
PPPPPPPPPPP

dove P è un pixel che contiene le informazioni RGB.
Se io ho un png ma non so qual'è l'algoritmo utilizzato per la conversione ne so qual'è la macchina fotografica con cui è stata scattata non riesco a ricreare "l'immagine originale".
Ecco perchè perdo informazioni rispetto al raw.
A meno che nel png non inserisca i metadati giusti per la conversione...
Ho capito qual è il problema. Si può "risolvere" facilmente e velocemente trattando l'immagine come se fosse monocromatica (l'uscita di un CCD in Boyer pattern praticamente lo è).

Certamente non è una soluzione improntata all'efficienza (la ridondanza specifica di questo tipo di immagini non la si può sfruttare per ottenere elevati valori di compressione), ma ha il vantaggio di essere praticamente "universale": non importa in che modo siano disposti i dati, ma l'obiettivo è di conservali e renderli fruibili alle applicazioni che sapranno gestirli.

Si potrebbe pensare di effettuare un'operazione de-interleaving, "raggruppando" i pixel per componente colore, ma ciò ovviamente richiederebbe la conoscenza del pattern usato dal sensore CCD.
Questo risolverebbe anche il problema della convesione, che di fatto rimarrebbe lossless (è un banale riordino dei dati).

Sei sicuro che JPEG 2000 usa le wavelet anche per la compressione lossless?
Al 100%. :) Ho sviluppato un'alpha di un decoder JPEG 2000 durante il mio stage / tesi di laurea all'STM, per cui conosco molto bene lo standard (anche se adesso molti particolari li ho dimenticati). :p
Sto pensando al fatto che usando una codifica a 8 bit per i coefficienti della DCT in JPEG si ottiene comunque un errore che nel caso peggiore può essere di +/- 4.
E' ciò che avviene anche con la trasformata wavelet reversibile 5/3 usata da JPEG 2000. :)
Infatti lo standard prevede l'aggiunta di alcuni "guard bit" rispetto ai bit riservati per ciascuna componente, e questo avviene anche per la trasformata irreversibile (lossy).
Salvare i coefficienti con precisione sufficiente ad evitare errori di approssimazione non conviene.
Non è detto, dipende sempre dal tipo di trasformazione che hanno subito i coeffienti: se è tale da mettere maggiormente in luce la ridondanza del segnale, si possono ottenere dei buoni risultati a livello di compressione. Infatti è proprio ciò che si verifica con la trasformata reversibile adottata per il JPEG 2000. :p

Questo non vuol dire che JPEG2000 offra i migliori fattori di compressione: JPEG-LS, ad esempio, è uno dei migliori (e forse migliore) compressori lossless esistenti per le immagini. Diciamo che JPEG 2000 offre una buona compressione.

E' stata scelta questo tipo di trasformata (anziché adottare, ad esempio, il più efficiente JPEG-LS) perché si integra perfettamente e "naturalmente" con lo standard JPEG 2000, e per offrire un formato unico e flessibile per qualunque esigenza (lossy e lossless, appunto).
Non è detto che il discorso valga in generale per le wavelet: la wavelet Haar (la più semplice) è perfettamente reversibile.
Anche quella di Daubechies, adottata dal JPEG 2000, lo è.

Comunque JPEG 2000 è uno standard aperto e in espansione: già il secondo draft / versione prevede altri tipi di trasformata wavelet (oltre anche altri tipi di quantizzazione del segnale molto più flessibili, e altro ancora).
Ci sono, però, due grossi handicap: richiede una notevole potenza di calcolo per l'elaborazione, e parecchio spazio di memoria.

D'altro canto l'unico formato che potrebbe essere usato sarebbe il raw, ma che di difetti ne ha uno gravissimo e cioè la sua futura ipotetica incompatibilità. Questo non è difetto da poco, cosa ci conservi? PNG non sarebbe alternativo ma complementare agli altri due, andrebbe a coprire quel segmento di richiesta di un formato affidabile (quanta qualità potrà mai perdere?) e duraturo, è open. Caratteristiche indispensabili per un segmento di fascia media che, secondo me, il jpg e raw non possono offrire. Non scontro dunque, ma cooperazione.
Non è questo il punto, IMHO: PNG e RAW "ereditano" i medesimi problemi, ossia quello dell'incompatibilità / non universalità.
Infatti il nocciolo della questione è quello di riuscire ad ottenere informazioni sul tipo di dati che ci ritroviamo in uscita dal CCD (cosa significano? Come li possiamo manipolare?), non sul formato da usare per memorizzarli.

Per questo motivo non posso che essere d'accordo col messaggio che joe4th ha scritto subito dopo al tuo... ;)

Vero, ma l'hanno aggiunto dopo, tant'e' che tutti i produttori di sw commerciale si ostinano a usare nei TIFF l'LZH piuttosto che il deflate... ;-)
LZW. ;)
Comunque è un problema loro: TIFF è un formato noto e ben documentato, per cui se la loro implementazione non è completa la "colpa" non è certo di TIFF.

E' un po' come se decidessi di implementare solamente alcune parti del JPEG 2000, perché le altre le ritengo superflue o troppo complicate da implementare... :p

Se ci spieghi anche cos'e' il Boyer pattern?
L'ha già mostrato superactual... :p
Sembra quasi come le stampanti EPSON in Esacromia...
E allora vuol dire che si prende l'RGB del PNG e si estende in un formato:

RGBX1X2X3...Xn

Dove Xi rappresenta una componente arbitraria definita tramite la sua lunghezza d'onda.
Adesso non ricordo di preciso com'è fatto il PNG (l'ho visto nascere su Amiga, ma è passato troppo tempo... :p), ma sicuramente JPEG 2000 in tal senso offre una flessibilità eccezionale, visto che permette di avere fino a 256 (16384 nel caso della compliance class più avanzata, la 2, che però non è quella raccomandata dallo standard per gli usi "comuni", ma per obiettivi molto più avanzati) componenti diverse, che possono avere caratteristiche anche completamente diverse rispetto alle altre (es: numero di bit, con o senza segno, fattore di sampling diverso in X e Y).
Purtroppo mi sembra che la battaglia sia piu' che altro per l'imposizione di un proprio formato...
E' probabile. Ciò non toglie che i miei dubbi su un formato universale rimangono comunque, a prescindere dal formato, a causa della diversità dei dati in uscita dai CCD...

Grazie per la risposta ;)
Infatti lo standard prevede l'aggiunta di alcuni "guard bit" rispetto ai bit riservati per ciascuna componente, e questo avviene anche per la trasformata irreversibile (lossy).
Questa non la sapevo...
Lo standard JPEG (se non ricordo male) non usa la DCT per la compressione lossless, ma una codifica di tipo DPCM. JPEG-LS è la prima volta che lo incontro (:p) e probabilmente funziona in modo simile a JPEG2000 (sul web ho visto qualcosa tipo "near-lossless compression").

Ciao,

Lo standard TIFF è diviso in baseline TIFF ed advanced TIFF:

Il baseline TIFF obbliga a supportare solo immagini RGB a 8 bit, monocromatiche e palettizzate fino a 8 bit e nessuna compressione. Il supporto ai 16 bit ed alle compressioni JPEG, LZW e CCIITT (per le monocromatiche) , ed alle altre estensioni, come la memorizzazione a "tiles", invece che a strisce, è opzionale.

Ciao.

Grazie per la risposta ;)
Di niente. E' sempre un piacere scambiare informazioni tecniche... :)
Questa non la sapevo...
Lo standard JPEG (se non ricordo male) non usa la DCT per la compressione lossless, ma una codifica di tipo DPCM.
Sì, ha un algoritmo completamente diverso e simile a PNG come approccio.
JPEG-LS è la prima volta che lo incontro (:p) e probabilmente funziona in modo simile a JPEG2000 (sul web ho visto qualcosa tipo "near-lossless compression").
Non ricordo i dettagli, ma dovrebbe essere basato sulla modellazione di contesti predittivi, a cui viene applicata poi una forma di codifica (generalmente aritmetica, ma non so cosa usi JPEG-LS).

Ciao,

Lo standard TIFF è diviso in baseline TIFF ed advanced TIFF:

Il baseline TIFF obbliga a supportare solo immagini RGB a 8 bit, monocromatiche e palettizzate fino a 8 bit e nessuna compressione. Il supporto ai 16 bit ed alle compressioni JPEG, LZW e CCIITT (per le monocromatiche) , ed alle altre estensioni, come la memorizzazione a "tiles", invece che a strisce, è opzionale.

Ciao.
Hai ragione. Comunque, anche se opzionali, si tratta di estensioni esistenti, documentate e facente parti dello standard (anche se avanzato) del TIFF: basterebbe utilizzarle.

Non ricordo i dettagli, ma dovrebbe essere basato sulla modellazione di contesti predittivi, a cui viene applicata poi una forma di codifica (generalmente aritmetica, ma non so cosa usi JPEG-LS).
Ho cercato un po' di informazioni e ho visto che JPEG-LS usa una tecnica ADPCM. Lo standard lossless JPEG invece usa una codifica DPCM a predittore fisso (se non ricordo male) e basato su un numero minore di pixel.

Per tornare IT, lo standard TIFF non è già abbastanza flessibile da permettere la definizione di uno standard RAW, dal momento che viene già usato a livello professionale per la gestione di immagini e di foto?

No, anche se supporta RGM, CMYK, CIELab ed altri spazi colore (anche se solo nell'advanced TIFF), non è possibile definire altri spazi colore come quello RGBM(agenta) di quel produttore menzionato prima.

Volevo dire RGB... il forum è chiuso e non posso editare... ;)

Ho cercato un po' di informazioni e ho visto che JPEG-LS usa una tecnica ADPCM. Lo standard lossless JPEG invece usa una codifica DPCM a predittore fisso (se non ricordo male) e basato su un numero minore di pixel.
Esattamente. Come il PNG, che ha diversi filtri a disposizione (infatti un compressore PNG generalmente applica ogni filtro disponibile alla riga corrente, e poi sceglie quello che presenta una "maggior comprimibilità").
Per tornare IT, lo standard TIFF non è già abbastanza flessibile da permettere la definizione di uno standard RAW, dal momento che viene già usato a livello professionale per la gestione di immagini e di foto?
T'ha già risposto bjt2. :)

Grazie per la risposta ;)

Questa non la sapevo...
Lo standard JPEG (se non ricordo male) non usa la DCT per la compressione lossless, ma una codifica di tipo DPCM. JPEG-LS è la prima volta che lo incontro (:p) e probabilmente funziona in modo simile a JPEG2000 (sul web ho visto qualcosa tipo "near-lossless compression").

usa anche la trasformata del coseno per la compressione lossless ( la perdita di informazioni in questa fase è irrilevante e se c'è, dipende dalla precisione negli arrotondamenti).
E' il passo precedente alla quantizzazione, che è invece la prima vera fase che porta ad una perdita di informazioni.

Un'ultima precisazione...dopo l'ordinamento a zig-zag il procedimento si biforca, perchè una codifica lossless è quella DPCM ma si applica ai soli coefficienti DC, mentre un'altra codifica lossless ( RLE) si occupa dei coefficienti AC, ovverosia tutti i coefficienti ( tranne il primo, con coordinate 0;0) di ciascuna matrice.

Se usa la DCT e c'è perdita di informazione, non si può parlare più di "lossless". :)

Qui http://www.hpl.hp.com/loco/HPL-98-193R1.pdf dicono questo:

"the two versions of the original lossless JPEG standard [20], i.e., the strongest one based on arithmetic coding, and the simplest one based on a fixed predictor followed by Huffman coding using “typical” tables [20]."

Quindi dovrebbe utilizzare il classico schema predittore -> codificatore entropico (Huffman o aritmetico).

Se usa la DCT e c'è perdita di informazione, non si può parlare più di "lossless". :)

Qui http://www.hpl.hp.com/loco/HPL-98-193R1.pdf dicono questo:

"the two versions of the original lossless JPEG standard [20], i.e., the strongest one based on arithmetic coding, and the simplest one based on a fixed predictor followed by Huffman coding using “typical” tables [20]."

Quindi dovrebbe utilizzare il classico schema predittore -> codificatore entropico (Huffman o aritmetico).

si parla di codifica lossless perchè la perdita di informazioni è irrilevante.
Questo significa che se si procede all'operazione inversa dal punto di vista dell'informazione ma soprattutto da punto di vista percettivo la differenza non si nota.

principio delle trasformazioni lossless è proprio la reversibilità delle stesse :)

Sulla DCT almeno io sapevo così, alcuni nemmeno accennano a questa perdita proprio perchè ritenuta insignificante ( d'altra parte è un'approssimazione di un errore...come avviene in qls tipo di misurazione: sufficientemente trascurabile).
se ripesco gli url li posto...alcune cose però le ho su come .ppt al max te le passo via ICQ, se ti interessa ovvio :D

Se c'è perdita di informazioni, allora non si può più parlare di lossless, come ho già detto. :)

Infatti formati come PNG, GIF, PSD, IFF, "RAW" si pongono come obiettivo proprio la perfetta conservazione dell'informazione trasportata.

Applicare la DCT, di cui non mi sembra esistere una trasformata reversibile (come invece accade con la DWT adottata da JPEG 2000), vuol dire necessariamente perdere qualcosa, per cui non è proponibile in questo caso.
Comunque non ho sottomano le specifiche del JPEG, ma la compressione lossless dovrebbe far uso soltanto di un predittore ai cui dati viene applicata una delle due codifiche (quella aritmetica non è comunque usata da nessuno a causa di brevetti di IBM, Matsushita, ecc. che comportano il pagamento di licenza); la DCT è esclusa proprio per quanto scritto prima... :p