Newsgroup: it.media.video.produzione
Titolo: come si acquisisce in RGB?

Una grande parte di noi usa le telecamerine con la firewire e acquisisce in
DV PAL; bel formato, non c'è che dire, ma pur sempre compresso.
Ma ammettiamo, per assurdo, che una volta io volessi cavarmi lo sfizio di
vedere la differenza tra una clip DV ed una RGB, acquisita così come esce
720x576x3colorix25fps ecc ecc.
Come posso fare, ammesso che il flusso di dati non sia improponibile
attraverso una porta FW o USB2?
Il sensore della telecamera "acchiappa" tutto quello che arriva, ma al
nastro arriva il flusso già codificato DV: esiste un modo per aggirare
questo ostacolo e provare per una volta l'ebbrezza del "non compresso"?
Ho detto una cazzata?
Ciao

Ciao, Derrick!
Il giorno 25/09/2003 alle ore 18:58 hai scritto:
 D> Come posso fare, ammesso che il flusso di dati non sia improponibile
 D> attraverso una porta FW o USB2?
720x576x3x25 = circa 29 megabyte al secondo, sia la firewire che USB2
dovrebbero farcela (la firewire va 400 mbit, non ricordo USB2 ma siamo li).
Il problema e' che non esiste una videocamera consumer che esca in questo
formato, per non parlare del transfer rate necessario per i dischi (e lo
spazio ovviamente).
 D> Il sensore della telecamera "acchiappa" tutto quello che arriva, ma al
 D> nastro arriva il flusso già codificato DV: esiste un modo per aggirare
 D> questo ostacolo e provare per una volta l'ebbrezza del "non compresso"?
Si certo, se sei pratico di microcontrollori e programmazione assembler,
puoi riscrivere parte del firmware del microprocessore che equipaggia la
videocamera in modo che faccia uscire il segnale RGB piuttosto che il DV.
 D> Ho detto una cazzata?
Diciamo che l'informatico non e' magia.
Bye

 ha scritto nel messaggio
news:a9Fcb.166186$R32.5...@news2.tin.it...

Assolutamente no. Ma hai messo il dito su un bel punto.
Ma proprio qui sta il nocciolo che divide il mondo
degli amatori dal mondo professionale. L'hardware
necessario per acquisire in component e con una
compressione diciamo di 2:1 o meno, che praticamente
è lossless.
Con una firewire non puoi farlo se non hai
un opportuno hardware, interno o esterno.
Che ha un costo non indifferente, almeno fino ad ora.
Per avere una idea della qualità.... beh, un sistema
semplice ci sarebbe.
Guardati la televisione alla sera su delle reti che hanno
una emissione degna, diciamo RAI 1 o C5.
Tutto ciò che vedi montato e che presumibilmente
è ripreso con una camera DV passa attraverso il processo
di cui sopra. Comparalo con quello che riesci
a fare con il tuo piccì, tieni conto che loro hanno di mezzo
un casino di passaggi, memorie di quadro e registrazioni,
una emissione e una antenna trasmittente e ricevente.
Quella è la differenza che vuoi vedere.


Mi sa che il calcolo non è proprio esatto... ne in teoria
ne in pratica.

Ciao, silvio!
Il giorno 25/09/2003 alle ore 19:28 hai scritto:
 sb> Mi sa che il calcolo non è proprio esatto... ne in teoria
 sb> ne in pratica.
Ufff...
720x576 = 414.720 (ci siamo ?)
414.720 x 3 = 1.244.160 (mi segui ? RGB = 3 byte, in questo universo)
1.244.160 x 25 = 31.104.000 (ok ?)
31.104.000 / 1.048.576 = 29,663 (aggiungiamo l'audio e siamo sui 30 Mbyte al
secondo)
Se adesso cortesemente volessi spiegare la tua obiezione...
Bye

 Ciao
°°° Posted from X-Privat Free NNTP server - 
www.x-privat.org
 °°°

..................
In "questo universo" come dici tu, cioè nel mondo reale
4:2:2 nè in teoria nè in pratica campionano come dici tu.

Ciao, silvio!
Il giorno 26/09/2003 alle ore 13:30 hai scritto:
 sb> In "questo universo" come dici tu, cioè nel mondo reale
 sb> 4:2:2 nè in teoria nè in pratica campionano come dici tu.
Peccato che si sta parlando di RGB, come chiaramente indicato nel subject, e
fino a prova contraria se dici ad una scheda di acquisire in RGB 24 bit
quella ti tira fuori 3 byte per ogni pixel.
Quello che tu dici sarebbe vero se l'acquisizione fosse in YUV, ma visto che
non era quello richiesto, non c'entra niente.
Bye


Ripeto (e due !):
il mondo reale (si parlava di fare delle prove
sul pianeta Terra se non sbaglio) è quello del
4:2:2 e/o SDI.

Ciao, silvio!
Il giorno 26/09/2003 alle ore 13:47 hai scritto:
 sb> Ripeto (e due !):
 sb> il mondo reale (si parlava di fare delle prove
 sb> sul pianeta Terra se non sbaglio) è quello del
 sb> 4:2:2 e/o SDI.
Ribadisco, ancora una volta, che non era quello che e' era stato richiesto.
Se poi tu vuoi avere ragione a tutti i costi, va bene, per quello che me ne
importa, hai ragione.
Bye


sě, intendevo RGB, ossia non compresso, 4:4:4  senza l'ombra di una
compressione, cosě per provare naturalmente...
Chiedo ad entrambi che ne sapete piů di me: cosa significa SDI?
 E Component? (lo so che mi hai giŕ risposto una volta, ma hai
sopravvalutato le mie doti
:)))
Altyrove Guybrush mi spiega che SDI č 4:4:410bit, quindi si tratta di un
segnale non-compresso, giusto?
come l'RGB?
E se l'RGB č non compresso per nulla,  qual'č la differenza con gli altri
due?
Naturalmente si fa pour parler, nessuna velleitŕ concreta; solo per il
piacere di saperne di piů...
grazie

 Se adesso cortesemente volessi spiegare la tua obiezione...
3 byte e' lo spazio necessario per rappresentare un pixel RGB.
Purtroppo se dobbiamo trasferirlo in un sistema di comunicazione 
ne occorrono molti di piu'.
-- 
"difficilmente riusciremo ad arginare la diffusione dei virus finche' 
 esisteranno programmi come  u(z1...zn)=sel1(u z1...zn)=u" - Kleene

 piacere di saperne di più...
Perche' no? Puo' sempre servire per altri scopi...