Newsgroup: it.comp.software.divx
Titolo: vobsubocr

come avevo detto, ho iniziato a scrivere un programma di OCR
per convertire in formato testuale i sottotitoli contenuti nei
DVD.
la pagina su cui ho messo le cose che sto facendo e' questa:
http://fsinapsi.altervista.org/code
qualche giorno fa avevo messo un archivio (vobsub2srt.tar.gz)
contenente un paio di utilities a riga di comando che possono
gia' essere utilizzate per raggiungere lo scopo; tuttavia
questo metodo richiedeva GOCR e come gia' avevo detto, non ne
ero soddisfatto :-)
adesso sono passato a un linguaggio di programmazione piu'
astratto del C (ci vuole poco) e ho cominciato a scrivere un
nuovo programma con interfaccia grafica, in cui sto riscrivendo
tutta la parte di riconoscimento del testo... sono ancora alle
prime fasi, quindi ancora ci vorra' un po' di tempo...
il nuovo programma si chiama VobsubOCR, ho gia' messo sul sito
una versione preliminare, qui se ne puo' vedere una schermatina:
http://fsinapsi.altervista.org/code/vobsubocr.png
ho messo solo l'eseguibile precompilato per linux; nell'archivio
ci sono le librerie dinamiche necessarie per eseguire il
programma (ne servono moltissime altre, ma si trovano facilmente)
attualmente il programma permette di fare queste cose:
- uscire dal programma :-)
- aprire un file di sottotitoli in formato vobsub (nell'archivio
  c'e' un documento che spiega come si possa ottenerli dai DVD);
- scorrere tutti i sottotitoli contenuti nel file (vengono
  visualizzati nel centro della finestra, come si vede dalla
  figura);
- scorrere tutti i "blocchi polimorfi massimali" che sono
  contenuti nell'immagine (il blocco corrente viene visualizzato
  in rosso su sfondo giallo, come la "b" nella figura)
per ora non ho fatto molto altro.
in realta' ho gia' implementato la parte di piu' basso livello del
programma, quella che costruisce tutti i blocchi; il resto sara'
abbastanza semplice, perche' posso lavorare a partire dal livello
dei blocchi, che hanno una rappresentazione abbastanza astratta.
per la mia "teoria dei blocchi" mi sono leggermente ispirato ad
alcuni documenti di "layout analysis" che ho trovato in giro per
la rete (trovati cercando appunto "layout analysis" su google :-));
la differenza fondamentale rispetto agli altri programmi OCR open
source e' nella nozione di blocco, che nella mia implementazione
non e' semplicemente un rettangolo, ma una forma qualsiasi; questo
dovrebbe rendere il riconoscimento piu' facile in situazioni
critiche, come ad esempio le lettere inclinate (italic) sulle
quali gli altri programmi non si comportano molto bene...
per altri dettagli vi rimando alle documentazioni, che scrivero'
via via...
se qualcuno e' interessato mi faccia sapere.
altrimenti, se non interessa a nessuno, non rilascero' piu' le
future versioni :-)
ah, dato che sono passato a usare un altro linguaggio, e' adesso
immediato compilare il programma anche per Windows, quindi se
qualcuno vorra' provarlo anche sotto Windows, lo dica...
ciao

 qualcuno vorra' provarlo anche sotto Windows, lo dica...
Non sarebbe male l'idea, ma più che altro sono curioso di sapere quale
linguaggio stai usando.
bye, Giubbe
-- 
HomePage e FAQ: 
http://giubbe.altervista.org
Inutile scrivere in privato, non ricevo le email 

 linguaggio stai usando.
il mio, che ho chiamato TreeP (te ne avevo gia' parlato).
da una parte e' un grosso svantaggio perche' non posso contare su
contributi (in termini di scrittura/modifiche di codice) da parte di
altri volenterosi :-), ma dall'altra mi libera da un sacco di problemi
relativi a dover programmare in C, mi rende molto piu' veloce la
scrittura del programma in generale e in particolare di un'interfaccia
grafica, e infine mi permette di compilarlo per piu' piattaforme senza
dover modificare una virgola...
nell'archivio vobsubocr.tar.gz ho messo tutto il codice sorgente TreeP
che ho scritto di getto ieri sera; ho messo un eseguibile ELF
precompilato e le sole 5 librerie TreeP che usa (le librerie TreeP sono
una trentina in tutto); ho intenzione di rilasciare il linguaggio sotto
GPL, ma ci sono _grossi_ problemi pratici:
- la mancanza di documentazione adeguata lo rende inutilizzabile;
- la dimensione del linguaggio e' pachidermica, e ogni versione diventa
  presto obsoleta, quindi vorrei aspettare che si sia abbastanza
  stabilizzato;
- il compilatore del linguaggio e' tutto scritto nel linguaggio stesso,
  e questo costringerebbe chiunque a fare una prima installazione del
  compilatore precompilato per la propria piattaforma (altrimenti non
  sara' possibile ricompilarlo);
comunque non ho alcun problema a fornire, a chi lo chieda, tutto il
codice sorgente su cui e' basato.
adesso vorrei esporre brevemente la mia idea di base per questo
programma.
il concetto di base e' quello di "insieme massimale di punti connessi",
che ho chiamato anche "blocchi polimorfi", per distinguerli dai blocchi
usati dai programmi di OCR che ho provato.
il programma lavora su immagini bitmap, in bianco e nero (ogni pixel
e' bianco o nero, senza altre possibilita');
due punti neri sono connessi se sono adiacenti (possono essere
adiacenti in direzione orizzontale e verticale, oppure in diagonale),
oppure se esiste un altro punto nero che e' connesso con ognuno dei
due; e' una definizione ricorsiva.
un insieme di punti neri e' connesso se, presi due suoi qualsiasi
punti, sono connessi.
un insieme connesso e' massimale se, aggiungendogli qualsiasi altro
punto non e' piu' connesso.
la prima cosa che ho scritto ieri sera e' una funzione che, presa
una immagine bitmap, renda tutti gli insiemi connessi che contiene;
l'algoritmo e' molto carino ed efficiente (in pratica raggiunge lo
scopo in una scansione dell'immagine), solo che non mi e' venuto in
mente subito :-) (avevo prima tentato altre tre strade che non
andavano bene).
questa funzione e' scritta in C, si chiama "pix_connected_blocks"
ed e' contenuta nella libreria libtreeppix.so, che e' parte del
run time support di TreeP; quindi, nel codice sorgente TreeP, si
puo' vedere solo che questa funzione viene usata, ma a livello
TreeP si tratta di una funzione predefinita...
la mia idea fondamentale e' che questo e' tutto cio' che serve per
raggiungere lo scopo! in altre parole, non ci sara' piu' bisogno
di analizzare ulteriormente l'immagine!
faccio un esempio: nell'ambito della "layout analysis", un algoritmo
tipico e' l'algoritmo ricorsivo dei tagli: si prende una pagina di
un giornale passata allo scanner, si individua un "taglio" (cioe'
una riga bianca, orizzontale o verticale, che divide il foglio per
intero), poi si riapplica l'agoritmo ricorsivamente sulle due
parti separate dal taglio, finche' cio' e' possibile.
ebbene, dall'insieme dei blocchi, cosi' come li ho definiti,
possiamo fare cio' (ma anche di piu') semplicemente giocando a
livello astratto con i blocchi; ad esempio, se voglio trovare i
tagli orizzontali, riordino (con un unico comando "sort") i blocchi
in modo tale che la riga finale di un blocco non sia successiva
alla riga iniziale del blocco che lo segue nella sequenza; per
fare questo ordinamento ci vuole un attimo (il numero di confronti
richiesti e' dell'ordine di n*log(n), dove n e' il numero di
blocchi), dopodiche' scandisco la sequenza: i tagli orizzontali
saranno tutti e soli quelli tra due blocchi tali per cui la
riga finale del primo e' inferiore alla riga iniziale del
secondo. tutto qua! :-)
questo esempio mostra come sia facile fare analisi complesse
lavorando a livello astratto, e non a livello delle immagini...
faccio un ultimo esempio.
consideriamo questa immagine (per vederla bene, bisogna che il
programma che la visualizza usi font non proporzionale):
   *   *******
   *         *
   *   ***   *
   *   ***   *
   *         *
   *******   *
se GOCR incontra una cosa del genere, esso mostra all'utente
tutta l'immagine e chiede cosa sia (nella modalita' "database");
questo e' uno dei problemi che porta al mancato riconoscimento
di molti caratteri che "invadono" lo spazio di quelli adiacenti...
nella mia nozione di blocco, invece, si tratta di tre blocchi
separati: mi sono dimenticato di dire, infatti, che il mio
algoritmo "pix_connected_blocks" restituisce blocchi che possono
sovrapporsi nello spazio; tuttavia i blocchi non contengono
pezzi di altri blocchi, e in questo modo vengono evitati
conflitti, e questo e' molto utile in varie situazioni, ad
esempio con le lettere inclinate (italic)...
per ora e' tutto, temo di avere gia' scritto troppo :-)
per giubbe: non ti preoccupare di rispondere velocemente, ne
riparleremo con tutta calma tra un po' di tempo; temo che
anch'io dovro' rimandare la continuazione di questo programma

 vorra' provarlo anche sotto Windows, lo dica...
Tu sei il mio mito personale e non posso fare altro che darti tutto il
mio appoggio. Se hai bisogno di una mano come tester per Win XP SP2,
eccomi qui. ;)
-- 
Saluti, Kap - ICQ 19857429 - ¥'s Fan #01 - 
www.lordkap.it
 - VCC
Per il buffone c'è sempre pane. - Proverbio popolare

 eccomi qui. ;)
perfetto :-)
e' fondamentale che tu abbia alcuni DVD contenenti
sottotitoli e che tali DVD siano diversi da quelli che
uso io per testare il programma...
appena risolvo alcune questioni, compilero' una versione
per Windows (tu hai gia' tutte le dll che servono, quindi
dovrai scaricare solo il file EXE :-))
la scrittura del programma sta progredendo, anche se
purtroppo lentamente...
qui puoi vedere il problema che sto risolvendo in questo
momento:
http://fsinapsi.altervista.org/code/vobsubocr.png
questo e' un sottotitolo di un film (chi sa dire quale? :-))
il programma ha trovato 49 blocchi nell'immagine, ma questa
e' solo la prima fase dell'analisi! (in seguito dovra' fondere
alcuni blocchi tra loro, sulla base di regole semplici).
il blocco corrente e' la "m" mostrata in rosso su sfondo
giallo; nella riga in fondo sono mostrate alcune
informazioni su tale blocco;
le righe rosse orizzontali sono i tagli, e qui c'e' un
problema: le righe dovrebbero separare le linee di testo, ma
come si puo' vedere c'e' una linea di troppo a causa
dell'accento sopra la "E" maiuscola;
comunque questo l'ho gia' risolto :-)
inoltre ho scritto un po' di supporto relativo ai blocchi
(compresa una funzione per fare il merging e vari criteri di
ordinamento);
nel giro di qualche ora dovrei riuscire a completare in modo
abbastanza soddisfacente l'analisi della struttura dei
blocchi, ma restera' un problema: quello delle lettere "fuse"
insieme...
comunque ci vorra' ancora qualche giorno prima che il
programma cominci a riconoscere effettivamente il testo...
ciao

 
^_^
http://www.filmup.com/sc_alongcamepolly.htm
Domani se ho un po' di tempo testo il tutto su Linux. Non mi dire che
servono decine di librerie perchè il 56k piange!
Bye


 servono decine di librerie perchè il 56k piange!
una volta che hai il file seguibile (vobsubocr), prova a
dare questo comando:
ldd vobsubocr
e controllare cosa ti manca; non credo che te ne mancheranno
molte... comunque, se te ne mancasse qualcuna, forse puoi
trovarla sui cd che hai usato quando hai fatto l'installazione
(forse ti manchera' libgtk-1.2.so.0 libgdk-1.2.so.0 ecc
ma si trovano facilmente...)
comunque, queste sono le librerie che servono :-)
(quelle che contengono la parola "treep" le ho allegate al
programma)
        libtreepfreetype.so => /usr/local/treep/lib/libtreepfreetype.so
(0x40013000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40035000)
        libtreepx.so => /usr/local/treep/lib/libtreepx.so (0x40086000)
        libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x4009b000)
        libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x401f5000)
        libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4022e000)
        libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40231000)
        libdl.so.2 => /lib/libdl.so.2 (0x40258000)
        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x4025b000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40263000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40271000)
        libm.so.6 => /lib/i686/libm.so.6 (0x4034f000)
        libtreeppix.so => /usr/local/treep/lib/libtreeppix.so (0x40371000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4039a000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x403b8000)
        libz.so.1 => /usr/lib/libz.so.1 (0x403db000)
        libtreepgnudocs.so => /usr/local/treep/lib/libtreepgnudocs.so
(0x403e9000)
        libtreep.so => /usr/local/treep/lib/libtreep.so (0x403fa000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4041f000)
        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

 che stai sviluppando sia qualitativamente superiore?
no.
perche' non sto facendo un programma di OCR "general purpose",
ma un OCR che funzioni solo per i sottotitoli, e questa e'
una grossa semplificazione.
ad esempio, il mio programma quasi sicuramente non
funzionerebbe per niente bene su una immagine ottenuta
passando un foglio stampato con uno scanner...
GOCR ha un "armamentario euristico" molto corposo, mentre
io non ho intenzione di fare niente di tutto cio'...
comunque, anche se non so come funzioni ocrad, ho avuto
l'impressone che faccia una migliore "layout analysis" di
gocr; gocr e' troppo debole da questo punto di vista, e
questo gli fa commettere molti errori (ad esempio, spesso
una virgola che si trova su una riga viene emessa
nell'output sulla riga sottostante); il modello che sto
sviluppando e' gia' adesso migliore di quello di gocr, ed
e' basato su idee molto semplici... quindi gia' adesso
potrei prendere la parte di gocr che implementa la
"modalita' database" (la puoi vedere nel file
"src/database.c" del codice sorgente di gocr, in
particolare il confronto con i blocchi memorizzati nel db
viene fatto tramite la funzione "distance2") e utilizzarla
per completare cio' che ancora mi resta, e gia' facendo
in questo modo otterrei risultati migliori di quelli di
gocr, perche' ho una migliore analisi dei blocchi...
quando riusciro' a preparare la versione per fare i test,
vi faro' sapere (ci vorra' qualche giorno... ormai direi
che si rimandera' a dopo i giorni di festa).
ciao

 cominci a riconoscere effettivamente il testo...
Siamo in trepidazione! ;)
-- 
Saluti, Kap - ICQ 19857429 - ¥'s Fan #01 - 
www.lordkap.it
 - VCC
Guai alla povera fanciulla che incespica sulla via del vizio.

 combinazioni crescono a dismisura.
be', mi e' parso che non ne capitino moltissime... di solito
sono combinazioni come "ff" "tt" "rt" "rv" perche' sono lettere
che hanno estensioni che tendono a toccarsi se messe accanto...
nel caso pessimo andranno trattate come lettere singole...

 
http://www.filmup.com/sc_alongcamepolly.htm
allora vediamo chi indovina questo :-)
http://fsinapsi.altervista.org/code/vobsubocr.png
ho messo una nuova versione del programma,
non c'e' molto di piu' ma almeno si possono scorrere tutti i
sottotitoli selezionandoli da una lista scrollabile
inoltre (cosa moooolto importante) si possono salvare le
immagini, cosi' potete mandarmi quelle su cui il programma
non si comportera' bene
domani compilero' anche la versione per Lord Kap

 nel caso pessimo andranno trattate come lettere singole...
Son curioso. ;)
-- 
Saluti, Kap - ICQ 19857429 - ¥'s Fan #01 - 
www.lordkap.it
 - VCC
Il coraggio è contro natura. Lo dimostra il fatto che pochi ne hanno.
Roberto Gervaso

innanzitutto chiedo scusa perche' la conversione dei sottotitoli
e' al limite dell'OT, anche se credo sia molto vicino a quello del
Ng...
forse faro' una ml in modo da non rompere ulteriormente le scatole
a chi non interessa.
a Lord Kap devo delle scuse perche' non ho ancora compilato la
versione Windows :-) (in realta' si e' presentato un problema
tecnico, ma lo risolvero'... no so quando... porta pazienza :-))
poi volevo dire che ho appena messo una versione che implementa
quasi totalmente la parte di layout analysis del programma, anche
se ha ancora qualche problemino, che spero di risolvere presto.
come al solito, qui potete vedere una nuova schermatina:
http://fsinapsi.altervista.org/code/vobsubocr.png
(quella di ieri non e' stata indovinata, cosi' ne ho messa una
piu' facile, almeno per chi l'ha visto...)
dalla schermata si puo' vedere come adesso il programma riesca a
individuare tutta la struttura della frase; dovrebbe riuscirci
nella maggior parte dei casi, e mi sarebbe molto utile ricevere
immagini su cui non si comporta bene, in modo da analizzare e
risolvere i problemi...
Buone Feste a tutti quanti.

 Windows :-)
No problem. Oggi non avrei potuto far niente (Mjpeg2Divx sta girando da
24 ore)... ;)
-- 
Saluti, Kap - ICQ 19857429 - ¥'s Fan #01 - 
www.lordkap.it
 - VCC
Viviamo sempre meno, e impariamo sempre di più. La sensibilità si
arrende all'intelligenza. - Rémy de Gourmont

 24 ore)... ;)
poco fa ho messo una versione precompilata per windows (trovi le
istruzioni dentro alla versione per linux... lo puoi scompattare un
archivio tar.gz da windows, giusto?); ad ogni modo, basta che lo
copi nella stessa directory dove hai mjpeg2divx e dovrebbe funzionarti
subito, perche' hai gia' tutte le DLL; se non parte, fammi sapere...
in un post precedente hai parlato di sottotitoli in corsivo con molti
caratteri attaccati... se in futuro ti imbattessi di nuovo in casi
cosi' critici, mandami qualche immaginetta (lo puoi fare dal programma,
con l'opzione "File->Salva l'immagine"); mi sarebbe molto utile per
cercare di affinare le regole...

 cercare di affinare le regole...
Va bene.
Ah, auguri di buon Natale a tutti quanti! ;)
-- 
Saluti, Kap - ICQ 19857429 - ¥'s Fan #01 - 
www.lordkap.it
 - VCC
Dio può essere meglio immaginato che descritto, e Lui esiste ancor più
sicuramente di quanto possa essere immaginato. - Sant'Agostino