Recenze  |  Aktuality  |  Články
Doporučení  |  Diskuze
Filmy a seriály, streamovací služby
Televize  |  Projektory
Audio a domácí kina
Multimediální centra  |  Ostatní
Svět hardware  |  Digimanie
Svět mobilně

Import PC video formátů do FinalCut studia 3

SB (260)|19.4.2011 12:36
Zdar,
Při importu videa, renderovaného na pc z programů Vegas, Premiere, AE, (ať už v *avi, *mov kontejnerech nebo sekvencích obrázků - TIFF, PNG, PSD) se barevný prostor vždy pokřiví - nezobrazuje se správně. U každého formátu se ale zobrazí špatně jinak. Jediný formát, který se zobrazuje korektně je *avi s kompresí DV. U ostatních dochází ke snížení kontrastu, ale ne konstantně. Někde je víc k černé nebo víc k bílé a aby to nebylo tak jednoduchý napravit, tak je podle testů na různých pruhách vidět, že je hnutá i gamma. Černá se většinou motá někde od 5 až 20 IRE a bílá většinou sedí na 90 nebo pod. Není to tedy převod 0 - 255 na 16 - 235 RGB. Takže nejde použít nějaký jednoduchý postup, jak situaci řešit systémově. Jediná možnost je to dotáhnout ručně Color correctorem a Gamma korekcí. Nevítě někdo jak tu situaci řešit jinak? Aby se jako v případě DV kodeku vyrobeného na PC zobrazovaly všechny formáty barevně a jasově správně? - Ve Final cutu?
ai (2993)|19.4.2011 15:43
Me vrtalo neco podobneho hlavou dost dlouho, protoze ale pouzivam jen frame server z Vegasu tak jsem to vyladil jen s timto, mozna, ze tam neco najdes. Nemuze totiz nastat situace, ze ten druhy soft , do ktereho to nacitas si to posouva, podle toho co to je za soubor a jaky ma barevny prostor, YUY2 nebo RGB ? ....

podivej se tu:
http://www.unival.realservers.info/index.php?page=frameserver#luma
SB (260)|19.4.2011 16:10
No, jak jsem psal výše, tak v tom problém není. Každý formát (krom zmíněného *avi s DV kompresí) se zobrazuje jinak - je jedno jestli vkládám RGB nebo YUV. Každý ztratí kontrast, ale každý jinak a hlavně podle těch měřáků to částečně "ohne" i gammu. Já to nejdříve řešil jako, že jde o interpretaci toho převodu RGB do YUV, ale není to tak - nebo alespoň ne konstatně. Frameserver používám taky a tam ten problém vzniká tím, že enkodéry používají projekt z vegasu (dostávají info) jako nekomprimované video. Takže tam dojde k převodu na 16-235 - v případě, že se komprimuje do YUV formátů typu MPEG nebo jiného z DCT kompresí. Pokud se renderuje do Uncompressed videa zůstane barevný prostor stejný. Ve Final cutu ale ke konstatnímu převodu 0 - 255 : 16 - 235 nedochází, tam je to každej pes jiná ves a to i pro sekvence obrázků. Jen ten DV kodek se zobrazuje správně. V manuálu jsem nic nenašel. Jinak uvnitř Final cut studia vše běhá mezi sebou správně.
SB (260)|19.4.2011 16:14
Udělal jsem x renderů barevných pruhů a gradientů do různých formátů, kompresí a sekvencí a výsledek byl pokaždý jinej.. takže moc nevim co s tím...
ai (2993)|20.4.2011 23:53
[quote=SB;340988]No, jak jsem psal výše, tak v tom problém není. Každý formát (krom zmíněného *avi s DV kompresí) se zobrazuje jinak - je jedno jestli vkládám RGB nebo YUV. Každý ztratí kontrast, ale každý jinak a hlavně podle těch měřáků to částečně "ohne" i gammu. Já to nejdříve řešil jako, že jde o interpretaci toho převodu RGB do YUV, ale není to tak - nebo alespoň ne konstatně. Frameserver používám taky a tam ten problém vzniká tím, že enkodéry používají projekt z vegasu (dostávají info) jako nekomprimované video. Takže tam dojde k převodu na 16-235 - v případě, že se komprimuje do YUV formátů typu MPEG nebo jiného z DCT kompresí. Pokud se renderuje do Uncompressed videa zůstane barevný prostor stejný. Ve Final cutu ale ke konstatnímu převodu 0 - 255 : 16 - 235 nedochází, tam je to každej pes jiná ves a to i pro sekvence obrázků. Jen ten DV kodek se zobrazuje správně. V manuálu jsem nic nenašel. Jinak uvnitř Final cut studia vše běhá mezi sebou správně.[/quote]
nerozumim tomu, rikas, ze RGB - YUV prevod nic nedela a pak, ze v pripade do YUV formatu dojde k 16-235 prevodu,

vim co delat z frame server RGB z Vegasu, aby to sedelo pri soucasnem prevodu do YV12, ovsem ted jsem zkusil o cems mluvil Vegas Frame Server -RGB-Virtual Dub -uncompressed RGB- Vegas a je to jak ma byt, tedy ten prevod do YV12 je pricinou 16-235, nebo Avisynth, nebo Vegas? Hazel jsem to na Vegas, ale v tomto pripade je bez viny?
ai (2993)|21.4.2011 04:26
Tak ted jsem nasel , ze RGB 0-255 na YUV 13-235 se v Avisynthu predpoklada, jako standard, tedy Vegas exportuje full range a Avisynth to prevodem na na YV12 zmeni, pokud se mu nerekne jinak (matrix="PC.709"). Tedy Vegas je z toho venku. Ono se jaksi predpoklada, ze u YUV je bila 235 (tedy Y=235,U a V=240 , jsem to ted nekde nasel, nevim jestli to je zpravne) a cerna =16, proto ty "normy".
SB (260)|21.4.2011 10:52
Pro lepší orientaci v problému posílám screeny z Final cutu - v názvu je použitá komprese a kontejner. Screeny "bars" a "gradient", ukazují použité testovací obrázky.
bars.png gradient.png uncompressed avi.png PNG mov.png DV avi.png DVCPRO mov.png Blackmagic 8 bit YUV uncompressed mov - gradient.png Blackmagic 8 bit YUV uncompressed mov.png TIFF mov.png MPEG4 mov.png
SB (260)|21.4.2011 10:56
Ad problém frameserveru, nevím přesně co jsem popsal nesrozumitelně - ten převod na 16 - 235, udělá enkoder, do kterýho renderuju jen v případě, že výstup mám být mpeg2. Pokud je výstup nekomrimovaný, pak zůstane prostor 0 - 255. Prostě se barvy z Vegasu přes frameserver a enkoder (TMPGEnc 4.0 XPress) nezmění. Možná ale nerozumim přesně, v čem vidíš ten zmatek - probíráme tady dvě věci najednou... :)
ai (2993)|21.4.2011 22:51
Jo promin, me uz to je jasnejsi, se to rysuje, moc ti to nepomaha ovsem, no jo, ale zalezi i na enkoderu, bych chtel rict, jestlize ten TMPGEnc to prevede na YUV (mpeg) a zmeni to na 16-235. Tak treba Procode ne. Ten drzi full range i z RGB na YUV. Kupodivu zase nedrzi full range z YUY2 na YV12, (YUY2 z Vegasu do mpeg2) je to celkem chaos. Ten TMPGEnc to dela zrejme podle normy, ale me se to moc nelibi tohle, nebyl bych spokojen. Dneska uz to je snad jedno na nase TV, nebo by tam meli mit volby. Avisynth to taky dela pry podle normy RGB na YUV z 0-255 na 16-235, a trvalo to "veky" nez mi to doslo, kde je problem. Dik za ty pripominky ohledne RGB na YUV.
SB (260)|22.4.2011 09:07
Vegas je z toho venku a frameserver zřejmě taky, je to věc konkrétního enkoderu. Každopádně to jak se to převádí ve Final cutu je něco jinýho, dle přiložených obrázků... Překvapuje mě jen, že FC je už poměrně populární program, který je určitou levnou alternativou k Avidu a určitě ho spousta lidí používá. Je zvláštní, že to zatím tady nikdo neřeší. Přeci jen pokud někdo ve FC pracuje, tak třeba občas má zdroje z PC, nebo ne?
Pave1 (4279)|24.4.2011 10:00
Pokud je alternativou k Avidu, tak ale většinou "postprodukčně naprosto oddělenou". Tedy kdo ví, že bude střihat na FCP, tak materiál tahá rovnou na něm. Pokud vlezeš na avid, tak se předpokládá, že na něm už taky zůstaneš.

Jinak AVID umí načíst ProRes (přes AMA) a zkonvertuje ho, takže tady předpokládám (ověřeně od výrobce) k žádným posunům úrovní nedochází. Netuším ale, jestli FCP umí načíst avidovské DNxHD, byť teď občas s FCP začínám občas laškovat .-) .
Když bude čas, tak to v příštích 14dnech otestuju.

Doplněno - vše výše napsané by se týkalo problému na straně FCP, ale ještě bych být tebou ověřil, zda se na tom nějak nepodílí VEGAS (tedy např. přes trial jiného programu bych zkusil stejný postup, zda to nebude jiné). To jen pro kontrolu, co vlastně problém způsobuje.
SB (260)|24.4.2011 19:37
Avidovské DNxHD umí naimportovat pokud má nainstalované avidovské kodeky. Tu alternativu myslím v možnostech, které FC studio 3 má.

V původní otázce jsem psal, že je výsledek stejný když se renderuje z Vegasu, Premiery a After Effects a platí to i pro TMPGEnc 4.0 XPress. Díky za zájem.. :) Pokud budou z testů nějaké výsledky budu rád. Je jasné, že výrobce počítá vždy se svou aplikací nebo balíkem jako samostané - soběstačné. Jen mě zaráží, že by to měl být problém mezi jednotlivými OS. V případě obrázkových sekvencí mě to vůbec nedává smysl.