Newsgroup: it.media.video.produzione
Titolo: Guybrush, per favore...

mi aiuteresti a spiegare meglio il 25PfS applicato al miniDV (vedi DVX100 e
XL") a luca pochi thread più sopra?
Vedi thread 'Canon XL2, prime impressioni'
grazie e ciao
Gary

 XL") a luca pochi thread piů sopra?
Dunque...
Ho letto adesso il thread e devo dire che in una certa misura avete ragione 
tutti e due, prima di spiegarti perche' ti ricordo della notazione "25 PsF" 
di cui avevo gia' parlato...
Allora, l'errore di fondo sta' nel pensare che un flusso dati possa avere 
una struttura interallacciata o progressiva, un flusso dati e' un flusso 
dati punto... Non e' piu' come con il beta in cui ad ogni giro del tamburo 
testine veniva registrata una linea di scansione (in realta' alcune cose 
sono rimaste simili, ma non complichiamo troppo).
L'unica differenza tra uno stream DV progressivo ed uno interallacciato e' 
il modo in cui viene applicato il sottocampiomento del croma, questo perche' 
lo schema 4:2:0 e' asimmetrico...
Mi spiego meglio, se io registro un segnale interallacciato non posso 
prendere il croma solo delle righe pari (2) e ignorare quello delle righe 
dispari (0), perche' in questo modo avrei il grosso problema che il secondo 
field erediterebbe il croma del primo, quindi un oggetto colorato che si 
sposta lascerebbe dietro di se' un alone colorato.
Per evitare questo problema si divide in linee pari e dispari anche il 
subfield; quindi, considerando il field1 composto da 720 pixel x288 linee di 
scansione, il croma associato sara' da 360 pixel x 144 linee (2:0), stessa 
cosa sul field2.
seguimi, il field1 avra' le linee 1, 3, 5, etc. da cui viene prelevato il 
colore, il field2 stessa cosa, quindi in un ipotetico still avresti questa 
situazione:
1 field1-riga1 (2) 720 pixel luminanza + 360 pixel colore
2 field2-riga1 (2) 720 pixel luminanza + 360 pixel colore
3 field1-riga2 (0) 720 pixel luminanza + 0 pixel colore
4 field2-riga2 (0) 720 pixel luminanza + 0 pixel colore
5 field1-riga3 (2) 720 pixel luminanza + 360 pixel colore
6 field2-riga3 (2) 720 pixel luminanza + 360 pixel colore
7 field1-riga4 (0) 720 pixel luminanza + 0 pixel colore
8 field2-riga4 (0) 720 pixel luminanza + 0 pixel colore
9 field1-riga5 (2) 720 pixel luminanza + 3600 pixel colore
e cosi' via...
Puoi verificarlo facendo un semplice pattern di test e comprimendolo in DV, 
il primo pattern lo fai con una riga rossa ed una blu alternate, il secondo 
lo fai con due righe rosse, due blu alternate, vedrai che il primo risulta 
uguale a come l'hai creato, il secondo sara' magenta o tutto rosso o tutto 
blu, a seconda di come funziona il codec, ovvero se fa' la media tra le 
linee o se si limita a prendere la prima o la seconda.
Questo e' all'origine del famoso problema sui bordi colorati (ed e' il 
motivo per cui i chroma key riescono male), questo accade perche' 
l'interpolazione della linea mancante avviene a livello di field, quindi la 
sequenza delle linee interpolate e' piu' o meno cosi':
1 field1-riga1 (2) 720 pixel colore interpolati dai 360 originari
2 field2-riga1 (2) 720 pixel colore interpolati dai 360 originari
3 field1-riga2 (0) 720 pixel colore interpolati da field1/riga1 + 
field1/riga3
4 field2-riga2 (0) 720 pixel colore interpolati da field2/riga1 + 
field2/riga3
5 field1-riga3 (2) 720 pixel colore interpolati dai 360 originari
6 field2-riga3 (2) 720 pixel colore interpolati dai 360 originari
7 field1-riga4 (0) 720 pixel colore interpolati da field1/riga3 + 
field1/riga5
8 field2-riga4 (0) 720 pixel colore interpolati da field2/riga3 + 
field2/riga5
9 field1-riga5 (2) 720 pixel colore interpolati dai 360 originari
etc...
come vedi l'informazione di croma sulla riga 2 (la 3 riga del frame) e' 
ottenuta tramite l'intepolaione del croma della riga 1 con quello della riga 
5.
La cosa non accade in HDCam o IMX o DigiBeta o SX o DVCpro50 o, addirittura, 
col DVCpro25 perche' lo schema 4:2:2 (3:1:1 HDCam, 4:1:1 DVCpro25) fa' si' 
che ogni riga di scansione abbia la sua informazione di croma, quindi non 
rimane quella voragine di due righe tra le linee dispari e le linee pari dei 
due field e non e' necessario estrapolare per interpolazione le informazioni 
mancanti.
Veniamo a noi, e' logico che registrando dati digitali che devono essere 
caricati in un buffer prima di poter essere inviati alle uscite video ce ne 
si puo' strabattere dello schema progressivo o interallacciato; pero' se io 
riprendo in progressivo l'encoder della camera deve decidere come applicare 
lo schema 4:2:0, se applicarlo all'intero frame o al singolo field.
Il problema fondamentale e' che, a quanto pare, non tutte le macchine ed i 
software si comportano allo stesso modo.
Io ho fatto alcuni esperimenti con Vegas, Virtualdub ed altri programmi; il 
risultato e' stato perlomeno strano...
Se io assegano il flag progressivo interallacciato o progressivo al pattern 
rosso/blu/rosso/blu e lo comprimo in DV interallacciato e progressivo 
(rispettivamente) il pattern non cambia, se io invece mischio le due 
caratteristiche succede un casino, ovvero se assegno il flag progressivo al 
materiale e poi lo comprimo in iterallacciato (o viceversa) il risultato 
sara' di un bel violetto uniforme; stessa cosa col pattern 
rosso/rosso/blu/blu.
In pratica tutta la lavorazione deve essere effettuata nello stesso formato 
di acquisizione pena la perdita' di almeno il 50% dell'informazione colore.
La Panasonic ha scelto di mantenere la migliore compatibilita' possibile 
utilizzando la modalita' 25 PsF (Progressive Segmented Frame e' il nome che 
usa Sony da quando introdusse questa modalita' per l'HDCam) o 25p on 50i 
(come la chiamano ultimamente altri produttori); Canon mi risulta che setti 
effettivamente il flag del progressivo; ma, come avrai gia' letto nel posti 
di Herik, non e' compatibile con tutte le macchine presenti sul mercato o 
con tutti i software.
In sostanza il problema e' come gli encoder trattano l'informazione colore 
(l'informazione di luminanza e' sempre quella perche' non viene 
sottocampionata), la tua camera tratta il progressivo come fosse un 
interallacciato per massimizzare la compatibilita' al prezzo di qualche 
problema sui bordi degli oggetti colorati, la Canon in teoria avrebbe un 
progressivo senza quel problema (peccato che in pratica non abbia un sensore 
progressivo) che pero' non e' completamente compatibile con tutto il resto 
del mondo; Sony, dal canto suo, ha sempre preferito fare camera 
interallacciate e stop.
Il discorso sarebbe anche un po' piu' ampio, ma senza la possibilita' di 
inserire uno straccio di immagine e' troppo difficile spiegare bene la 
questione.
Spero di essere stato esauriente, se invece non ho centrato il problema... 
ditemelo, ma con tatto!
Probabilmente con l'HDV qualcosa cambiera', anche perche' il formato Mpeg2 
prevede 

 ditemelo, ma con tatto!
Ciao Guy, interessantissima la discussione sul sottocampionamento del
chroma progressivo/interlacciato (che magari continueremo), ma io e Gary
siamo ancorati molto prima...
La sostanza e' questa: Gary (e con lui Panasonic e altri "esperti") dicono
che un fotogramma di uno stream DV e' codificato in 2 immagini
indipendenti 720x288. Io, invece, sono sicuro al 100% (e posso presentarne
gli "prove"... oppss, gli algoritmi) che lo stream DV e' frame based, con
la possibilita' di codificare ogni singolo blocco 8x8 progressivo o
interlacciato.
Ciao ciao,
  Luca
P.S.: io mi rifaccio vivo domenica.

 ha scritto nel
messaggio news:46157272$0$36450$4faf...@reader5.news.tin.it...


 hai fatto qualche bella foto ai bimbi almeno?
Uno come te che critica me!!!  Non c'è più religione!!!
Ciao
Stefano

 interlacciato.
io penso che guy ti abbia ben dimostrato la 'sostanza' del discorso
Indipendentemente da come sia codificato lo stream miniDV, Panasonic ha
fatto la scelta di trattare e trasportare il segnale progressivo come se
fosse una scansione interallacciata. Punto.
In pratica tratta la scansione progressiva come se fosse una scansione
interallacciata.
Così facendo ci guadagna in compatibilità: con qualsiasi macchina, con
qualsiasi TV, con qualsiasi NLE tutto funziona alla perfezione.
Se inece avesse trasportato la scansione progressiva come un segnale
progressivo sarebbero sorti una miriade di problemi di compatibilità.
Per questo ti dicevo che è 'l'uovo di Colombo'.
Tu dici che il codec miniDV può trasportare la scansione progressiva e
questo è vero.
Panasonic semplicemente non se ne avvale.
Ti ho anche dato le PROVE che è così:
-la registrazione progressiva della 100 è sempre visibile, ovunque e
comunque, cosa che non è vera per uno stream miniDV in cui il flag
progressivo sia attivo;
-si può sbattere sulla timeline materiale progressivo ed interallacciato
senza creare nessun problema a nessun tipo di editor, ivi compreso WMM
-se si effettua il deinterlace di una registrazione panasonic 50i non si ha
un dimezzamento della risoluzione
Da qui l'estrema flessibilità di questo stratagemma, flessibilità che non si
sarebbe mai riscontrata se fosse stato attivato il famigerato flag.
Piuttosto Guy mi ha chiarito un'altra cosa. Avevo pensato che anche la Xl2
funzionasse così, invece è molto peggio, perchè se è vero che il sensore
della XL2 è interallacciato e il flag progressivo viene attivato se ne
ricava che per il primo motivo quello della XL2 è un falso progressivo, che
presenta solo gli svantaggi del formato (strobing) e non i vantaggi e che
per il secondo motivo c'è un crollo verticale della compatibilità (con i NLE
e con altri riproduttori che non siano la stessa XL2), come dimostra il
fatto che Herik non riuscisse a far leggere lo stream progressivo generato
dalla XL2 ad una lettore sony.
Se così è, la 100 rimane in pratica l'unica camera miniDV al mondo che
riprenda in progressivo
ciao
Gary

 ditemelo, ma con tatto!
più che esauriente, come del resto mi aspettavo
Per cui, a questo punto, è solo un problema di termini.
Basta usare la definizione 'a 100 tratta e trasporta il segnale proveniente
da una scansione progressiva come se fosse proveniente da una scansione
interallacciata' e non si dicono cazzate. Giusto?
Però rimane la sostanza del discorso: questo stratagemma 'azzera' qualsiasi
problema di compatibilità e permette di ricostruire il progressivo 'puro' in
qualsiasi momento senza perdita di qualità.
E non mi pare poco, così come dimostra anche il fatto che questa modalità è
stata adottata anche da codec più blasonati e addirittura da quello che oggi
può essere definito il miglior codec HD, ovvero l'HDcam.
Ciò che invece mi ha lasciato basito è il funzionamento della XL2: io
pensavo che il sensore fosse progressivo e adottasse il 25PfS come la 100
(Guidelli mi ha sempre detto così).
Se invece è come dici tu la cosa è grave, perchè abbiamo una scnsione
interlacciata che viene trattata come se fosse progressiva.
Quindi il progressivo non è vero ma simulato ed in più il modo in cui viene
trasportato riduce drasticamente la compatibilità del girato.
Bella roba
ciao e grazie ancora
Gary


Il punto e' proprio questo (spiegandolo col croma pensavo fosse piu' 
intuitivo) e' ovvio che per comprimere l'encoder deve sapere come 
comportarsi a seconda dei dati da trattare.
Capiamoci un attimo, se io devo comprimere un macroblocco da 8x8 in 
modalita' interallacciata il sistema piu' semplice e' aggregare tutte le 
righe del field pari e tutte le righe del field dispari in due macroblocchi 
separati:
11111111
22222222
11111111
22222222
11111111
22222222
11111111
22222222
questo e' molto difficile da comprimere, ma:
11111111 - 22222222
11111111 - 22222222
11111111 - 22222222
11111111 - 22222222
questi due macroblocchi hanno (tendenzialmente) aree simili tra loro, quindi 
una ridondanza molto alta, il che crea le condizioni ideali per il lavoro 
della DCT.
A questo punto mi sembra evidente che il sistema piu' semplice per 
comprimere un immagine interallacciata (completa del suo croma) e' di 
dividerla in gruppi di dati piu' piccoli e quindi applicare la DCT su 
macroblocchi provenienti da immagini omogenee...
In soldoni e' come se l'encoder, quando deve trattare un segnale 
interallacciato, lo dividesse in due immagini da 720x288 con 360x144 pixel 
per il croma;
questo perche' e' in assoluto la cosa piu' semplice.
In progressivo puoi comprimere tutto il frame applicando la DCT all'immagine 
intera senza fare distinzione tra field perche' aree adiacenti dell'immagine 
sono
omogenee, cosa che invece non accade con segnali interallacciati.
Questa cosa, pero', non incide in alcun modo sul risultato finale con 
immagine progressive, perche' non avendo una decimazione del segnale a me 
non cambia nulla il fatto di aggregare le righe dei field o meno; mentre mi 
cambia molto il metodo con cui tratto il croma, preche' dato che qui decimo 
(e pesantemente) l'informazione, quando vado a riapplicare la trasformazione 
rischio di avere un'ulteriore perdita del 50% dell'informazione di croma.
Il resto e' solo questione di mettersi d'accordo su come intepretare i 
dati... 

Mi pare chiarissimo, sei stato di una luminanza esemplare :-)
Vediamo un po': se il sensore di una camera è "davvero" progressivo,
posso tranquillamente applicare il 4:2:0 all'intero frame perchè
l'eventuale secondo field derivato (nel caso io abbia registrato in
modalità interlacciata) è pur vero che non avrebbe nemmeno un chroma
suo, ma siccome è stato ripreso esattamente insieme al primo field (da
cui è stato separato solo in fase di registrazione) non mi ritroverò
*mai* un oggetto colorato con la scia dietro.
Al contrario, se il sensore è interlacciato mi conviene applicare il
4:1:1 tipo DVCPro. E se proprio devo uscire in DV 4:2:0, mi tocca
applicarlo ai singoli fields (che comunque vengono acquisiti in tempi
diversi) col risultato inevitabile di una quantità più o meno evidente
di pasticci sui bordi.
Ho capito giusto?
PS: perchè "probabilmente in HDV sarà diverso"? Io sapevo che la
compressione usata per l'HDV riguarda l'interframe dei macroblocchi
16x16. Cosa c'entra col sottocampionamento colore? Dove sbaglio?

 della XL2 è interallacciato
Per quello che ne so io, i sensori della XL2 sono progressive scan come
quelli della 100 (perlomeno, questo e' quanto dichiara Canon: che poi sia
corretto... e' tutta un'altra storia). Era la XL1 che aveva i sensori
interlacciati e, per fare il progressivo, prendeva un campo dal CCD verde
e l'altro dal rosso e dal blu, e poi faceva un po' di interpolazione sulla
falsa riga del bayer pattern.
Ciao ciao,
  Luca

 
Ciao luca....stò cercando da ieri di mandarti un email ma mi
dà sempre errore....cmq buona Pasqua anche a te e alla tua
famiglia...ciao.

 una ripresa fatta con la 100 in progressivo? La mia mail e' valida.
ti va bene in canopus DVcodec? Io il mio materiale acquisito ce l'ho tutto
così
ciao
Gary

 famiglia...ciao.
Grazie mille, anche a te.
Ciao!
  Luca
P.S.: Ti ho spedito una mail e ho provato a spedirmene una: io non ho
problemi....

 così
Sarebbe meglio avere "l'originale" (ma mi stai dicendo che quando
acquisisci, il video viene ricodificato?!?), pero' se e' il materiale con
cui lavori va bene questo.
Grazie mille,
  Luca



Ho provato con la mia fastmail a mandarla....sembra che vada bene adesso
(ti è arrivata?) ciao
p.s. sei un grande!

 cui lavori va bene questo.
no, dovrebbe cambiare solo gli headers... ma non so se questo può inficiare
la tua analisi
Altrimenti devo acquisirtela con il notebook e mi devi dare un po' di tempo
Sul sito Canopus puoi scaricare il codec (solo visualizzazione) ed anche un
convertitore caso mai ti servisse
ciao
Gary

 convertitore caso mai ti servisse
Non dovrebbe, comunque grazie per la segnalazione.
Attendo...
Ciao,
  Luca

 Attendo...
un'ultima cosa: se ho capito bene devo tradurre luca in inglese per ottenere
il tuo indirizzo.
Corretto?
ciao
Gary

PS = OK, gli impegni di pranzo pasquale mi chiamano
Fammi capire 'sta cosa della mail e nel pomeriggio ti mando uno stream di
alcuni secondi
ciao
Gary



Sono attivi entrambi gli indirizzi (lucainenglish o luke punto mabat). Non
mandare piu' di 5MB per evitare di sforare il limite della mail.
Ciao e BUON APPETITO!!
  Luca

Inviati... divertiti
:-)
ciao
Gary

 50% dell'informazione di croma.
Premettendo che anche il chroma puo' essere codificato progressivo (8x8) o
interlacciato (2x4x8) indipendentemente dal modo in cui viene campionato,
effettivamente il PAL DV e' abbastanza un bagno di sangue per la
crominanza, e non solo se il sensore e' progressivo, ma anche per quanto
riguarda un semplice DV "standard" con scansione interlacciata.
Come dici tu, bisogna stare molto attenti come lo si tratta, tenendo anche
in considerazione che Cr e Cb sono campionati su 2 righe differenti.
Alcuni codec DV (tipo quello Microsoft, mi pare) considerano la crominanza
nel 4:2:0 progressiva, altri sono un po' piu' furbi e tirano fuori un
4:2:2 (tipo la libdv), semplificando la gestione del chroma in tutta la
pipeline produttiva.
Tutto questo, comunque, esula dalla compatibilita' con qualsiasi
videocamera/lettore: il problema rimane solo quel bit per fotogramma, che
e' facilmente modificabile senza ricodificare. Certo che Sony - che
da quel che ho capito e' l'unica che si rifiuta di riprodurre uno stream
con questo bit - ce l'ha veramente a morte con il progressivo....
L'unica controindicazione e' che, se riprodotto da un altra videocamera su
un televisore, potresti avere qualche artefatto sui colori. E qui sorge
spontanea una domanda: ma qual e' lo scopo di riversare su nastro (a parte
il backup, per il quale non si applicano i problemi della crominanza)?
Ciao,
  Luca

 sarebbe mai riscontrata se fosse stato attivato il famigerato flag.
Gary, parliamo sempre di flag (che si modifica in un lampo, anche durante
l'acquisizione). Perdonami, forse abbiamo dei parametri di giudizio
completamente differenti, ma definire un flag "l'uovo di Colombo" mi
sembra profondamente eccessivo...
Rimane, per il PAL, il problema del chroma sollevato da Guy. Visto che le
fonti da cui attingiamo sono inaffidabili, come facciamo a sapere in che
modo viene campionato il chroma? Possiamo dire che la 100 lo campiona a
righe alterne e la XL2 progressivo? Che test possiamo fare per capirlo?
Ciao ciao,
  Luca

 il backup, per il quale non si applicano i problemi della crominanza)?
Eh? Non ho capito la domanda. 

 Eh? Non ho capito la domanda.
L'eventuale problema sulla crominanza lo avresti se tu usassi il player
per vedere il video sul televisore. La domanda si puo' quindi girare in
questo modo: ha ancora qualche senso collegare un player/videocamera DV
direttamente al televisore?
Ciao,
  Luca

 direttamente al televisore?
No, ma se produci un DVD con uno schema di croma differente da quello di 
ripresa il casino ce l'hai eccome! 

 ripresa il casino ce l'hai eccome!
OK, sono d'accordissimo. La domanda era solo per capire se il problema di
compatibilita' con i lettori miniDV era anche quello relativo al chroma o
solo quello del flag.
Ciao,
  Luca

 solo quello del flag.
Secondo me e' solo una questione di flag; il motivo, forse, sta' nel fatto 
che un progressivo "forzato" dovrebbe uscire con frequenze di riga e quadro 
un tantinello fuori standard (dovresti avere un 25Hz di quadro...), quindi 
alcuni apparecchi decidono semplicemente di blankare le uscite, l'altra 
possibilita' e' quella di prendere il progressivo e trasformarlo in un 
interallacciato in modo da renderlo compatibile col resto del mondo 
(ricostruisci il frame e lo invii alle uscite come due field separati*), la 
terza ipotesi (uscire a 25 Hz) non credo sia percorribile per ora, questa 
modalita' resta confinata al campo dell'editing su computer. Certo visto che 
la PS3 esce in 24p... magari... in futuro...
*in effetti questo e' un test che si fa' abbastanza spesso coi deinterlacer 
dei pannelli LCD/Plasma (ma anche coi TV 100Hz), si invia un segnale 
progressivo in forma interallacciata per vedere se lo scaler/deinterlacer lo 
riconosce. 

 secondo quello schema.
Si', diciamo che i decoder trasformano tutto in un unico frame,
indipendentemente da come sono codificati i singoli blocchi. Poi, pero',
possono fare macelli quando espandono la crominanza...
Ciao e grazie,
  Luca