OCR filmových titulků (diskuse)

[Jendа]

Zkusil bych obraz průměrovat po celou dobu trvání daného titulku (což už nepůjde shell skriptem, chtělo by to napsat v nějakém „plnohodnotném“ jazyce) -- myšlenka je, že všechno ostatní se hýbe a rozmaže se to, a titulky z toho hezky vystoupí.

[Jendа]

A zjištění, že je další titulek, ideálně nějakou podobnostní metrikou (přímo toho obrazu?), která nebude reagovat na drobné změny (tečka/čárka).

[jejda]

Ono když je ten film puštěný, tak ta změna není vidět protože ty časy jsou natvrdo nastavené 000-999 milisekund, tak se žádné rušivé probliknutí nekoná. Ty titulky akorát vypadají hnusně v textovém editoru třeba.

[Bherzet]

Myslíš to nějak tak, že bys bral snímek po snímku, porovnával je mezi sebou pixel po pixelu a ty pixely (resp. jejich souřadnice), kde zaznamenáš změnu, bys zahazoval? Je to sice zajímavá myšlenka, ale na statickém pozadí by to nefungovalo vůbec a u scén, kde je třeba spodní část obrazovky hodně tmavá, taky moc ne. Asi by to šlo zkombinovat s tím prostým filtrováním podle barvy, ale stojí to za ty zvýšené výpočetní nároky?

[Aleš Kapica]

Příloha:

• title_yellow.png (12288 bytů)

Vy jste divní. Já bych šel na to úplně jinak a použil bych nástroje z netpbm

1, Především bych přes ffmpeg vyjel všechny snímky z filmu do png (pnm zabírá zbytečně moc místa)

ffmpeg -i video.mp4 -r 1/1 $filename%03d.png

Když jsem to zkoušel, tak minutovou sekvenci vyblil cca za 6 sekund

2, Pak bych vybral jeden reprezentativní keyframe, ze kterého bych pomocí výběru podle barev vybral optimální selekci, tak aby zabrala pokud možno všechny barvy titulku. A z té bych pak udělal mapu barev:

pngtopnm title_yellow.pnm | pnmcolormap all > mapa.pnm

Redukcí barev se výrazně zjednoduší a zrychlí následné zpracování.

3, No a pak bych s využitím této mapy bych projel ve smyčce všechny snímky:

for i in (ls *.png) ; do pngtopnm $i | pnmremap -map=mapa.pnm -missingcolor=white > ${i/png/pnm} ; done

Ještě víc by se to dalo urychlit tím, že bych před ten pnmremap předřadil pnmcut, aby se zpracovávala jen ta část obrazu, kde se vyskytují titulky. Čímž by ještě víc zredukoval objem dat s nimiž by se pak měl tesseract zabývat.

A k jejich zpracování bych si napsal jednoduchý skriptík, který by bral jeden po druhém a přes pnmpsnr, porovnál jestli nedošlo ke změně. Pokud jo, tak pokud by šlo o začátek titulku, tak by zavolal tesseract, a když by to byl konec, tak by zapsal výsledek s číslem počátečního a koncového keyframe do souboru s titulky.

[jejda]

U toto exportu všech obrázků na jednu hromadu je trochu problém, jak potom ten obrázek přiřadit k času. Nejsu si jistý jestli ffmpeg vůbec umí vložit timestamp do názvu souboru. Prý se to dá nějak zpětně dopočítat nevypadá to ale moc intuitivně.

[Aleš Kapica]

Zmíněno níže. Nepoužívá se jen časování přes časová razítka, ale také přes klíčové snímky. Má to ale jeden háček - musí to být titulky ke konkrétnímu videu. Nicméně pokud ho máš k dispozici, nebo víš jakou měl snímkovovou frekvenci, není problém s konverzí.

[Bherzet]

Přílohy:

• test01.png (11476 bytů)
• test02.png (329236 bytů)
• test04.png (39875 bytů)
• test07.png (1017073 bytů)

Zkoušel jsem ten Jendův algoritmus, resp. to, jak jsem ho pochopil, aplikovat na krátký sample, a nefunguje to. Naivní implementace (p1 ≠ p2, tedy nulová tolerance), dle očekávání nefunguje vůbec (test01.png je výsledek po průchodu přes všechny snímky, test02.png pouze přes dva), trochu chytřejší implementace (d(p1, p2) > t) není o nic lepší (test04.png je výsledek po průchodu přes všechny snímky při t=10). Zvyšování thresholdu nepomáhá. Co je zvláštní, tak že i pokud threshold nastavím tak absurdně vysoko (dejme tomu na 300), že téměř všechny pixely ve scéně zůstanou netknuty, titulky to stejně částečně usekne (viz test07.png). Napadá mě jediné logické vysvětlení, že tam dochází k nějakému nepatrnému posunu, což je věc, kterou jsem fakt nepředpokládal. Čekal bych, že titulek bude pozicovaný vždy stejně.

No ale zkoušel jsem ty framy projet od oka a žádného viditelného posunu jsem si nevšiml, tak fakt nevím. Protože pokud tam k tomu posunu nedochází, tak by to aspoň o trochu lepší výsledky produkovat mělo, ne? Pak by bylo na čase přemýšlet, jak to optimalizovat (zmenšení viewportu na relevantní část, nějaké půlení intervalu, aby to nebralo úplně všechny snímky, …). Pokud je to ale opravdu tím skákáním a neudělal jsem teď v rychlosti někde jen nějakou stupidní chybu, bylo by nutné místo jednotlivých pixelů sledovat nějaké matice sousedních pixelů atd. Natrénovat nějaký model přímo na čtení titulků by v dnešní době asi byla rozumnější cesta.

[Bherzet]

Záhada vyřešena, je to opravdu způsobené poskakováním titulků – při přecházení mezi snímky v menším okně je to dobře patrné. Aplikace např. na prvních 50 snímků dává podstatně lepší výsledky, kde dochází k postupnému odmazávání scény a nikoliv titulků. Jakmile se ale ke slovu dostane třeba snímek č. 108, cca třetinu titulků pošle do hrobu, protože on je má pozicované trochu jinak.

Takže řešení by bylo buď neporovnávat jednotlivé snímky přímo pixel po pixelu, ale mít nějakou toleranci i tímto směrem, nebo z nich zkoušet počítat nějaký průměr, o kterém Jenda vlastně mluvil původně, ale to si asi neumím úplně představit, jak by fungovalo (protože pokud titulky skáčou, budou rozmazané, resp. dělat duchy). Další věc je, že perioda, po kterou je titulek zobrazený, potažmo změna ve scenérii, která během ní proběhne, nemusí být ani zdaleka dostatečně velká na to, aby zmizely opravdu všechny ostatní pixely a nakonec to stejně skončí implementací algoritmu „plechovky“, vybíráním souvislých bloků pixelů o cca barvě titulků… a takto složitě vyprodukovaný výsledek bude opět trpět stejnými problémy jako popisuje OP v blogu (bude to chytat i jiné nápisy o stejné/podobné barvě atp). Čili tudy cesta nevede.

Dobrou noc.

[Aleš Kapica]

No a co to takhle zkusit postupem který jsem popsal?

Kdybych měl k dispozici vzorek takového videa a nejenom jeden snímek, tak už by byl ten skript dávno na světě. Já totiž ve své sbírce žádný takový film nemám. Vždy jsem se snažil sehnat originální verzi, češtinu mít jako další stopu a titulky mimo soubor, aby je bylo možné editovat a případně překládat.

[Bherzet]

Tvůj postup očividně funguje, OPův taky. Já to nepotřebuji, tohle jsem zkoušel jen ze zvědavosti, protože mi to přišlo jako zajímavý nápad, ale byl jsem trochu skeptický k tomu, že bude fungovat. Ale nevím, jak to Jenda myslel, a jestli jsem ho pochopil úplně správně (spíš ne, přinejmenším s tím průměrováním vůbec netuším, co myslel).

[Aleš Kapica]

Kdybych měl něco, na čem bych to mohl testovat, tak bych ten skript napsal. Ale bohužel nemám.

[Aleš Kapica]

U bílých titulek bych pochopitelně použil pozadí černé a pak to inverzně přemapoval.

[panejo]

Uz to tady zaznelo, pokud by tazatel nahral ten klip nekam na ulozto, uz ma titulky i s ocr programem. Filozofovat naprazdno se o tom samozrejme da taky :)

V pripade zajmu o test s klicovyma snimkama, ja si kdysi napsal toto (vynecha 'hodinu', kdyz tak doplnte // prip misto python asi staci echo "scale=20; x*y+z" | bc -l):

# all frames::

# mkdir all_frames_orig
# cd all_frames_orig
# ffmpeg -i ../Trailer_2020.orig.mp4 -vsync 0 -r 25 -f image2 %04.png
# cd ..

## tohle ale muze trvat dooost dlouho (4000 asi 4 hodiny):
## vysekne jen vybrane snimky
for f in $(seq 0 4752); do
fn=$(printf "%04d.png" $f)
ffmpeg -i ../Trailer_2020.orig.mp4  -vf "select=eq(n\,$f)" -vframes 1 $fn
done


#######
mkdir key_frames_orig_hms
cd key_frames_orig_hms
# ffprobe -select_streams v -show_frames -show_entries frame=pict_type -of csv ../Trailer_2020.orig.mp4
ffprobe -select_streams v -show_frames -of csv ../Trailer_2020.orig.mp4 > trailer_ffprobe.out

cat trailer_ffprobe.out | awk -F',' '{print $5,$6,$19}' > trailer_ffprobe_types.out

grep 'I' trailer_ffprobe_types.out > trailer_ffprobe_types_keys.out

## vyzaduje all_frames nebo vysekavat po jednom (viz vyse)
cat trailer_ffprobe_types_keys.out | while read a b c; do
zpframe=$(printf '%04d' $a); secs=$(printf '%.2f' $b);
ms=$(python -c"print('{}m{:02.2f}s'.format(int($b//60),$b % 60))")
convert ../all_frames_orig/$zpframe.png -quality 80 ./${zpframe}_${secs}s_${ms}.jpg;
done

[Josef Kufner]

Teoreticky bys mohl jít po klíčových snímcích, neboť titulek by mohl být dost velká změna, aby takový snímek byl vždy na začátku titulku.

Jinak pokud bys použil rozumný programovací jazyk a nespouštěl ffmpeg + cca 10 dalších procesů pořád dokola, tak by to mohlo být řádově rychlejší. Neměl by být problém projet všechny políčka videa rychleji než je doba přehrávání, při tom nějakým průměrováním nadetekovat změny v titulcích a pak vyexportovat jeden snímek na titulek. Tipnul bych si, že pokud si vyneseš graf podobnosti mezi snímky, tak změny titulků budou vidět jako špičky.

[jejda]

Podle toho co se píše v manuálu ffmpeg při tom seekování klíčové snímky používá. Jsem to pochopil tak, že se mu zadá přesný čas, ffmpeg doskáče na nejbližší keyframe a přesnou pozici potom nějak dopočítá. Samotné klíčové snímky mají rozestup klidně několik sekund. Pro seekování jenom podle keyframes to má volbu -noaccurate_seek

Když to čte jenom každý pětadvacátý snímek tak to zas až tak zoufale pomalé není. Nejvíc na tom zdržuje to OCR které se nakonec zavolat stějně musí. Když by se ffmpeg překompiloval s volbou --enable-libtesseract tak se tím zpřístupní filtr ocr. Ale to moc nechápu jak to funguje.

[Josef Kufner]

Ano, používá je. Ono to ani jinak nejde.

Co jsem však chtěl říct je, že když vemeš ffmpeg knihovnu a naprogramuješ si to s ní, tak nebudeš na každý snímek číst hlavičku souboru, obtížně seekovat do prostřed souboru a radovat se, že zvládneš načíst každý 25. snímek, když bys mohl zpracovat všechny snímky a ještě několikanásobně rychleji.

[JiK]

co takhle na to natrenovat nejakou neuronovou sit?

[nadtržítko]

Dafuq? Pred 20ti lety kdyz jsme ripovali dvd do divx tak na to byl softik co to OCRkovalo a rovnou prehnalo pres slovnik MS Wordu. Jo aha, v linuxu? Tak to muzete jit do <>e i po 20ti letech :o)

[xsubway]

Chodí taky zbloudilý uživatelé Linuxu na Win fóra a dělají tam dlouhý nos jako malý dečka? :)

[nadtržítko]

Samozrejme, to parti k linuxovimu fanatismu ;o)

[nadtržítko]

Zadny linuxovy fanatismus neexistuje. Linuxaci jsou proste dusevne nemocni lide zijici v bludu. Kdyz jim to nekdo vytkne tak jenom bekotaji a strkaji hlavu do pisku. Nechapu co je na tom tezkyho normalne se vztycenou hlavou to priznat a zaspivat hymnu linuxaku: Radujme se veselme se, hovno mame, podelme se.

[Aleš Kapica]

Pořád lepší než si ji strkat do prdele jako ty.

[=^..^= AmigaPower®]

To je nějaký dítě vole, ani Win BFU nemůže bejt takhle blbý...

[billgates]

Ako, uprimne, nevidel som este jedinu diskusiu o nejakom Windows bugu na lubovolnom fore, kde by nevyrukoval niekto s linuxom.

[AfD 💙]

jo :D :D ;D ;D

a furt jim tam řikám jak je jako ten linux supr jak všecko funguje aže takovej a takovej problémek by v linuxu vubec nebyl možnej i když vim žeto jako neni pravda a každou chvilku se musí v linuxu něco vopravovat :O :D :D ;D

[mimi.vx]

Az na to ze na DVD jsou titulky ve vlastnich stopach ...

 

coz tady autor resi uplne jiny  problem o oplne jine komplexite ... HardCoded SUBS :D , ale u uzivatele windows clovek neceka ze pochopi psany text a nebo vi neco o technologii na pozadi

[nadtržítko]

To v jake stope jsou je irelevantni protoze DVD ma titulky jako obrazky a tedy OCR se nevyhnes. Ze se autor musel srat s cernenim obrazu je jen proto, ze je pirat a nema orginalni disk.

[mimi.vx]

ne, je to celkem relevantni .. chtel bych videt tn X let stary program na widle co to udela na kliknuiti ..

 

to jestli je autor pirat nebo ne je irelevatni, i ten kdo grabuje orig dvd a OCRkem protahuje titulky je pirat ..

[Josef Kufner]

DVD titulky jsou průhledné video, které přehrávač plácne přes film. Takže OCR to má velmi snadné, neboť dostane velmi čistá data. Pokud je OCR natrénované na konkrétní font, tak by úspěšnost měla být velmi slušná. A ano, ripovací programy mají podporu OCR v sobě už nějakou tu dekádu.

[SubRip]

https://en.wikipedia.org/wiki/SubRip Ten software má přes 17 let a pořád se udržuje. Když vám vadí použití pokrokovějšího operačního systému než je ten váš, tak je možné to pustit přes Wine.

[Aleš Kapica]

Ty matelo, než podstupovat ten oser s tím tvým "pokrokovějším systémem", to bych ty titulky raději přeťukal na klávesnici.

[Mumin]

Ten SubRip konec konců zřejmě používá neuronku, protože u nejasných znaků se ptá co to je, pár krát mu pomůžeš a pak se to už naučí. Zřejmě je natrénovaný na anglosaské jazyky protože se ptal povětšinou na znaky s diakritikou.

[Aleš Kapica]

Ale houbeles. Učení uměly OCR aplikace už před dvaceti lety. Kdyby používal "neuronku", tak se neptá.

Zaobírám se OCR už docela dlouho a úspěšnost výsledku záleží víc na kvalitě zdroje, než na nějakém učení. Proto je hovadina aplikovat OCR na neupravený filmový snímek, kde titulek tvoří jen malou malou plochu. Nejefektivnější je ten snímek ořezat(titulky se zpravidla vyskytují v dolní třetině snímku, pak mimo barev titulků vše ostatní remapovat na jednu barvu pozadí – je-li plocha pozadí bílá a titulky jakákoliv barevná směs, je výsledek rozpoznání lepší, než pokud je pozadí černé – a teprve pak na to poštvat nějaký OCR engine pochopitelně s doporučením jazyka rozpoznávaného textu. Pak totiž použije i další finty, které zvyšují úspěšnost až na 99%.

[Bherzet]

Kdyby používal "neuronku", tak se neptá.

Ptá, protože potřebuje trénovací data.

[Josef Kufner]

Pokud by se použila neuronka, tak by se jí dalo předhodit neupravené video a natrénovat ji, ať si ho upraví sama. Mělo by stačit jí udělat trochu hlubší, aby vstupní vrstvy měly dost prostoru na zpracování obrazu a ještě zbylo na zpracování textu.

Trénovací data nebude nijak obtížné obstarat, neboť videí s titulky se válí všude hromada a stačí titulky zapéct do obrazu. V ten okamžik máš jak vstup, tak 100% správný výstup a může se trénovat.

[Aleš Kapica]

Přesně tak. S tím ale ať si hraje někdo jiný. Mně vyhovuje OCR software co není úzce specializovaný a jak už jsem napsal tesseract funguje, pokud se mu dodá slušná předloha dostatečně. A s mizernýma předlohama by měl problém i člověk na trávě.

[AfD 💙]

co tohleto hele :O :O

[jejda]

Příloha:

• ocrsub2.sh (1921 bytů)

No to je vlastně původní důvod, proč toto celé vzniklo. Protože se mi ten videocr nepodařilo rozhýbat. Taky autor toho videocr píše, že dvacetisekundové video to čte tři minuty. To se mi zdá hodně pomalé. Teď zrovna překopávám tady ten bash skript tak, že čte za sekundu ne jeden obrázek ale dva a zjišťuju že to stačí. Žádné titulky netrvají míň jak 500ms. V té původní verzi co je navrchu v blogu se mi občas krátký titulek ztratil. Hodně se tím zvýšila přesnost časování. Bohužel s tím ale narostl počet duplikátů (asi v tom mám bug) a taky to celé trvá dvakrát dýl. Přibližně je to stejně rychlé jak přehrávání. Dám to do přílohy. Přijde mi že je to o maličko víc použitelné jak ta původní verze.

Našel jsem na toto téma pár zajímavých odkazů Pre-processing for OCR (outlined font) a converting fuzzy outlined text for ocr.

[Aleš Kapica]

Taky autor toho videocr píše, že dvacetisekundové video to čte tři minuty.

No to je fakt HODNĚ pomalé. Jak bych na to šel já jsem popsal o kousek výše.

[Josef Kufner]

Hele a jak dopadne časování titulků? Pokud máš každý titulek +/- 200 ms, tak to musí být děsně otravné.

[jejda]

To časování je dost bída to uznávám zvlášť když je ten film hodně ukecaný, no ve filmech kde se mluví trochu normálně mi přijde ta vůle 500ms docela snesitelná. Kdyby v tom čtení neměl tesseract tak moc chyb, šlo by číst obrázek třeba každých 100ms. To už by zvýšilo přesnost dostatečně ale zas za cenu pětinásobného zpomalení.

[jejda]

Jenom tak na zkoušku jsem to nechal číst snímek každých 0.1s a je to jak jsem předpokládal. Přesnost časování už se blíží k dokonalosti ale jedna minuta videa se počítá zhruba 8 minut. To je neúnosně dlouho. Sice mám 12 roků staré dvoujádro ale nemyslím si že by to na nějakém moderním CPU běželo o moc rychlejš.

[Aleš Kapica]

Co furt máte sakra s tím časováním titulků? To fakt nevíte, že jsou formáty, které jsou časované nikoliv přes timestamp, ale přes čísla snímků, což je mnohem jednodušší? A že není problém udělat přes aegisub korekturu rozpoznaného textu a opravené titulky pak libovolně převádět do libovolného formátu?

[Nebo]

V pirátských kruzích vyhrály časové titulky ponevac číslo snímku závisí od snímkové frekvence. U časových jedny titulky dokážou pokrýt vícero video norem.

[Aleš Kapica]

Toho, kdo si titulky sám píše nějaké pirátské kruhy nezajímají.

[jejda]

On spíš naráží na to, že ten skript zaokrouhluje začátek titulku dolů a konec nahoru a tím tam vzniká trochu rozptyl. Udělal jsem to tak protože se kvůli rychlosti nečtou všecky obrázky a taky pro případ že když by se tam náhodou objevil duplikát, tak aby to neblikalo. Dělat ocr kompletně na všech snímkoch mi přijde zbytečné. A nemusíš tak vůbec řešit fps.

[Aleš Kapica]

Bohužel nemám k dispozici nic, na čem bych to mohl porovnat s řešením přes netpbm.