Smart Decimate odstraňuje telecine kombinováním telecine polí a decimováním ve stejném čase, což se liší od tradičního přístupu uspořádávání telecine snímků a teprve poté následujícího odstraňování duplikátů. Poslední verze Smart Decimate můžete najít na http://kevin.atkinson.dhs.org/tel/.
LoadPlugin("...\avisynth_c.dll") LoadCPlugin("...\SmartDecimate.dll") AssumeTFF() # nebo AssumeBFF() SmartDecimate()Všimněte si, že druhý plugin je LoadCPlugin a ne LoadPlugin. (Za Load je umístěno písmeno C)
JE VELMI DŮLEŽITÉ, ABY BYLO POŘADÍ POLÍ SPRÁVNÉ.
Průvodce použitím
V tomto průvodci budu předpokládat, že váš materiál je 3:2 pulldown s
možným zamíchaným videem. Nicméně, SmartDecimate může zpracovat jakýkoli
pevný decimační poměr.
Pro použití tohoto filtru, musíte nejdříve určit správné pořadí polí. Pokud je pořadí polí nesprávné, můj filtr nebude správně pracovat. Určení pořadí polí:
AviSource(...) AssumeTFF() Bob()Nyní si prohlédněte video a hledejte zpětný pohyb. Pokud žádný nevidíte, tak by jste měli použít "assumetff()". Pokud nějaký vidíte, zkuste:
AviSource(...) AssumeBFF() Bob()A ještě jednou hledejte zpětný pohyb. Pokud tentokrát žádný nevidíte, tak by jste měli použít "assumebff()".
Teď nastal čas nastavit můj filtr:
LoadPlugin("...\avisynth_c.dll") LoadCPlugin("...\smartdecimate.dll") # všimněte si C v loadCplugin AviSource(...) AssumeTFF() # nebo AssumeBFF() jak je určeno výše SmartDecimate()Pokud se vám výsledek líbí, tak je to vše co je potřeba. Pokud ne čtete dále.
Pokud je váš materiál animovaný s hodně opakovanými snímky, tak by jste měli zkusit:
SmartDecimate(tel=0.60)To by se mělo vyhnout jakémukoli bobbingu ve dlouhých sekvencích bez pohybu.
Hodnota "tel" řídí jak agresivní je filtr při uspořádání polí. Výchozí hodnotou je 0.50.
Pokud máte smíchané video s velkým množstvím skutečného videa, tak by jste mohli chtít snížit "tel" až na 0.25. To riskuje bobbing některých progresivních snímků, ale nemělo by spojovat (weave) skutečné video snímky, což může odstranit artefakty roztřepení.
Pokud máte video, které je čisté 3:2 pulldown s velmi malým podílem opravdových video snímků, pak by jste mohli zkusit zvětšit "tel" až na 0.75. To způsobí, že SmartDecimate bude opravdu agresivní, při uspořádání progresivních polí. Nicméně, asi přestane odstraňovat vážné artefakty roztřepení za ním, pokud je nějaké čisté video ve vašem klipu.
Pokud máte hodně zašumělé video, pak by jste mohli potřebovat zvýšit parametr noise jako zde:
SmartDecimate(noise=0.80)Výchozí hodnota je 0.50. Nechte ho na výchozí pokud váš klip není hodně zašumělý. Vyšší hodnoty noise za sebou často zanechávají více artefaktů roztřepení pro čisté video snímky.
Pokud máte opravdu čistý klip a všimli jste si některých artefaktů roztřepení v čistých video snímcích, pak by jste mohli chtít snížit parametr noise. Ale buďte opatrní; pokud je příliš nízko, SmartDecimate nebude schopen uspořádat progresivní pole a bude je tedy bobovat (duplikovat).
Nakonec, pokud máte hybridní video (mix 3:2 pulldown a skutečného videa), měli by jste zvážit nahrazení dumb (hloupý) bob něčím jako DgBob nebo SmoothDeinterlace. Aby jste to udělali, použijte možnost "bob". Například:
SmartDecimate(bob=DgBob(...))To výrazně zlepší kvalitu čistých video snímků. Všimněte si, že bob zdroj ovlivní jen jak jsou bobbované snímky rendrovány. Není to použito pro porovnání polí. Ani to není využito jinou částí SmartDecimate.
Použití je:
SmartDecimate
([numr, denm], možnosti)
Následující možnosti mohou být použity pro vyladění SmartDecimate
:
bob
alternativní zdroj snímků s odstraněným prokládáním metodou bob. Výchozí je "Bob()"
což je v AviSynthu vestavěný dumb (hloupý) bob filtr. Pro lepší výsledky
použijte smart (chytrý) bob jako DgBob nebo SmoothDeinterlace. Bobbovaný zdroj
je použit kdykoli SmartDecimate určí, že pole není částí
progresivního snímku.
weave
alternativní zdroj složených (weaved) snímků. Výchozí je "DoubleWeave()".
tel
číslo mezi 0 a 1, které ovládá jak agresivní je filtr
při uspořádání polí. 0.50 (výchozí) pracuje dobře s většinou
klipů. Čím vyšší hodnota tím více se riskuje zanechání
artefaktů roztřepení ve skutečně prokládaném materiálu. Čím nižší hodnota, tím víc
se riskuje bobbing (nebo v extrémním případě přeskočení nebo
duplikování) Telecine snímků.
V současnosti tel
přepíná různé vnitřní možnosti podle toho co je nastaveno.
V současnosti jsou přepínání mezi: 0.45, 0.55, 0.65
a 0.72.
noise
Parametr šumu. Výchozí hodnota, 0.50, by měla pracovat ve většině
případů.
t_max
Alternativní metoda nastavení faktoru noise. Aby jste ho mohli použít,
musíte pochopit jak můj filtr pracuje.
cpu
Vynutí CPU na určitý typ. Normálně je to autodetekováno.
Aby jste se podívali jestli je to detekováno správně zapněte logování. Prní řádek
výstupu zobrazí typ CPU. Aktuální platné hodnoty
jsou: 0 - Generic, 2 - Integer SSE, 3 - SSE, 4 - SSE2.
unaligned
Umožní číst nezarovnaná data. Normálně SmartDecimate
může ignorovat několik
pixelů na začátku nebo na konci každého řádku, takže čte jen ty pěkně zarovnané.
Nastavení této hodnoty na true tomu zabrání.
Následující možnosti mohou být použity pro ovládání tištění užitečných informací:
log_level
Výmluvnost tištěných informací. Výchozí je 2.
log_file
Pokud je nastaven, celý výstup bude připojen k zadanému jménu souboru.
console
Při nastavení na true, vyskočí okno konsole window a celý výstup bude
posílán do ní.
debug_print
Pokud je nastaven, tak celý výstup bude vytištěn přes systémovou výzvu OutputDebugString.
Tento výstup můžete zobrazit pomocí utility jako DebugView.
Význam vytištěných informací je následující:
Následující možnosti mohou být použity pro vyladění vnitřních parametrů. Aby jste pochopili co dělají, musíte se podívat na zdrojový kód. Mohou být změny mezi vydáními.
Jiné telecide filtry obecně odstraňují telecine ve dvou krocích zpracování. Nejprve jsou telecine pole uspořádány, ale frekvence snímků není změněna, pak jsou duplikované snímky odstraněny. SmartDecimate takto nepracuje. SmartDecimate namísto toho, kombinuje telecine pole a decimuje frekvenci snímků v jednom okamžiku.
První věc, kterou SmartDecimate dělá je, že použije "SeparateFields()", který rozdělí video na samostatná pole, což také zdvojuje frekvenci snímků. Tedy pole číslo 9 je ve skutečnosti spodní pole snímku 4 (předpokládám, že video je TFF) před jeho rozdělením na pole. Pro jednoduchost se budu odkazovat vždy na pole ze zdrojového videa tímto způsobem.
SmartDecimate pak vybírá pole v pravidelné šabloně a snaží se vyhnout vybírání duplikovaných polí. Přesněji, ať je N číslem umístění snímku a R bude poměr, který pro 3:2 pulldown bude 24/60 = 2/5, pak SmartDecimate volí mezi polem floor(N/R) a floor(N/R) + 1. Například, pro číslo umístění snímku 5, použití typického 3:2 pulldown, SmartDecimate volí mezi poli 12 a 13. Který zvolí je docela komplikované a něco co sem už nedostanu.
Poté kdy je zdrojové pole vybráno, musí rozhodnout jak ho rendrovat
SmartDecimate volí mezi: 1) jeho uspřádáním s předchozím
polem, 2) jeho uspřádáním s následujícím polem, nebo 3) jeho bob deinterlace.
Který zvolí, je založeno na tom jak podobné je pole k
předchozímu nebo následujícímu. Pokud je pole stejné jako předchozí nebo
následující pole, uspořádá ho s tímto polem složením těchto
dvou polí dohromady. Pokud nemůže najít pole pro uspořádání, provede odstranění prokládání
metodou bob v aktuálním poli. SmartDecimate ve skutečnosti nedělá konečné
rendrování. Místo toho používá jiný AviSynth filtr, který to udělá.
V případě skládání (weaving) použije DoubleWeave(), a v
případě bobbingu použije Bob() nebo smart (chytrý) bob filtr pokud
je nějaký k dispozici a zadaný.
Vyladění T_Max
Aby odkryl, která pole se liší jedno od druhého a
která jsou stejná, SmartDecimate hledá špičky v řetězci rozdílů.
To je dáno třemi hodnotami reprezentujícími rozdíl mezi
čtyřmi po sobě jdoucími poli A B C D, pokud BC (t.j. rozdíl mezi B
a C) > AB a BC > CD a AB a CD mají podobné hodnoty, pak
pole A a B by mohly být stejné, pole B a C by mohly
být rozdílné, a pole C a D by mohly být stejné.
Nicméně, tato metoda není dokonalá a může občas klasifikovat vysoce pohyblivé scény, kdy podobné hodnoty rozdílů mezi snímky (to je AB a CD jsou podobné), že by mohli být stejné. Takže pro řízení tohoto, SmartDecimate jednoduše předpokládá, že všechna pole s rozdílem větším než pevná prahová hodnota nemohou být stejná. Naneštěstí neexistuje optimální hodnota pro tuto prahovou hodnotu, takže je nastavena na rozumnou hodnotu, která by měla pracovat dobře ve většině klipů, které nejsou extrémně zašumělé. Nicméně, tato hodnota obecně nechá některá rozdílná pole nedotčená, což povede k artefaktům roztřepení. Aby jste se tomu vyhnuli, měla by být prahová hodnota "t_max" nastavena co možná nejníže.
Pro objevení nejlepší hodnoty "t_max" je pro konkrétní klip budete potřebovat znát jaké jsou rozdíly mezi snímky. Nejsnadnější způsob jak to udělat je nastavit možnost "log_file" (s log level nastavenou na 2 nebo vyšší) a spustit SmartDecimate na značné části vašeho klipu. Jakmile je to uděláno, měli by jste v log souboru vidět něco podobného tomuto:
... Diff 827: 0 6.11586e-008 FRAME 331 = [828,827] Diff 828: 2 8.21554e-005 Diff 829: 0 3.69098e-008 Diff 830: 0 3.27322e-008 FRAME 332 = [830,831] Diff 831: 2 0.000124936 Diff 832: 0 6.48069e-008 FRAME 333 = [832,833] Diff 833: 2 0.000102379 Diff 834: 0 3.54472e-008 ...Řádky, které vás zajímají jsou ty které začínají "Diff ...". První číslo za Diff je zdrojové číslo pole. Druhé číslo je klasifikace rozdílu s 0 znamenající shodnost, 1 podobnost, a 2 rozdílnost. Konečné číslo je skutečný rozdíl. To co vás v něm zajímá je rozdíl snímků klasifikovaných jako shodné. Chcete nastavit t_max mírně nad maximální hodnotu všech rozdílů klasifikovaných jako stejné. Pro tento klip by 7.0e-8 měla být dobrou hodnotou. Ale protože jsem se podíval jen na malou část klipu může být potřeba vyšší protože rozdíly se mohou hodně lišit. Nejlepší je podívat se na hodnotu pro několik různých oblastí klipu, aby jste dostali bezpečnou hodnotu. Předpokládejme, že 7.0e-8 je dobrá hodnota a mohu ji použít následovně:
SmartDecimate(t_max=0.000000070)Napsal jsem 0.000000070 místo 7.0e-8 protože AviSynth jak se zdá nepodporuje vědecký zápis. Aby jste si byli jisti, že jste převedli číslo správně, nastavte log level na 3 nebo vyšší a hledejte řádek jako:
t1_max = 7.00000e-008 t2_max = 2.10000e-007 max_last_set = 13Hodnota, která vás zajímá je t1_max což je 7e-8. Proto jsem převedl číslo správně. Další hodnoty jsou pro jiné vnitřní prahové hodnoty.
Jakmile si myslíte, že jste nalezli dobrou hodnotu pro t_max, znovu projeďte váš klip přes SmartDecimate s log level nastavenou na 3 nebo vyšší, aby jste se přesvědčili, že jste ji nenastavili příliš nízko. Pokud ji nastavíte příliš nízko velký počet snímků bude bobbován a vy uvidíte zprávy jako je tato:
2001: T1 Maxed Out at 2.00000e-008Tyto zprávy jsou normálně pro skutečné video části vašeho klipu, ale neměli by se ukázat v telecine částech vašeho klipu. Pokud je vidíte, tak to znamená, že t_max je příliš malý a má být zvětšen. Přesná hodnota může být objevena prohlédnutím rozdílů okolních snímků. Například:
... Diff 1999: 2 3.08506e-008 Diff 2000: 1 4.03734e-008 Diff 2001: 2 8.89810e-006 Diff 2002: 1 2.93221e-008 ...ukazuje, že t_max by měl být alespoň 4.04e-8, ale 4.5e-8 by byla bezpečnější hodnota.
Nakonec si prosím všimněte, že jak "t_max" tak "noise" ovládají stejný vnitřní parametr, kterým je "t1_max". Dělají to jen jiným způsobem. "t_max" ho nastavuje přímo, zatímco "noise" ho nastavuje nepřímo, podle exponenciální formule. Ve SmartDecimate 0.21 tato formule je:
t1_max = exp(17.65*noise - 20.71)Ale přesné parametry se mohou v různých vydáních měnit. Myšlenka je taková, že hodnota šumu 0.50 (výchozí) by měla pracovat dobře s většinu klipů, zatímco 0.80 může být použito pro opravdu zašumělé klipy, atd.
Většina deinterlacerů (odstraňovačů prokládání) při práci vždy volí horní pole (nebo snad spodní) jako dominantní pole a výběrově hází informaci do druhého pole a pak je interpoluje nebo smíchává (blending). Pro normální 30 fps (nebo 25 fps pal) je to správně. Nicméně pro výstup ze SmartDecimate to není správné, protože dominantní pole není vždy stejné. To závisí na tom které pole SmartDecimate původně vybíral ze zdrojového videa, a může to být buď horní nebo spodní pole. Proto tradi¨ční deinterlacer může vzít nesprávné pole. Nemusí to být dokonce ani pozorovatelné, ale měli by jste si toho být vědomi.
Autoři filtrů pro odstraňování prokládání mohou opravit tento problém za cenu
dohlížení na paritu snímku. SmartDecimate vždy zahlásí
paritu původního vybraného pole jako paritu finálního
rendrovaného snímku. Pokud je parity true, pak by mělo být vybráno
horní pole. Pokud je to false, bude vybráno spodní pole. Také bude ochotný
předávat údaje hints do deinterlaceru pro indikaci která pole jsou bobbována
pokud mi někdo řekne jak.
Zacházení s nechtěným pohybem
Použitím možnosti weave můžete použít různé klipy pro vstup
a výstup. To je užitečné pro práci s titulky nebo jiným pohybem,
který nechcete uvažovat při uspořádávání snímků. Například
můžete zkusit oříznout titulky.
b = Bob() w = DoubleWeave() CropBottom(64) SmartDecimate(bob = b, weave = w)Pak nebude výstupní video oříznuté, ale posledních 64 řádků nebude vidět filtr SmartDecimate. Pokud použijte tuto metodu, pak bob zdroj musí být také zadán. Pokud nezadáte bob zdroj, tak se pokusí použít vstupní klip pro "Bob()". Ale výsledný klip nebude mít stejné rozměry jako složený (weave) zdroj.
Pokud je vaše cílová frekvence 24fps, pak je volba založena na osobní chuti, protože jak Smart Decimate tak Decomb zpracují tuto situaci zcela odlišně, a s velmi rozdílnými výsledky.
Smart Decimate zpracuje video vybíráním snímků z bobbovaného zdroje (dvojnásobná frekvence snímků) v 3:2 šabloně. To je, jde od 60 -> 24fps. To vede ke slušně hladkému pohybu bez nutnosti rozmazávání snímků dohromady. Nicméně, video je stále mírně trhavé. Podle mých zkušeností je mírné trhání obecně nepozorovatelné, kromě případu kdy probíhá text. Například, při decimaci probíhajících titulků v této podobě jsou výsledky hrozné. Protože jsou použity bobbované snímky, budete mít také některé artefakty bobbingu. Výsledky nebudou moc dobré kromě případu, kdy použijete smart bob.
Decomb, na druhou stranu zkusí decimovat skutečné video tak, že jde od zdroje s odstraněným prokládáním s 30 fps k 24 fps. Dělá to jedním ze dvou způsobů. První věc, kterou může udělat je prosté vypuštění jednoho z každých 5 snímků. Tento přístup povede k extrémně trhavým výsledkům. Druhá věc, kterou může udělat je smíchat snímky dohromady. Tento přístup povede k hladšímu videu než u přístupu Smart Decimate, ale ne bez nežádoucích artefaktů. Pohybové oblasti obrazu budou obecně rozmazané. U velkého pohybu se mohou objevit duplikované obrázky, které mohou ztěžovat oku sledování pohybu. Rozmazání snímků dohromady také negativně ovlivní kompresi protože dělá sledování pohybu obtížnější.
Decomb na druhou stranu vidí prokládané video a progresivní 30 fps jako stejnou věc a bude tak schopen rozmazat snímky dohromady pro hladší pohyb. Pokud je váš klip hlavně video/30 fps progresivní s nějakým 3:2 pulldown, Decomb může také udržet 30 fps a smíchat pulldown materiál pro lepší výsledky.
Jiné věci pro vyzkoušení Smart Decimate
Zde jsou některé další věci, které by jste mohli vyzkoušet se Smart Decimate, pokud je nemůžete zvládnout s použitím tradičních telecine filtrů Decomb.
SmartDecimate(1,1, tel=0.25, bob=DgBob(...))což povede k lepším výsledkům než použití DgBob (nebo většina jiných smart bob filtrů) samotný, protože telecine snímky jsou duplikovány spíše než aby v nich bylo provedeno odstranění prokládání metodou bob. To by mohlo udělat velký rozdíl u animovaných filmů.
SmartDecimate upozorní na jakékoli ignorované pixely pokud je logging level
nastavena na level 0 nebo vyšší.
Kompilování
Pro kompilování SmartDecimate budete potřebovat nainstalovat Gcc a Nasm, a
možná GNU Make. Já jsem použil MinGW
(2.0.0-3) s MSYS 1.09, Gcc 3.3.1, a Nasm 0.98.37. Kromě Nasm,
lze všechny požadované utility najít na MinGW Download
page. Jiné konfigurace by měli pracovat, ale můžete potřebovat editovat
Makefile. Jakmile jsou všechny potřebné nástroje nainstalovány a na cestě,
jednoduše napište:
makez MSYS shell a to je vše co by mělo být vyžadováno.
0.23 (Sep 16, 2003)
0.22 (Sep 12, 2003)
0.21 (Sep 7, 2003)
0.20 (Aug 29, 2003)
0.12 (Aug 22, 2003)
0.11 (Aug 18, 2003)
0.10 (Aug 16, 2003)
$English Date: 2004/08/17 20:31:19 $
Český překlad:12.5.2009