Blacker than Black, come verificarlo correttamente?

[Luciano Merighi]

Di fatti, ho seguito tutta la tua guida passo passo: x le regolazioni dei black/while levels ho fatto esattamente come indicavi tu e ottenendo quel risultato, ma alla fine la visione di un film era peggiore che facendo le tarature col DVD di AVMagazine. Non mi chiedere come mai.

mi sa che ti tocca invitarmi a cena, perchè a questo punto sono curioso...

 

[Vittorinox]

no problem.

Solo che devi venire fino a TO.

Quando vuoi venire fammi sapere che mi organizzo.

 

[ciuchino]

Strumenti troppi flessibili si vede che incasinano.

Far diventare nero l'ultimo rettangolo della scala dei neri di AF , quello con sopra i pallini bianchi nel DVE oppure un rettangolo con scritto 16 ... probabilmente e' diverso.
Se c'era scritto zero allora si che diventava bello nero dopo taratura

 

[Vittorinox]

Ho fatto un'altra verifica che non avevo fatto......

Sull'altro PC, ove c'è il piccolo samsung 17" WIDE (quello profilato che passava il test BTB), ho rifatto la taratura perchè non ero certo di aver lasciato tutto invariato.

Da subito passa lil test BRB: sicuramente questo è merito del profilo colore fatto col sensore della Colorvision.

Proseguo con le regolazioni, lasciando a defalt sul monitor e agendo sui controlli del pannello Nvidia: debbo portare a 98% la luminosità e a 105% il contrasto.
Praticamente era quasi a posto.


A questo punto ho rimesso su il film che uso sempre x questi test: Matrix.

Ricco di neri anche se non ha una qualità eccelsa, con parecchio rumore di fondo e artefatti che si notano.

Qui mi pare che si veda bene, anche se non ho installato il Purevidia, ma il vecchio NVDVD....

 

[ciuchino]

Scusami ma forse la mia domanda di prima era poco chiara.

Se io inserisco un disco di test in una certa catena e non faccio niente e' impossibile che poi un film si veda diversamente.
Avrai regolato i parametri , diciamo quelli fondamentali Luminosita' Contrasto Gamma Saturazione ottimizzandoli con quel disco.
Quindi interessante capire le differenze di settaggio che hai ottenuto utilizzando un disco di test oppure un altro ... stessa catena.

 

[Girmi]

alt! le versioni precedenti alla 1.07 avevano un errore di fondo...

Questo è il punto.
Da quanto ho rilevato io è il contrario.

La cosa sarebbe facilmente dimostrabile se tu riuscissi a modificare la schermata "Grey test" sostituendo la rampa 0-100%, ora limitata a 21 step, mettendo tutte le 220 sfumature che compongono la gamma 16-235 e le 254 (1-254) usate nella codifica MPEG2.

Basterebbe poi "contare" gli steps presenti nelle rampe dopo la compressione (cosa che io ho fatto con le mie schermate) per capire come viene trattata l'immagine dall'encoder.

Ciao.



p.s.: ti ho rimandato la mail pari pari.

 

[Girmi]

Di fatti, ho seguito tutta la tua guida passo passo:

Prova a rifare gli interventi, sia sull'Amstrad che sul PC, usando IL DVD di Luciano nel modo che ho indicato più indietro.
Poi sistema i due display senza più toccare i settaggi sulle sorgenti.

Ciao.

 

[Luciano Merighi]

Questo è il punto.
Da quanto ho rilevato io è il contrario.

La cosa sarebbe facilmente dimostrabile se tu riuscissi a modificare la schermata "Grey test" sostituendo la rampa 0-100%, ora limitata a 21 step, mettendo tutte le 220 sfumature che compongono la gamma 16-235 e le 254 (1-254) usate nella codifica MPEG2.

mi sembra che si giri un po' attorno...

la schermata che dici esiste già. E' la "grey ramp".
Nell'immagine tiff originale, la colonna a sinistra è a 16, quella di destra è a 235 e in mezzo alle due, vi sono 256 colonne larghe due pixel ciascuna, con triadi RGB, ovviamente uguali fra loro, da 0 a 255.
L'immagine tiff così costruita, è stata data in pasto all'encoder CCE impostato per avere gli algoritmi per il calcolo del valore di Y nel file mpeg prodotto, collocati nel range 0-255 e non 16-235. Da queste formule, Y risulta uguale ai valori RGB originali, cioè un r,g,b di 45 darà un y di 45 e così via.
I risultati sono calcolabili con il foglio gamma.xls che ho allegato qualche pagina dietro.

Il problema sta nel fatto che i software usati per estrarre i frames dall'mpeg, considerano solitamente solo il range 16-235, per poi espanderlo nel range PC (e mac!) di 0-255, perdendo le informazioni 0-15 e 236-255. Danno per scontato che non vi sia nulla da considerare al di fuori di quel range. Ciò è vero nell'uso comune ma non con pattern di test volutamente fatti per andare oltre. Il frame estratto della rampa citata che mi hai inviato, era proprio così: erano state espanse su 0-255 le informazioni 16-235 con perdita dei livelli 0-15 e 236-255, appiattiti rispettivamente a 0 e 255. Questo porta ad interpretazioni errate. Prova ad estrarre il famoso frame THX, vedrai che ti mancherà qualcosa dell'immagine originale.
La stessa rampa, nelle versioni vecchie del dvd, subiva in encoding la compressione e l'offset dei livelli originali, che tra l'altro, producevano un andamento molto più irregolare della sfumatura che doveva distribuire 229 livelli digitali in 256 colonne.

Poi, si dica quel che si vuole, per far scendere il segnale analogico sotto il livello di 0,321V che, ripeto, in tutti i dvd che ho esaminato corrisponde alle zone veramente nere e guarda caso nelle specifiche bt-601, al digital 16, devo usare delle sequenze di test opportunamente codificate (merighi ma anche THX). Le stesse sequenze nelle vecchie versioni del test si fermano a 0,321V e non vanno mai al di sotto.

 

[MauMau]

premetto che nella mia catena video (HDMI normal, YCbCr 4:2:2) ho la perfetta corrispondenza fra la taratura Merighi, AF digitale e THX.

... Come ho già scritto, la schermata BTB è poco più che un "nice to know", non va usato per regolare la luminosità.

Luciano, non vedo il motivo.
Secondo me la luminosità del display/vpr va calibrata proprio con il black-16, che deve equivalere al nero in termini di luminosità su schermo.
Si regola in modo che i livelli 0-15 "affoghino" nel nero, e rimangano distinguibili i livelli dal 17 in su.

Vanno usati set contrast, blacks e whites che riportano i valori assoluti digitali della sola componente Y, scritti nel flusso mpeg.

daccordo. Qui entra in campo la qualità della catena video, la sua capacità di visualizzare a schermo piccole differenze di luminosità.
E' possibile che non tutti riescano a "tirar fuori" dal proprio impianto tutti gli step digitali, e allora si dovrà cercare un compromesso.

Il 16 del mio dvd è lo stesso 16 dei comuni DVD, livello deputato a produrre il nero .

Per come lo vedo a casa mia, non posso che confermare.

 

[Vittorinox]

premetto che nella mia catena video (HDMI normal, YCbCr 4:2:2) ho la perfetta corrispondenza fra la taratura Merighi, AF digitale e THX.

Uhmm.....

In tutti i casi, dato che sull'altro PC "sembra" ok (ma debbo fare delle vero prove comparative con un po' di calma), vedrò di rifare le calibrazioni DVD-Merighi sul Myrica sia con l' HTPC e sia con l'Amstrad.

 

[Girmi]

Il problema sta nel fatto che i software usati per estrarre i frames dall'mpeg,…

Come ti ho detto in pvt, il sistema che uso io analizza direttamente il flusso digitale MPEG, non fa alcuna estrazione di frame ma la sola conversione da YCbCr a YUV.

L'oscilloscopio che usi tu invece è soggetto ai convertitori D/A, e relativi controlli, posti sulle uscite analogiche della sorgente e ne misura l'ampiezza del segnale in uscita, non quelle che succede a monte.

Se vari i controlli di luminosità e/o contrasto della tua sorgente e ne analizzi l'uscita con l'oscilloscopio, avrai un risultato per forza di cose diverso dall'analisi del flusso digitale originale.

Questo ad esempio, è lo spezzone di filmato, che tu hai già visto, posto alla fine delle schermate del THX Optimizer versione PAL (1-254 RGB). Cliccare l'icona per vedere il filmato.



Anche se ne analizzassi i frames estratti non cambierebbe nulla (almeno su Mac). Infatti…

Il frame estratto della rampa citata che mi hai inviato, era proprio così: erano state espanse su 0-255 le informazioni 16-235 con perdita dei livelli 0-15 e 236-255, appiattiti rispettivamente a 0 e 255.

Per chiarezza di chi legge, il frame di cui si parla è quello qui sotto e che riporta l'analisi della luminanza, Y, dello spezzone della rampa.



Se il tuo ragionamento fosse corretto e se le campiture ai lati della rampa fossero veramente a 16 e 235 RGB, la rampa dovrebbe essere "stirata", come dici sopra, dai valori 16-235 a 1-254 (lo 0 ed il 255 non vengono considerati nella codifica MPEG2).
La perdita dei livelli 1-15 e 236-254 avrebbe come conseguenza la riduzione delle sfumature da 254 a 220, cioè le sole comprese fra 16 e 235.

Ma se vado a fare la conta delle sfumature presenti nella rampa, in questo caso in un frame estratto come TIFF, le cose stanno molto diversamente.



Infatti le sfumature presenti sono ben 253 (abbuoniamone una per le imprecisioni dell'encoder).

Dato che si potrebbe pensare che alcune di queste sfumature possano essere generate dalla sovrapposizione di gamma differenti nei diversi canali (in pratica se alcuni pixel non avessere le combinazioni RGB con valori pari: 20:20:20, 156:156:156; ecc…, il totale delle sfumature aumenterebbe), si possono analizzare le singole sfumature con un qualsiasi color picker, cosa che ho fatto, o meglio ancora evitare qualunque dubbio contando le sfumature anche nei singoli canali.



Il risultato è sempre di 253 sfumature per ogni canale.


Come lo spieghi, dato che dovrebbero essere 220 o meno?


A mio avviso, la confusione generata in questo thread, alla quale ho dato il mio contributo, è nata dalla presunzione di una relazione diretta fra IRE, valori di luminanza e valori RGB.
Non è così.

Se è vero che l'optimum sarebbe avere una sorgente capace di leggere il valori Y 0-100%, farli uscire rispettivamente a 0 e 100 IRE e che il display ne facesse una conversione a 0-255 RGB, è anche vero che nulla vieta che un valore Y 25-78% esca a 14 -110 IRE e che il display lo converta da 0 a 211 RGB o altro.

Sono valori e scale completamente diverse fra loro.

Infatti nel nostro caso abbiamo un segnale RGB 0-255 encodato in YCbCr (Y non ha limiti di sfumature) con Y forzato su valori da -5% a 109%.
Assumendo questi estremi come corrispondenti ad una scala 0-100 IRE è ovvio che le letture in analogico, del tuo osciloscopio, diano valori di ampiezza compleamente diversi.
Io credo che equiparando gli estremi ai corrispondenti valori in IRE, -5 +109, i conti dovrebbero tornare (i valori IRE sono 140 gestibili in vario modo).
La stessa cosa accade con una connessisone analogica o digitale YCbCr variando i valori di luminosità e contrasto.
Utilizzando invece un convertitore A/D, per il passaggio ad RGB, vengono letti solo i valori compresi fra 0 e 100% Y e questi sono quelli riportati dal mio vidoescopio.

Ad ogni modo, tutto questo ha ben poco a che vedere con il problema del BtB, almeno nell'eccezzione comune che si dà a questo termine, cioè l'impossibilità per una sorgente video di uscire con valori inferiori al 16 RGB, quindi dopo tutte le conversioni A/D del caso.
Questo riguarda solo le uscite digitali, HDMI o DVI, in RGB.

Per quanto ne so, questo è un problema limitato a pochissimi lettori.
Anzi, io so per certo solo dei Samsung HD945 e HD950.

Per verificarlo, o simularlo, su altri lettori ho già postato un mio sistema qui.


Ciao.

 

[Girmi]

I test col pendolo o con le sbarre biache/gialle, mi paiono strani.

Scusa Vittorinox,
qui ragioniamo già a fatica sul BtB.
Non sarebbe più opportuno parlare di pendoli nel thread sul Merighi DVD Test?

Ciao.

 

[Vittorinox]

Non sarebbe più opportuno parlare di pendoli nel thread sul Merighi DVD Test?

si. Hai ragione, scusa.

 

[Luciano Merighi]

Come ti ho detto in pvt, il sistema che uso io analizza direttamente il flusso digitale MPEG, non fa alcuna estrazione di frame ma la sola conversione da YCbCr a YUV.

ti ricordo che YUV a 8bit prevede il range 0-255, YCbCr no.

L'oscilloscopio che usi tu invece è soggetto ai convertitori D/A, e relativi controlli, posti sulle uscite analogiche della sorgente e ne misura l'ampiezza del segnale in uscita, non quelle che succede a monte.

se mantengo la stessa regolazione posso confrontare l'output di due sequenze. Se una mi scende sotto gli 0,321V e l'altra no, posso comunque trarre delle considerazioni sui livelli digitali che contengono.

Se vari i controlli di luminosità e/o contrasto della tua sorgente e ne analizzi l'uscita con l'oscilloscopio, avrai un risultato per forza di cose diverso dall'analisi del flusso digitale originale.

vedi sopra, non cambio le regolazioni confrontando sequenze diverse

Questo ad esempio, è lo spezzone di filmato, che tu hai già visto, posto alla fine delle schermate del THX Optimizer versione PAL (1-254 RGB). Cliccare l'icona per vedere il filmato.

è qui che sbagli, lo spezzone lo vedi nel range 1-254 solo dopo la conversione YUV che attua il tuo software, ovveroi dopo l'espansione del contenuto originale 16-235 YCbCr in YUV 0-255

Per chiarezza di chi legge, il frame di cui si parla è quello qui sotto e che riporta l'analisi della luminanza, Y, dello spezzone della rampa.

L'immagine della rampa che posti non appare uguale a quella sul DVD, mancano gli "scalini" fra i lati sx dx del frame e l'inizio e la fine della rampa. Controlla nel thread, qualche pagina indietro...
Guardando la rampa nella finestra YUV, il videoscopio clippa, tralasciando i livelli fuori range, livelli che invece vedo benissimo sia sul televisore che sul proiettore (scalibrandolo...) e che quindi ci sono! Non è che il tasto source abbia qualche influenza? La curva YUV che dice anche che è stata applicata una correzione di gamma visto l'andamento esponenziale. Dovrebbe essere una retta, come ad esempio ho con l'oscilloscopio quando non correggo il gamma del lettore.

Se il tuo ragionamento fosse corretto e se le campiture ai lati della rampa fossero veramente a 16 e 235 RGB, la rampa dovrebbe essere "stirata", come dici sopra, dai valori 16-235 a 1-254 (lo 0 ed il 255 non vengono considerati nella codifica MPEG2).
La perdita dei livelli 1-15 e 236-254 avrebbe come conseguenza la riduzione delle sfumature da 254 a 220, cioè le sole comprese fra 16 e 235.

Ma se vado a fare la conta delle sfumature presenti nella rampa, in questo caso in un frame estratto come TIFF, le cose stanno molto diversamente.



Infatti le sfumature presenti sono ben 253 (abbuoniamone una per le imprecisioni dell'encoder).


Il risultato è sempre di 253 sfumature per ogni canale.


Come lo spieghi, dato che dovrebbero essere 220 o meno?

La compressione-estrazione e relativi errori di quantizzazione e arrotondamenti, aumentano il numero di pixel diversi facendo raggiungere il numero di 253. E' vero lo 0 e il 255 sono valori non permessi in mpg ma legali in YCbCr.
Un'altra cosa, non è che c'è stata anche una riscalatura di mezzo, prima del conteggio pixel? Le immagini devono essere 720x576 e invece nel link che metti c'è 1024x576. L'algoritmo di riscalatura ci mette evidentemente del suo...
Le formula per RGB (0-255) dai valori YCbCr (16-235) sono ad esempio questa:
R=1,164(Y-16)+1,596(Cr-128)
G=1,164(Y-16)-0,813(Cr-128)-0.391(Cb-128)
B=1,164(Y-16)+2.018(Cb-128)

A mio avviso, la confusione generata in questo thread, alla quale ho dato il mio contributo, è nata dalla presunzione di una relazione diretta fra IRE, valori di luminanza e valori RGB.
Non è così.

Infatti, gli IRE sono una rappresentazione di comodo, in 100 parti dell'intervallo di tensione del segnale analogico di 0,7V che va dalla tensione nominale equivalente al livello di blanking (0,321V) a quella che deve produrre il bianco (1,020V). In ambito PAL e NTSC Japan, il blanking e il nero hanno la stessa tensione, quindi è possibile dire che in una sorgente calibrata, vi è corrispondenza fra la percentuale dell'intensità del segnale e il valore in IRE. Gli Yankees invece, ponendo il nero a 7,5IRE, non possono vantare questa corrispondenza. E' poi la ragione per la quale non si è più parlato in percentuale di intensità ma sono stati escogitati gli IRE...

gli yankees, ponendo il nero a 7,5IRE, hanno di fatto il range 0-100% del segnale utile distribuito su 92,5IRE ma questi sono affari loro...

Se è vero che l'optimum sarebbe avere una sorgente capace di leggere il valori Y 0-100%, farli uscire rispettivamente a 0 e 100 IRE e che il display ne facesse una conversione a 0-255 RGB, è anche vero che nulla vieta che un valore Y 25-78% esca a 14 -110 IRE e che il display lo converta da 0 a 211 RGB o altro.

Sono valori e scale completamente diverse fra loro.

ma un sistema calibrato deve far coincidere i valori in funzione delle grandezze che rappresentano anche se espressi in modi diversi.
Un Y al 78% che producesse l'equivalente di 110IRE in output, sarebbe poco bello da vedere... Una delle prove che molte riviste fanno, è proprio la verifica delle tensioni in uscita in relazione al valore di Y, che se ad esempio 235, cioè il 100% del valore nominale deve fornire 1,020 per essere a posto. Sarà poi cura del display gestire come si deve questo segnale

Infatti nel nostro caso abbiamo un segnale RGB 0-255 encodato in YCbCr (Y non ha limiti di sfumature) con Y forzato su valori da -5% a 109%.
Assumendo questi estremi come corrispondenti ad una scala 0-100 IRE è ovvio che le letture in analogico, del tuo osciloscopio, diano valori di ampiezza compleamente diversi.

Y di YCbCr purtroppo ha solo 220 step nominali, quelli fino a 255 sono per valori oltre i 100IRE, che nel video possono sempre capitare, ad esempio un lampo...
Nessuno assume il range 5-109% corrispondente alla scala 0-100IRE, altrimenti si avrebbe un sistema non calibrato. Si deve invece cercare di ottenere la corrispondenza 0%-0IRE e 100%-100IRE. Sull'analogico potrò verificare con sicurezza questa corrispondenza perchè i 100IRE devono essere a 1,020V, altrimenti non sarebbero 100IRE e a loro volta dovranno essere prodotti dalle zone a livello 100% che a loro volta dovranno essere prodotte dal livello 235... chiaro no?

Ad ogni modo, tutto questo ha ben poco a che vedere con il problema del BtB, almeno nell'eccezzione comune che si dà a questo termine, cioè l'impossibilità per una sorgente video di uscire con valori inferiori al 16 RGB, quindi dopo tutte le conversioni A/D del caso.
Questo riguarda solo le uscite digitali, HDMI o DVI, in RGB.

Per quanto ne so, questo è un problema limitato a pochissimi lettori.
Anzi, io so per certo solo dei Samsung HD945 e HD950.

Per verificarlo, o simularlo, su altri lettori ho già postato un mio sistema qui.


Ciao.

vero e comunque non è un gran danno se il BTB non passa...
Anche i players LG mi risultano "tagliatori di supernero.
Il vero problema con le connessioni digitali, è fare in modo che tutti i passaggi siano eseguiti con le giuste impostazioni, per non subire inopportune espansioni/tagli/offset dei valori utili del segnale, mangiandosi zone scure o chiare che invece dovrebbero esserci.
Esempio: imposto YCbCr (16-235) sulla sorgente e sul display via HDMI. Regolo per vedere correttamente il livello 16 come nero, fin qui tutto bene. Per qualche motivo cambio impostazione sulla sorgente e metto rgb estesa (0-255) senza cambiare regolazioni sul display.
Il display, continuando a considerare i valori 16-235, potrebbe tralasciare tutto quello al di fuori del range e perdere informazioni che in realtà erano in origine sopra al livello del nero e sotto al bianco, causando black crush e white clipping.


Dopo questa fatica vado a letto...

 

[Luciano Merighi]

premetto che nella mia catena video (HDMI normal, YCbCr 4:2:2) ho la perfetta corrispondenza fra la taratura Merighi, AF digitale e THX.

meno male...

Luciano, non vedo il motivo.
Secondo me la luminosità del display/vpr va calibrata proprio con il black-16, che deve equivalere al nero in termini di luminosità su schermo.
Si regola in modo che i livelli 0-15 "affoghino" nel nero, e rimangano distinguibili i livelli dal 17 in su.
.

il fatto è che nella schermata BTB il livello dello sfondo e dell'ombra sono 13 e 4, livelli che non sono significativi per regolare la luminosità ma sono stati scelti perchè "ragionevolmente" sotto al 16 da non dare adito a dubbi sul fatto che passino o meno.

 

[Luciano Merighi]

Se il tuo ragionamento fosse corretto e se le campiture ai lati della rampa fossero veramente a 16 e 235 RGB, la rampa dovrebbe essere "stirata", come dici sopra, dai valori 16-235 a 1-254 (lo 0 ed il 255 non vengono considerati nella codifica MPEG2).
La perdita dei livelli 1-15 e 236-254 avrebbe come conseguenza la riduzione delle sfumature da 254 a 220, cioè le sole comprese fra 16 e 235.

Ma se vado a fare la conta delle sfumature presenti nella rampa, in questo caso in un frame estratto come TIFF, le cose stanno molto diversamente.



Infatti le sfumature presenti sono ben 253 (abbuoniamone una per le imprecisioni dell'encoder).

.......


Il risultato è sempre di 253 sfumature per ogni canale.


Come lo spieghi, dato che dovrebbero essere 220 o meno?

torno brevemente su questa domanda e riporto i risultati di alcune prove che sono finalmente riuscito a fare...

Premessa: le immagini riportate qui di seguito, sono la conversione jpg di originali tiff. I numeri di colori riportati, si riferiscono agli originali tiff, anche se la conversione jpg non ha mutato questi valori.

Questa è l'immagine originale che ho dato in pasto all'encoder mpeg settato espressamente per produrre un range in out 0-255:

essa comprende i livelli da 0 a 255, la colonna a sinistra è 16 poi comincia una rampa regolare a step larghi 2 pixel che va da 0 a 255, la colonna a destra è a 235.
Quando la osservo con il televisore, leggendola dal testDVD Merighi con il player domestico, l'immagine mi appare esattamente così come sopra, ogni zona è distinguibile, quindi l'informazione è presente sul DVD! (CRT non mente!)


Se estraggo un frame dallo stesso file mpeg del DVD, mantenendo la risoluzione originale, usando il PC e premiere 6.5, ho invece questa:

si nota che le sfumature estratte sono solo quelle del range video, quelle 16-235 espanse però nel range PC 0-255. Addio agli scalini all'inizio e alla fine della rampa. La colpa è del renderer mpeg2 che ha ignorato i range extra video.
Ai fini "visione film" non importa, perchè il segnale utile è confinato in quel range. Ha importanza invece se vogliamo fare analisi qualitative/quantitative del frame. L'espansione dei livelli taglia zone significative e porta anche una distribuzione più irregolare delle sfumature, visto che ora nello stesso numero di pixel, 512, cioè la larghezza della rampa, sono distribuite 220 sfumature diverse e non tutte le 256 originali.

Se poi riscalo l'immagine a 1024x576 come gli esempi che avevi postato...
http://digilander.libero.it/merifon/btb/extractCCE_ramp256_rescaled.jpg
ecco che le sfumature aumentano. E' a causa dell'algoritmo di riscalatura che riempie i pixel mancanti con altri di sfumature intermedie fra due originariamente contigui. Usando diversi algoritmi, il numero finale cambia

 

[MauMau]

interessantissima analisi ...

Se estraggo un frame dallo stesso file mpeg del DVD, mantenendo la risoluzione originale, usando il PC e premiere 6.5, ho invece questa:

hai per caso visto se il test del BTB di THXoptimizer e il tuo vengono superati ?

... e porta anche una distribuzione più irregolare delle sfumature, visto che ora nello stesso numero di pixel, 512, cioè la larghezza della rampa, sono distribuite 220 sfumature diverse e non tutte le 256 originali.

verissimo.
Secondo me questa perdita di sfumature è il "difetto" maggiore dello standard dvd-video 16-235.
Però non ho idea quale sia l'impatto reale ai fini della visione.

 

[Luciano Merighi]

interessantissima analisi ...

hai per caso visto se il test del BTB di THXoptimizer e il tuo vengono superati ?

ho fatto queste prove tempo fa e cito a memoria: estraendo con premiere, dal file vob rinominato mpeg, i due famosi frame, il merighi ha sfondo uniforme e quindi non passa, mentre il THX riporta una flebile traccia della differenza fra sfondo e ombra. Infatti quest'ultimo non ha un 16 uniforme ma un dither di valori 16, 17, 18 e forse quache rado 19. Ribadisco che il THX non è stato fatto per verificare il btb ma per calibrare il nero.

verissimo.
Secondo me questa perdita di sfumature è il "difetto" maggiore dello standard dvd-video 16-235.
Però non ho idea quale sia l'impatto reale ai fini della visione.

in assoluto non drammatico ma in una catena che introduca elaborazioni a 8bit successive, l'aumentare dell'errore da quantizzazione può diventare evidente, ad esempio sui famosi incarnati. Non perchè il color carne sia più difficile ma perchè il cervello è abituato da milioni di anni ad elaborare le facce, che sono la parte del corpo analizzata più a fondo... dopo i fondoschiena

 

[Girmi]

ti ricordo che YUV a 8bit prevede il range 0-255, YCbCr no.

Veramente le cose stanno diversamente e la prova che hai postato sopra ne è un’ulteriore conferma.

Il processo di discretizzazione delle componenti YUV (lo spazio colore equivalente alle componenti YCbCr/YPbPr) non ha niente a che vedere con la campionatura a 8 bit/canale che riguarda i componenti RGB.
Il range della componente Y prevede valori percentuali da 0 a 100%, nonché una nutrita serie di decimali.
Mentre per i canali cromatici, (UV; CbCr; PbPr) benché descritti anche essi in un range percentuale (da -100% a + 100%), hanno un'ampiezza più limitata.
Ricordiamo anche che YUV, come RGB, è uno spazio colore senza sottocampionature, quindi 4:4:4.

Credo che la confusione nasca anche dal fatto che spesso si parla (lo faccio anch’io) di RGB come se fosse uno spazio colore, mentre è solo il tipo di divisione delle componenti di un’immagine.

Adobe RGB, sRGB, WideRGB Phot Pro RGB, PAL, NTSC, Secam, ecc… sono tutti spazi colori con componenti separate in RGB.

SWOP, TOYO, EuroStandard, ecc… sono spazi colore le cui componenti sono divise in CMYK

YUV, Lab, Luv, Hue, HLS, HSV, ecc… sono spazi colore con componenti divise in Luma e Chroma.

Qui sotto vedi uno spettro colore completo (colori primari + complementari + bianco + nero) e nell'animazione al suo fianco puoi vedere come la componente Y occupi tutto il range disponibile ed i limiti delle componenti cromatiche.


Cliccare le immagini per ingrandirle.

Per maggior chiarezza, qui vedi la differenza fra le componenti nei due sistemi.
In RGB i 256 livelli sono rappresentati per intero, mentre in Lab (spazio colore che utilizza la stessa divisione delle componenti Luma e Chroma dello YUV e che lo contiene) l'unico canale pieno è quello della luminosità.
Ben più ristretti gli altri due.


Cliccare le immagini per ingrandirle.

…, lo spezzone lo vedi nel range 1-254 solo dopo la conversione YUV che attua il tuo software, ovvero dopo l'espansione del contenuto originale 16-235 YCbCr in YUV 0-255

YUV è lo spazio colore che rappresenta le componenti YCbCr/YPbPr, non può determinare perdite di informazioni né espansioni e, vedi sopra, non è composto da un numero finito di sfumature.

La compressione-estrazione e relativi errori di quantizzazione e arrotondamenti, aumentano il numero di pixel diversi facendo raggiungere il numero di 253.

Fosse un problema di interpolazione la possibilità che ogni canale riporti gli stessi valori per ogni pixel è di 1 a qualche milione.
(ndr: il tasto Source serve solo a switchare fra l’ingresso video della scheda ed un flusso digitale letto da supporto, HDD o DVD)

Un'altra cosa, non è che c'è stata anche una riscalatura di mezzo, prima del conteggio pixel? Le immagini devono essere 720x576 e invece nel link che metti c'è 1024x576. L'algoritmo di riscalatura ci mette evidentemente del suo...

Come pure non c'entra la dimensione dell'immagine che ho postata, che è il frame da 720 solo visualizzato con il pixel aspect ratio 1:1,33 del PAL 16/9.

La ragione della completezza della rampa è nella conversione dai valori Y 0-100% in RGB 1-254.

Lo stretch che fai tu quando dici all’encoder di posizionare l’Y 0% in corrispondenza del 16 RGB ed il Y 100% in corrispondenza del 235 RGB ha come risultato il posizionamento dei valori sotto al 16 RGB nella zona del Black Crush, cioè sotto gli 0 IRE, ed i valori sopra al 235 RGB si posizionano sopra al white clipping.
Ma la luminosità rimane invariata a 0-100%.

Ecco perchè la funzione di trasferimento, che per il nostro PAL dovrebbe essere Y 0-100% = 0-255 RGB, da me ricrea le 254 sfumature.

Mentre il frame a 220 sfumature che hai estratto con Premiere è evidentemente sottoposto ad una funzione di trasferimento che rispetta lo standard NTSC, Y 0-100% = 16-235 RGB, ma, dato che il nostro materiale è in formato PAL e dato che la compressione MPEG2 PAL è a 1-254 RGB, ritengo che questo sia un errore.

Ed è per questo che penso che la versione 1.0.7 del DVDTest vada bene per verificare il Black Crush, ed anzi ti suggerirei di cambiare la scritta in “Black Crush” o qualcosa di simile e di fare anche una schermata simile per il White Clipping (anche per i singoli canali se possibile).
Ma credo anche che le schermate con i blocchi e le rampe così come sono non vanno bene, per i motivi suddetti.

gli yankees, ponendo il nero a 7,5IRE, hanno di fatto il range 0-100% del segnale utile distribuito su 92,5IRE ma questi sono affari loro...

Ma questo è quello che hai fatto anche tu, per questo dico che le schermate utili per la calibrazione erano meglio nelle precedenti versioni.

Gli americani usano un equivalenza: 16 - 235 RGB (sorgente) = 0 – 100% Y (compressione) = 7.5 - 92.5 IRE = 0 – 100% Y (e si fermano qui se hanno dei CRT) = 16 - 235 RGB (che poi devono espandere sui loro display digitali a 0-255 RGB)
Noi europei usiamo l’equivalenza: 0 - 255 RGB (sorgente) = 0 – 100% Y (compressione) = 0 – 100 IRE = 0 – 100 % Y (e anche i nostri CRT si fermano qui) = 0 – 255 RGB (e sui nostri display digitali non dobbiamo espandere niente)

Quello che hai fatto tu è una via di mezzo: 16 - 235 RGB = 0 – 100% Y = 0 – 100 IRE = 0 – 100% Y = 0 – 255 RGB che per la verifica del BC va benissimo, ma non per le schermate successive dove la nomenclatura di etichetta non corrispondente ai valori reali.

Se vuoi fare la prova del 9, estrai un frame dal DVD che ho fatto io per la verifica del BtB e guarda quanti colori contiene:
È fatto in b/n in MPEG2 PAL.

http://www.avmagazine.it/forum/showpost.php?p=666102&postcount=157

In questi giorni ne sto facendo una nuova versione con le dimensioni dei vari blocchi a multipli di 16 px, in modo da evitare qualunque approssimazione dovuta alla quantizzazione dei blocchi della compressione MPEG.

Tornando al mio videoscopio.
A conferma della validità delle letture effettuate, qui sotto trovi la lettura della schermata SMPTE (test pattern AVID ma ne trovi finché vuoi in rete).
Nella prima immagine ho riportato i valori rgb dei vari settori e nella lettura, a destra, ho riportato le corripondenze fra i valori di Y ed i relativi settori.


Cliccare le immagini per ingrandirle.

Come vedi le corrispondenze sono perfettamente in linea con la funzione di trasferimento ideale Y 0-100% = RGB 0-255.

Qui c’è una raccolta di alcune schermate delle rilevazioni che ho fatto e delle famose scene del Gladiatore che presentano neri sotto al 16 RGB.

Usando il DVDTest per allineare il Blanck Level, come descritto qui, e simulando con l’HDMI della sorgente il taglio del nero 16 (in RGB) o posizionando il nero a 7,5% (in YCbCr), si ottiene il mio stesso risultato (ovviamente non bisogna modificare i controlli di luminosità dopo l’allineamento del blanck level).



Ciao.

 

[Girmi]

Secondo me questa perdita di sfumature è il "difetto" maggiore dello standard dvd-video 16-235.
Però non ho idea quale sia l'impatto reale ai fini della visione.

Io resto dell'idea che il 16-235 non sia affato lo standard nella produzione di DVD moderni.

I problemi di visione di eventuale materiale, NTSC, così prodotto, dopo la necessaria ricalibrazione credo anch'io che siano molto limitati.

Visi, campiture, sfondi, zone sfuocate o alonate, possono essere quelle più esposte al rischio banding e dithering.

Per dare un'idea di quello che accade e di come si perdono queste informazioni, supponiamo che la prima schermata rappresenti il range completo 0-255 che si può trovare in un DVD PAL (è la mia solita schermata, usata anche nel mio BtB Test).
Osservando i livelli ed il color counter si vede che la gamma è piena, ci sono tutte le sfumature.
In una catena video PAL ben calibrata l'immagine in uscita sul display dovrebbe avere la stessa gamma piena.



Nel caso di materiale NTSC compresso a 16-235, la situazione che abbiamo è simile alla rappresentazione della seconda schermata.
Quando poi la calibrazione ci riporta a valori di luminosità e contrasto corretti, la situazione che ricreiamo è quella della terza schermata.



Affiancando la prima e terza immagine non si notano grandi differenze, ma alcune informazioni si sono perse e corrispondono ai buchi bianchi.
Se li contiamo sono proprio 36, la differenza fra 256 e 220.


Ciao.