Blacker than Black, come verificarlo correttamente?

[nemo30]

Il test THX serve proprio ad individuare il giusto livello di luminosità da abbinare al black-16.

Al black 7, forse.

[MauMau]

teoricamente il nero dovrebbe essere black-16.
E l'ombra (BTB) sarebbe andata bene teoricamente a black-15.

Ma THX, nella sua infinita saggezza, ha considerato che il test doveva funzionare su una schiera immensa di catene video (player, tipo di connessione, vpr, TV), non tutte in grado di visualizzare differenze di 1/256esimo (0,4% di separazione, mentre le scale di grigio che vediamo di solito hanno gradini di 5% o max 2%).
E forse anche l'occhio umano ha dei limiti a distinguere differenze di luminosità così piccoli ....

Perciò ha preferito mettere il BTB a black-7 per avere una differenza più percepibile rispetto al fondale.

Fra parentesi, stesso ragionamento per il livello del logo THX, che non è a black-17 (teoricamente sarebbe bastato), ma qualcosa in più.

[ciuchino]

Solito sistema di rilevamento piuttosto discutibile.

Il "nero" del vaso
http://img218.imageshack.us/img218/2127/prima.jpg

Zona soldato
http://img218.imageshack.us/img218/2061/seconda.jpg

Sin City
http://img218.imageshack.us/img218/8338/terza.jpg

Effettivamente qui' l'anemone colpita dal sole spara un po' , supera il canonico 235 ?

http://img218.imageshack.us/img218/967/quarta.jpg

Tanto per giocarci un po' .

[Girmi]

Durante il riversamento da pellicola a dvd si tiene conto del fatto che il nero deve essere digitalizzato come "black-16" (con qualche tolleranza), e si devono opportunamente istruire i player (e i software PC) che il livello 16 deve produrre un segnale di "luminosità zero".

Mau, continui a confondere la questione del BtB, o del segnale digitale in generale, che attiene esclusivamente alla catena video digitale e la sua rappresentazione analogica, cioè la sua visualizazione tramite vp (o altro display), che è fatta di luce, colore e saturazione.

A parte l'osservazione già fatta da Nemo (fra il 7 e il 16 c'è parecchia roba), un segnale digitale non può produrre o determinare alcun livello di luminosità predefinito.

È agendo sulla funzione di trasferimento del convertitore D/A (nel nostro caso il pannello LCD del vp) che si determina la luminosità corrispondente a quel segnale digitale (nonchè la crominanza e dominanza relative).

Le diverse "catene" di cui parli, altro non sono che diverse funzioni di trasferimento, anche la riduzione a 16-235 lo è.

Per assurdo io potrei settare il mio vp per fargli emettere un bel rosa intenso quando il segnale digitale che gli arriva è un RGB 0,0,0 o 16,16,16 o altro ancora.
Il segnale digitale sarebbe lo stesso, la sua conversione analogica no.

Chiarito questo, bisogna dire che ogni conversione D/A può avere una sola funzione di trasferimento perché possa dare un risultato definibile "calibrato" (e molto raramente la si trova).

Tutte le modifiche fatte a quest'unica possibile funzione danno sempre risultati soggettivi, come lo è la taratura THX o qualunque altra variante che renda l'immagine più piena o più calda o più feddra o che soltanto ci piaccia di più.

…catene video (player, tipo di connessione, vpr, TV), non tutte in grado di visualizzare differenze di 1/256esimo (0,4% di separazione, mentre le scale di grigio che vediamo di solito hanno gradini di 5% o max 2%).

Qualunque device analogica può discriminare segnali con delta ben inferiori allo 0,4%, come può farlo qualunque device analogica ad almeno 8 bit/canale, senza contare che ormai molti display sono a 10 bit se non oltre.

E forse anche l'occhio umano ha dei limiti a distinguere differenze di luminosità così piccoli

L'occhio umano può discriminare tali differerenze di luminosità ed anche molto più piccole.

Ciao.

[Girmi]

Effettivamente qui' l'anemone colpita dal sole spara un po', supera il canonico 235 ?

http://img218.imageshack.us/img218/967/quarta.jpg

Traddondosi di CG è molto facile che ci siano sforature.
Hai anche "Gli incredibili" da controllare?
Al momento io l'ho prestato, ma mi sembra ci siano molte "sciabolate" di luce.

Ciao.

[ciuchino]

Hai anche "Gli incredibili" da controllare?

Domani sera tempo permettendo provo a dargli un occhio.
Se a qualcuno nel frattempo viene in mente qualche sequenza particolare ... naturalmente per quello che vale questa misurazione un po' troppo artigianale.

Ciao

[br1]

Per favore non rapportiamo il fine -lo scopo- del test con i mezzi a disposizione.

Quando avevo un'altro hardware con un VPR LCD Hitachi ho penato tanto per visualizzare le varie scale dei bianchi e dei neri, con modesti risultati.

Adesso pur avendo un discutibile lettore DVD Samsung abbinato al VPR DLP, le scale vengono riprodotte bene, per nulla al mondo andrei a togliere qualche livello di nero del DVD Test di Merighi.

Ad ogni minimo dubbio nella visione dei film ho sempre verificato le regolazioni, poi ho constatato solo difetti dei DVD e sono tornato alla regolazione iniziale: visibilità dei livelli del nero, meglio ancora parlare di percezione dei neri.

Metto in evidenza ancora: il test in questione va a passi minimi di un singolo bit video.

Se ci sono dubbi personali riprodurre una Luma Ramp, del tipo presente sul disco test di AF Digitale, toglie le incertezze.
Nell'immagine ci sono i valori della luminanza Y dal minimo al massimo con spiegato che:
l'ideale sarebbe vedere tutto senza gradini, come se fosse un segnale analogico appunto che sfuma dal nero al bianco.

Torniamo alla scala dei neri
La scala dei neri deve essere visibile quanto più possibile, con il VPR DLP va tutto abbastanza bene, ma se provo mandare il test sul mio monitor LCD Sony della serie X mi tornano in mente tutti i trascorsi.
E' come leggo da vari commenti: l'immagine è poco gradevole se regolata per vedere tutti i 16 livelli della scala dei neri.

Una verifica
Per scrupolo l'altra settimana ho riportato a casa il VPR Canon a tecnologia Lcos, ci ho collegato pure il PC, ma niente da fare, ha poco contrasto:
1000:1 non rende giustizia bisogna scurire l'immagine perdendo qualche livello del nero per vedere decentemente.

Per vederci chiaro nelle ombre...
Ma se devo essere giusto il contrasto 4000:1 (puramente teorico) del mio DLP mi sta un pochino stretto.
Per prova ho misurato con un Luxmetro il contrasto sullo schermo di proiezione utilizzando le immagini THX: ho rilevato circa 150:1 di contrasto reale tra la barra più chiara e quella più scura.... ho detto tutto mi pare.

Br1

[MauMau]

Solito sistema di rilevamento piuttosto discutibile.

ciuchino, ti adoro !!!

Se poi riuscissi anche a scovare fra il nero qualche pixel di livello <16, sarebbe una buona conferma della teoria.

Per il livello elevato dell'anemone non ti preoccupare: il "Whiter than White" è una questione molto meno rigida del BTB.

[ciuchino]

Stasera zoommo e posto pixel-x-pixel le componenti RGB.
In fondo sono solo 1280x720

[Girmi]

In fondo sono solo 1280x720

Come sarebbe 1280x720?
Stai parlando di trailers HD o di roba postprocessata?

Non puoi analizzare il flusso MPEG2 nativo?

Ciao.

[ciuchino]

C'e' la decodifica mpeg2 e lo scaling alla risoluzione del mio pannello.
La cosa dovrebbe essere trasparente dal punto di vista livelli.
Hanno gia' fatto delle prove in proposito :
http://theatertek.com/Forums/showthr...hlight=dgindex

Se no' mi devo attrezzare con DGINDEX che sembra in grado di catturare i frame come si deve ... ad aver voglia.
Ma per queste cose tu sei molto piu' preparato ed attrezzato.

Ciao

[Girmi]

C'e' la decodifica mpeg2 e lo scaling alla risoluzione del mio pannello.

Temo che queste due azioni influiscano sulla conversione dello spazio colore originale.

Come vedi qui sotto fra lo spazio PAL (che è un sottospazio YUV) ed il sRGB (che è un sottospazio RGB e che è quello tipicamente usato da Windows), non c'è corrispondenza.
In particolare lo spazio sRGB è più stretto e quindi richiede una rimappatura totale (la richiederebbe comunque data la differenza di spazi origine YUV-RGB) .



I rilevamenti che faccio io si riferiscono ad una conversione degli spazi di origine, enormemente più ampi dei rispettivi sottospazi.

Non conosco TT, ma credo che da qualche parte vada a pescare un profilo per la conversione e se non è assegnabile manualmente si rifarà a quello di sistema.
Quindi, a meno che tu non riesca ad implementare a livello di OS il profilo PAL (o NTSC se il DVD è NTSC), qualunque file tu vada a decomprime e scalare subisce una rimappatura che inficia qualunque rilevamento.

C'è poi Paint Shop Pro che non quanto sia affidabile. Anche qui bisognerebbe essere sisuri di usare un profilo PAL o nessun profilo.

Per verficare l'affidabilità della tua catena puoi fare una prova.
Scarica questo file. Sono le barre originali SMPTE, fornite con AVID.
Puoi notare che la scala riprodotta rispetta le specifiche CCIR601, quelle che dicono di tagliare sotto al 16 e sopra al 235, però contiene anche il livello 7 che, guarda caso, corrisponde al lower level consigliato da THX.

Prova a convertirlo in filmato MPEG2 ed a processarlo allo stesso modo degli altri ss.

Poi confronta le letture con i valori fra i due file e soprattutto con quelli originali che sono questi:



Se qualcosa dovesse non corrispendere, allora le misurazioni fatte sono nulle.

Ho dato uno sguardo veloce alle caratteristiche di DGINDEX e non ho notato da nessuna parte che legga i valori YUV del flusso MPEG2, li converte e basta.

Quello che a noi interessa, ai fini della discussione, sarebbe proprio il valore Y, la luminanza, che io rilevo con l'analizzatore si spettro che ho già fatto vedere.

Ciao.

[ciuchino]

Girmi tu vai ad analizzare cose molto piu' a fondo e native.
Come ho gia' detto i livelli che dichiara il DVE nel suo disco di test , quindi gia' encodato da loro in mpeg2 me li ritrovo paro paro.
Ho gia' analizzato un frame di un DVD con DGINDEX che salva in BMP come TVSCALE o PCSCALE (livelli espansi o meno) ed il risultato finale e' sempre quello ... livello 16 o zero (con perdita di eventuale BTB) per il nero.

Sono daccordo con te' ma poi alla fine a me' interessa cosa mando al VPR ... cioe' segnale decodificato e scalato.
Sono chiaramente tutte cose interessanti ma poi dovrei chiedermi se ho fatto encoding corretto in mpeg2 ... cose troppo difficili per me'.
In ogni caso chiaramente ti ringrazio delle tue spiegazioni che leggero' sicuramente attentamente ... e magari ci provo anche.

Ciao

[Girmi]

…poi dovrei chiedermi se ho fatto encoding corretto in mpeg2…

Prova allora a processare il file MPEG2 che ho postato io:
http://www.avmagazine.it/forum/showp...&postcount=157

Quello è sicuramente codificato come si deve e, a parte gli sporchi sui livelli 0-3 già discussi, dovresti poter rilevare tutti i livelli 0-253 con scarti inferiori ad 1 livello fino a ca. 180 e inferiore a 2 sopra.

Ciao.

[Luciano Merighi]

scusate l'assenza ma ho veramente dei problemi ad essere "presente" e a fare le prove che vorrei. Comunque ho giocato con CCE encoder mpg che ha la possibilità di due impostazioni:
16-235 e 0-255

nei due rispettivi casi applica le seguenti operazioni algebriche ai valori RGB presenti nei frames che gli vengono dati in pasto:

When “16 to 235” is specified
RD = 219R + 16 × 256
GD = 219G+ 16 × 256
BD = 219B + 16 × 256

Y = (77RD + 150GD + 29BD) / 2^16
CR = (131RD − 110GD − 21BD) / 2^16 + 128
CB = (−44RD − 87GD + 131BD) / 2^16 + 128

mentre
When “0 to 255” is specified
Y = (77R + 150G+ 29B) / 2^8
CR = (131R − 110G − 21B) / 2^8 + 128
CB = (−44R − 87G + 131B) / 2^8 + 128

In any case, decimals in the result of the division are omitted.

se vi volete divertire vedrete che nel primo caso i risultati di grigi RGB in input 0-255 verranno scalati e compressi nel canonico range di Y 16-235, con gli arrotondamenti del caso.

Nel secondo caso passeranno immutati.

Con questa premessa un po' da "fenomeno" ho codificato la stessa sequenza dei neri presente nel mio test, aspettandomi quindi che nei files ottenuti vi fossero, in un caso valori da 16 a 235 e nell'altro da 0 a 255 (salvo il fatto che i livelli 0 e 255 sono non ammessi per evitare imprecisate noie in fase di sync dell'informazione).
Non potendo interpretare con un editor esadecimale gli effettivi valori perchè non sono capace..., sono passato alla visualizzazione analogica, certamente senza nessuna castrazione sui neri.
Il caso 16-235 mostrava esattamente lo stesso aspetto del mio test originale, cioè i neri 1,2,3 ecc. distinguibili con un minimo sforzo dallo sfondo. Aumentando la luminosità, si aumentava naturalmente la loro visibilità.
Il caso 0-255 mostrava un'immagine con il nero 16 all'incirca allo stesso livello di distinguibilità sullo sfondo dell' "uno" dell'altro caso. Aumentando la luminosità arrivavo a distinguere fino all'uno ma ovviamente con un'inaccettabile set-up complessivo.

Seconda prova, estrazione e analisi dei frames con il mio metodo, cioè premiere 6.5 e photoshop.

Da entrambi i files ottenevo dei tiff in range rgb 0-255, con quello ottenuto dall'mpeg 16-235 che continuava fisicamente a mostrare tutti i livelli presenti nel frame originale (con qualche piccolo errore da arrotondamento). Il tiff estratto dall'mpeg 0-255 era anch'esso in range rgb 0-255 ma con i livelli sotto il 16 totalmente scomparsi.

Altra prova, ho codificato una rampa RGB larga 512 pixel con valori nel frame originale da 0 a 255, per avere colonne di 2 pixel adiacenti con step di variazione di 1 livello.
Nel mio test, come con CCEncoder 16-235 si ottine una visione da DVD con delle quasi impercettibili irregolarità verticali. Pensavo che dipendessero da errori dell'mpeg ma la stessa rampa codificata con CCEencoder 0-255 appare invece perfetta e con i set-up del lettore che uso normalmente brucio i bianchi da 236 a 255 e perdo i neri da 1 a 15 a meno di agire sui controlli del display.

Non ho ancora provato il frame di Girmi ma non ho elementi per pensare di ottenere un risultato dissimile.
Per Girmi: tenderei a non usare un frame in scala di grigi perchè temo che l'encoder in qualche modo possa essere ingannato.

Che dire? sono sempre più convinto che pur andando bene per regolare il proprio display, l'attuale versione del mio test non vada bene per verificare il BTB. Ci mi fa rammaricare perchè prima sostenevo a spada tratta il contrario...

Credo che molte tecniche per estrarre informazione dall'mpg diano per scontata la presenza del range normalizzato BT601 e applichino di default, senza dirlo espressamente, la compensazione inversa quando convertono lo spazio colore YcBcR nuovamente in rgb e che di conseguenza portino a conclusioni errate sotto l'aspetto formale.
Purtroppo il fatto di non avere un display HDMI mi impedisce il condurre prove sistematiche in quest'ambito.

Se avrete un po' di pazienza, vorrei preparare delle sequenze BTB e WTW codificate nei due modi, così chi vorrà potrà fare tutti i test del caso.

Un'altra cosa di cui sono ormai convinto, è che se un encoder mpg non permette di scegliere il range, quasi certamente lavora in quello normalizzato. Se ci pensate non è una castrazione, anche i valori di tensione analogica di un segnale video, espressi in modo relativo in "IRE", prevedono un abbondante spazio al di sopra del tetto di 100, è previsto addirittura che i sitemi clippino a 140IRE. Magari si poteva guadagnare spazio in basso dove il fatidico livello 16 è allineato ai 7,5IRE del nero NTSC americano (in giappone è a zero IRE come nel PAL). Non so se il motivo risieda in miopia o nel voler qualcosa di universalmente utile. Il limite del digitale consumer sta purtroppo negli 8 bit finali, dove ai 256 livelli possibili, già molto pochi, vengono rubati quelli in alto ma soprattutto quellli in basso.

Ancor più in generale, credo sia importante poter visualizzare BTB e WTW ma senza incaponirsi, limitandosi al massimo a qualche step, anche perchè la regolarità del gamma dei display digitali, soprattutto sui nerissimi, è solitamente poco regolare e quindi vanifica ogni tentativo di raggiungere gli estremi in modo accettabile.

Spero di non aver scritto toroppe frescacce...