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.