Canon al lavoro sul formato RAW per i video

[Redazione di Hardware Upg]

Link alla notizia: http://www.fotografidigitali.it/news...deo_40528.html

Canon è al lavoro per lo sviluppo di un formato RAW per i video: da poco è stato pubblicato un brevetto depositato nel luglio 2010

Click sul link per visualizzare la notizia.

[calabar]

Però se scrivete "dipartita del presidente" sembra che sia schiattato, poverello!

In ogni caso un formato raw 4k mi sembra davvero difficilmente gestibile, per lo meno con le attuali tecnologie di storage.
Forse lo vedremo per riprese di pochi secondi?

[AleLinuxBSD]

Suppongo che risulterà essere una evoluzione spinta di raw compressi (con perdita di dati quindi di tipo loss) da usarsi specificamente per i flussi video.
Quindi, se la mia precedente ipotesi fosse valida, pur gestendo flussi video di dimensioni superiori all'attuale fullHD, se si volesse editare un singolo fotogramma (a quel punto di dimensioni sufficienti pure per realizzare stampe di un certo tipo - da vedere alla giusta distanza), la qualità risulterà inferiore (da capire di quanto) perché mancano delle informazioni.

[babytecnico]

Per questo ultimo motivo il lavoro dei tecnici è anche quello di alleggerire al massimo il flusso video: un flusso RAW 4096x2048 a 12 bit e 30 fps avrebbe infatti un bitrate pari a 2.8125 Gib/sec, troppo per le capacità di scrittura delle schede CF.

detto da pagano delle riprese, mi sembra follia pura.
qualcosa come 3000MB/s di video. (se ho fatto i calcoli giusti)

[gxxx]

Originariamente inviato da calabar

Però se scrivete "dipartita del presidente" sembra che sia schiattato, poverello!

In ogni caso un formato raw 4k mi sembra davvero difficilmente gestibile, per lo meno con le attuali tecnologie di storage.
Forse lo vedremo per riprese di pochi secondi?

infatti, immagino fare editing in un filmato da un'ora, a meno che non si dispone di una workstation...

[babytecnico]

Originariamente inviato da gxxx

infatti, immagino fare editing in un filmato da un'ora, a meno che non si dispone di una workstation...

[OT] Nvidia CUDA (o la controparte AMD) ed un bel 3-way multi-GPGPU [/OT]
beh, se ci riusciranno, buon per loro.. i professionisti ringrazieranno

[Opteranium]

Originariamente inviato da gxxx

infatti, immagino fare editing in un filmato da un'ora, a meno che non si dispone di una workstation...

una sola..? Direi quantomeno un server..

cmq penso che per sostenere un data-rate di quel genere, più che schede di memoria sia necessario un raid0 di SSD

[aqua84]

ma infatti è quasi esclusivamente rivolto ad un settore cinematografico, non di certo per farsi il filmino del compleanno e copiarlo agli amici.

[AleLinuxBSD]

Direi che non si dovrebbe sottovalutare la possibilità di estrarre solo singoli fotogrammi di un video.
Non saprei quanto l'operazione di riduzione possa ridurre la qualità potenziale ma, rispetto alle possibilità attuali, la situazione dovrebbe migliorare.
Pensate ad es. alle possibilità di estrarre foto quasi identiche a scatti singoli, da un video di backstage ...
Ecc.

[tmx]

@babytecnico:

no è sui 300MB, non 3000

[babytecnico]

Originariamente inviato da tmx

@babytecnico:

no è sui 300MB, non 3000

mi pareva...
per pigrizia ho usato un convertitore online.
troppo, comunque IMHO

[calabar]

Più che altro, il dato di partenza non è ben scritto.
2.8125 Gib/sec andrebbe scritto 2,8124 Gib/sec, altrimenti potrebbe sembrare un 28.125 Gib/sec scritto male (vabbè, un po' eccessivo comunque).

[yossarian]

Originariamente inviato da AleLinuxBSD

Suppongo che risulterà essere una evoluzione spinta di raw compressi (con perdita di dati quindi di tipo loss) da usarsi specificamente per i flussi video.
Quindi, se la mia precedente ipotesi fosse valida, pur gestendo flussi video di dimensioni superiori all'attuale fullHD, se si volesse editare un singolo fotogramma (a quel punto di dimensioni sufficienti pure per realizzare stampe di un certo tipo - da vedere alla giusta distanza), la qualità risulterà inferiore (da capire di quanto) perché mancano delle informazioni.

i RAW delle red sono di tipo 4:4:4 compresso (wavelet) con perdite, con rapporto di compressione variabile (3:1 per i 16 bit e 18:1 per i 12 bit) a bitrate costante. Eppure non mi risulta che la qualità sia inferiore al fullhd 8 bit 4:2:2 (tramite hdmi per 7d 1dMark IV, GH2 e futura nikon d4) o al 4:2:0 (compresso, però, anche quello), sempre 8 bit, delle cinereflex su CF o SD e delle videocamere.
Aggiungo solo: era ora. Se canon vuole allargare il core business ed entrare seriamente anche nel mondo del cinema con i suoi prodotti, deve, per forza di cose, fare questo salto. Altrimenti continuerà a puntare solo sulla maneggevolezza delle cinereflex rispetto alle cineprese vere e proprie, per riprese "scomode" ma sempre con i soliti limiti.

[gxxx]

Originariamente inviato da babytecnico

[OT] Nvidia CUDA (o la controparte AMD) ed un bel 3-way multi-GPGPU [/OT]
beh, se ci riusciranno, buon per loro.. i professionisti ringrazieranno

Originariamente inviato da Opteranium

una sola..? Direi quantomeno un server..

cmq penso che per sostenere un data-rate di quel genere, più che schede di memoria sia necessario un raid0 di SSD

beh, insomma tutta attrezzatura economica
comunque per il momento non è una tecnologia per noi "utenti normali", nè per produrre video nè tantomeno per vederli semplicemente in quanto non credo che qualcuno abbia un pannello con tale risoluzione (rarissimi casi a parte).

[ronthalas]

siamo a circa 377 MB/s (fissi)... ci vuole un SSD di quelli molto veloci!!!
1,296 TB per un ora di registrazione... in arrivo il nuovo formato RAW4k-Ray per supporti ottici e Flash?

[benis67]

Facendo bene i conti: 4096*2048*30*12=3019898880 bit al secondo.
Dividendo per 8, poi per 1024 e ancora per 1024 si hanno 360 MByte/s.
Iniziamo a parlare di compressione LOSELESS, ovvero compressione matematica senza perdita di qualità; senza scomodare le ridondanze temporali (ovvero la possibilità di sfruttare la similitudine spaziale e temporale di immagini successive) si ottiene un risparmio netto del 35-40%. In tal caso si arriva senza grosse elaborazioni (bastano i DSP che le telecamerine di oggi comprimono in fullHD, si arriva a circa 230-240 MByte/s che è il bitrate di un normale HD SSD.
La matematica grazie al cielo aiuta e fermo restante l'utilizzo di compressione senza perdita di qualità, fondamentale per avere delle reali successioni di immagini RAW, si possono usare tecniche di compressione che utilizzano le ridondante temporali. Le tecniche sono le ultranote tecniche compensazione dei movimenti che consistono, in breve, nella ricerca tra fotogrammi successivi, di blocchi di pixel tra di loro simili. Con tali tecniche si ottengono a secondo del tipo di movimenti risparmi di un fattore variabile da 4 a qualcosa più di 10; molto dipende dall'algoritmo e dal tipo di video. si arriva così a valori di 20-90 MByte/s.
In realtà esistono già algoritmi che fanno ciò, vedi l'ultranoto h264 che esiste anche in versione loseless: probabilmente Canon vuole svincolarsi da royality dovute all'utilizzo di codec già "patentati". Approfondimenti sulle tecniche di compressione le trovate nella parte "vecchia" mio benis.it :-)

[maxthewildcat]

"....si possono usare tecniche di compressione che utilizzano le ridondante temporali. Le tecniche sono le ultranote tecniche compensazione dei movimenti che consistono, in breve, nella ricerca tra fotogrammi successivi, di blocchi di pixel tra di loro simili....."

si ma non è un tipo di operazione che si può fare sui formati video raw, i quali, per definizione stessa di raw, devono conservare all'interno di ogni singolo fotogramma tutte le informazioni relative a esposizione, bilanciamento del bianco, guadagno / ISO, etc etc;

infatti, a titolo di paragone, la compressione della REDONE è di tipo INTRAFRAME, e non potrebbe essere altrimenti....

[AleLinuxBSD]

Originariamente inviato da yossarian

... Eppure non mi risulta che la qualità sia inferiore ...

Avevo trovato questo articolo:
A proposito del NEF compresso...
si discute del raw nikon ma tanto penso che il principio di funzionamento sia lo stesso quanto parliamo di compressione del raw.
Verso il fondo viene indicato un modo per evidenziare le differenze tra un raw normale ed uno compresso.
Se il metodo proposto risultasse effettivamente valido, sarebbe piuttosto semplice evidenziare le differenze.
Che poi queste possano essere più o meno trascurabili è un'altro discorso.

In ogni modo penso che quanto indicato da benis sia fattibile (a parte il discorso loseless di cui continuo a non essere convinto) riguardo all'usare differenze di fotogrammi, riuscendo lo stesso ad ottenere il raw del singolo fotogramma.
In fondo si tratterebbe di lavorare su un blocco di fotogrammi, dove la parte video, che è la più onerosa in termini di spazio, può essere compressa lavorando sulle differenze, mentre la parte degli exif dei singoli fotogrammi può essere ripetuta.
Da questo super blocco raw si potrebbe generare "al volo" il raw specifico.

Esempio supponiamo che un raw abbia il seguente peso:
99 % parte video 1 % exif (in realtà per gli exif è necessario molto meno)

Ipotizziamo un blocco raw video di 1 minuto, se si riuscisse a comprire anche del 30 %, sarebbe un bel vantaggio, poi quando l'utente chiede un raw il software basandosi sui dati exif conosce esattamente quale fotogramma va ricostruito.

[benis67]

maxthewildcat, il bello dei formati proprietari è che puoi scrivere il codec come preferisci; a quel punto inserire per ogni fotogramma dei dati exif è banale; se non ricordo male anche l'h264 prevede la possibilità di aggiungere liberamente dei byte di "note" per ogni frame.
Benny

[yossarian]

Originariamente inviato da AleLinuxBSD

Avevo trovato questo articolo:
A proposito del NEF compresso...
si discute del raw nikon ma tanto penso che il principio di funzionamento sia lo stesso quanto parliamo di compressione del raw.
Verso il fondo viene indicato un modo per evidenziare le differenze tra un raw normale ed uno compresso.
Se il metodo proposto risultasse effettivamente valido, sarebbe piuttosto semplice evidenziare le differenze.
Che poi queste possano essere più o meno trascurabili è un'altro discorso.

In ogni modo penso che quanto indicato da benis sia fattibile (a parte il discorso loseless di cui continuo a non essere convinto) riguardo all'usare differenze di fotogrammi, riuscendo lo stesso ad ottenere il raw del singolo fotogramma.
In fondo si tratterebbe di lavorare su un blocco di fotogrammi, dove la parte video, che è la più onerosa in termini di spazio, può essere compressa lavorando sulle differenze, mentre la parte degli exif dei singoli fotogrammi può essere ripetuta.
Da questo super blocco raw si potrebbe generare "al volo" il raw specifico.

Esempio supponiamo che un raw abbia il seguente peso:
99 % parte video 1 % exif (in realtà per gli exif è necessario molto meno)

Ipotizziamo un blocco raw video di 1 minuto, se si riuscisse a comprire anche del 30 %, sarebbe un bel vantaggio, poi quando l'utente chiede un raw il software basandosi sui dati exif conosce esattamente quale fotogramma va ricostruito.

l'articolo parla di un metodo che fa uso di tecniche di reverse engineering. Non può essere applicato a qualsiasi formato RAW con compressione differente da quelli (il NEF in particolare) analizzati nell'articolo. Tra l'altro, un conto è trattare immagini statiche, un altro trattare immagini dinamiche. Per queste ultime si possono usare anche algoritmi di compressione che lavorano sulle similitudini spaziali, come dice benis67 ma presentano altre problematiche di cui parlerò dopo.
Al momento, noi abbiamo a che fare, a livello consumer e prosumer (e, se vogliamo, anche a livello pro) con molti tipi di algoritmi di compressione di tipo lossy (ad iniziare proprio dall'AVCHD). Anche macchine di un certo livello, come RED, panasonic varicam, ossia macchine per uso professionale, fanno uso di RAW con compressione di tipo lossy, anche se di alta qualità e, a dir loro, "visivamente" di tipo lossless. Questo per permettere l'acquisizione su supporti differenti da box esterni, dotati di ingressi dedicati da collegare alla cinepresa. Il vantaggio di usare una cinereflex o una red one, rispetto, ad esempio, ad una alexa o ad una sony f35 o f65, è nella portabilità e nei minori ingombri. Per mantenere questo vantaggio, si deve trovare il modo di registrare su CF o qualcosa di analogo.
Tornando al paragone tra immagini statiche e dinamiche, le differenze di trattamento non riguardano, eventualmente, solo il tipo di compressione ma anche il tipo di acquisizione. L'acquisizione delle immagini in movimento presenta, soprattutto con sensori a matrice bayer, più problemi e maggior rischio di artefatti anche a causa del minor tempo che la cpu può dedicare al processo di ricostruzione dell'immagine. Per questo motivo si fa uso di sensori con molti più Mpixel di quelli necessari, in modo che le informazioni sui 3 canali RGB risultino ridondanti. Ad esempio, la canon c300 che ha un'uscita di tipo fullHD, acquisisce ed elabora le immagini, internamente, a 4K. La nuova F65 di sony, con uscita 4K, acquisisce le immagini utilizzando un sensore da 20 Mpixel.
Ovviamente, stiamo parlando di macchine che esulano dalle possibilità e anche dalle necessità dei comuni mortali che hanno l'esigenza di fare il filmino delle vacanze (ma per quello è troppo anche una cinereflex) . Però, capisci bene che non si tratta di elaborare un flusso di dati pari a quello in output, ma un flusso molto maggiore lungo tutta la pipeline, fino all'uscita dove, lo stesso, viene ridimensionato. Questo per poter elaborare le immagini con una qualità più elevata.
Da qui, la necessità di lavorare con file compresi se si vuole poter utilizzare un supporto del tipo memory card. Per fare qualche esempio, i RAW non compressi di arriflex, panavision o dalsa presentano bitrate superiori ai 3 Gbit/sec (addirittura sopra i 5 per l'arriraw).
SEcondo me, canon ha già fatto un importante passo avanti con la codifica intraframe introdotta con la 1dx, che non ha precedenti nel mondo delle video reflex e la pone, a livello qualitativo, decisamente al di sopra della concorrenza. Se decide di adottare un formato RAW, seppure compresso, magari a livello di quello a 12 bit della red one, non potrei non dirmi soddisfatto.