Discussioni Wikizionario:Importazione dizionari PD

Da Wikizionario, il dizionario a contenuto aperto.
Jump to navigation Jump to search

Vedi Wikizionario:Bar#Dizionari_PD.

Ho aggiunto anche il pianigiani, dite che va caricato il djvu su commons? --Diuturno (disc.) 17:43, 8 dic 2009 (CET)
Aiuterebbe, però è troppo grosso, non penso che ci riusciresti (MediaWiki è stato corretto e dovrebbe funzionare, bisogna aspettare che aggiornino i wiki). --Nemo 09:48, 9 gen 2010 (CET)

Zingarelli[modifica]

Spostiamo qui le discussioni specifiche sullo Zingarelli e sulla sua elaborazione (discussione in lista per i soci WMI).

Spezzamento e raddrizzamento delle pagine[modifica]

La prima cosa da fare è spezzare le due pagine contenute in ogni immagine di http://www.archive.org/details/VocabolarioDellaLinguaItaliana e raddrizzarle, per poi darle in pasto all'IA e ottenere un (auspicabilmente) bel DjVu da usare in Wikisource o dove vogliamo. Laurentius ha già fatto delle prove con unpaper: risultati? Io non ho tempo in questi giorni per studiarmi le configurazioni, quindi mi sono limitato a un mogrify -format pgm *.JPG seguito da unpaper -l double --output-pages 2 -bn h %03d.pgm %04d.pgm. Qui parte delle informazioni; potete vedere alcuni risultati qui: [1] [2] sono due pagine spezzate male senza nessun avviso; [3] è una pagina intera ma storta perché "out of deviation range"; [4] è una pagina non ruotata per lo stesso motivo e spezzata male. Forse bisogna provare ad alzare il limite del "deviation range", ma prima serve investigare se spezza prima di raddrizzare, altrimenti è ovvio che non ci riesca perché le due pagine di una stessa immagine non sono storte allo stesso modo. Laurentius, riesci a farlo tu nei prossimi giorni? Perché altrimenti domani provo a caricare questi PGM nell'IA come sono (una riconversione verso JPG è rischiosa e non ho voglia di pensare come farla) cosí almeno fra 4-5 giorni circa dovremmo avere già i primi prodotti della derivazione. --Nemo 10:20, 13 mar 2011 (CET)

Ah, un'altra cosa da verificare è quanto devono essere scure le righe nere perché le usi per spezzare le pagine: qui le ombre non sono scurissime; altrimenti si potrebbe convertire in bianco e nero per marcare le differenze (che però non è il massimo). --Nemo 10:38, 13 mar 2011 (CET)
Con unpaper ho fatto giusto un paio di prove di base. Con le impostazioni di default, se gli si passano immagini bitonali funziona bene; con le immagini in scala di grigi il risultato è quello che hai visto tu, piuttosto scarso. Bisognerebbe esaminare bene le varie opzioni, e non l'ho ancora fatto. Se non sbaglio, ruota singolarmente le due pagine. Se non si riesce a farlo lavorare direttamente sugli originali in effetti si può farlo lavorare in bianco e nero e poi riportare sull'originale le trasformazioni; ma sarebbe sensato se un procedimento di questo tipo (o migliore) lo facesse già da sé. - Laurentius (disc.) 11:42, 13 mar 2011 (CET)
E passando al bitonale i caratteri restano ben distinguibili oppure perdono anche solo minimamente di leggibilità e quindi riconoscibilità per l'OCR (come spesso accade, ma può succedere anche il contrario)? Se la prima, l'unico danno è sulle immagini, ma a quello si può pensare dopo, quindi potresti procedere in bitonale e caricare nell'IA (oppure, se non ti basta la banda, mi dici le impostazioni migliori e lo faccio io). --Nemo 11:53, 13 mar 2011 (CET)
Be', già che c'ero ho caricato i miei PGM schifidi in http://www.archive.org/details/VocabolarioDellaLinguaItaliana2p ma non deriva questo formato (a meno che sia perché mancava l'estensione nei file, uffa; comunque provo a convertire in TIFF); visto quanto ha detto Alex, può darsi che l'IA nella derivazione spezzi e raddrizzi anche, comunque quando hai finito colle tue prove, Laurentius, se ti basta la banda ti passo i dati di accesso alla mia utenza sull'IA cosí sostituisci il mio tar col tuo (a questo punto comunque si potrà fare solo fra tre o quattro giorni perché durante la derivazione è tutto bloccato). Nemo 09:15, 14 mar 2011 (CET)
No, passando al bitonale (senza scegliere bene la soglia) i caratteri perdono di leggibilità, sicuramente per un umano, immagino anche per un OCR (d'altra parte, se migliorassero, un OCR un minimo furbo la conversione se la può fare da sé). Può darsi che la leggibilità migliori se si sceglie bene una soglia. Nel nostro caso, questo è reso difficile dal fatto che le pagine sono poco uniformi. Probabilmente piuttosto che passare ad un bitonale utilizzando una soglia sarebbe meglio utilizzare una curva ripida, che schiacci il chiaro sul bianco e lo scuro sul nero, ma mantenendo anche qualche grigio. In questo modo si otterrebbero immagini in scala di grigi "quasi bitonali" molto contrastati.
Al momento non credo sia utile caricare dei PGM sull'Archive, non aggiungono nulla... magari in futuro se riusciamo a rielaborarli in modo utile. - Laurentius (disc.) 22:59, 21 mar 2011 (CET)


Qualità della scansione[modifica]

Discutiamo qui della qualità della scansione dello Zingarelli (il tar iniziale che ho piazzato nell'IA) per capire se ce ne serve un'altra (rifarla non costerebbe poi tanto; se il problema è alla fonte tanto vale risolverlo alla fonte). Le pagine storte probabilmente si possono sistemare "semplicemente" facendo piú attenzione; la poca uniformità dei colori (puntini grigi ovunque) è facile che dipenda dal cartaceo (muffa?) ma potrebbe anche essere un problema di compressione (non so; qualcuno se ne intende?), magari si può chiedere un formato lossless; non credo invece che passare a 400 o anche 600 dpi aiuterebbe molto, ma se aiutasse sarebbe la cosa piú facile da farsi. Nemo 11:49, 13 mar 2011 (CET)

I puntini grigi, se intendi quelli che penso, credo siano problemi dell'originale (muffa o altro); il fatto che ci siano parti più chiare o più scure non so (potrebbe essere la scansione così come fogli ingialliti). Non credo possano essere problemi di compressione. Se dovessi fare una scansione per me, senza vincoli particolari, utilizzerei un formato lossless ed una risoluzione alta, aspettando il più possibile a comprimere; però, nella pratica, fra una JPEG ad alta qualità ed un'immagine lossless cambia poco. Sicuramente sono indistinguibili a prima vista, e nel nostro caso c'è comunque il rumore dato dalla scansione, che supera quello della compressione. Non so dire quale sia l'effetto del variare la risoluzione. Se vogliamo passare attraverso il bitonale, una risoluzione maggiore è utile, perché compensa la perdita delle informazioni sui grigi. - Laurentius (disc.) 22:59, 21 mar 2011 (CET)

La "mia via" (Alex)[modifica]

Per me è l'occasione di approfondire l'utilizzo di FineReader 10, che possiedo in copia regolarissima (è il regalo di Natale che mi sono fatto).

Ho constatato che dando a FineReader le immagini a doppia facciata, e attivando le opzioni "Attiva pre-elaborazione" e "Separa le pagine", FineReader fa tutto quello che serve:

  1. acquisisce l'immagine delle facciate
  2. separa le pagine
  3. esegue il deskewing (correzione dei difetti, raddrizzamento ecc)
  4. identifica regioni e colonne della pagina
  5. identifica le aree di "figura" e le salva come immagine
  6. esegue l'interpretazione
  7. salva tutti i dati raccolti in formato ABBYY
  8. esporta in una varietà di formati e di contenuti:
    1. esporta le pure immagini delle pagine (non quelle originali: quello derivanti dallo splitting e deskewing, suppongo) in una varietà di formati grafici (da quelle immagini si può allestire lo strato immagien di un djvu)
    2. esporta il "puro testo" come file txt
    3. esporta il testo formattato in rtf, o doc, o html
    4. esporta un file html completo delle immagini (tutte contenute in una cartella file_nome del file, come quando si esegue una copia locale di una pagina web completa).

Nei miei primi test, i file jpg disponibili, di alta qualità a 300dpi, producono un warning "Aumentare la risoluzione per la corretta interpretazione dei caratteri piccoli", sulla grande maggioranza delle pagine. Mi piacerebbe provare con un paio di immagini TIFF e non JPG, sia alla stessa risoluzione di 300 dpi, che a risoluzione maggiore: 600 dpi. La qualità dell'OCR, nonostante il warning, è passabile, ma piuttosto lontana dalla qualità che si ottiene con una risoluzone ottimale. I "prodotti" che otterrò li metterò in rete dal mio account toolserver, nella cartella http://toolserver.org/~alebot/voc/. Nella stessa cartella posso pubblicare altri file, se vi è comodo, ma non troppo grandi, perchè mi pare di avere solo un Gby a disposizione. --Alex brollo (disc.) 15:19, 21 mar 2011 (CET)

Grazie. Puoi dirci che PC (processore, RAM) hai per capire se è qualcosa su cui si può cercare aiuto? Inoltre, pensi che potresti importare http://ia600403.us.archive.org/5/items/VocabolarioDellaLinguaItaliana/VocabolarioDellaLinguaItaliana_abbyy.gz ? Forse questo archivio contiene i risuiltati del primo lavoro di elaborazione automatica che hai detto impiegare una nottata ogni cento pagine. Grazie, Nemo 21:14, 21 mar 2011 (CET)
un solo Gby di RAM, era il classico portatile da 450 euri di due anni fa circa. Una macchinetta. Il processore a memoria non lo ricordo.
quanto al file abbyy.gz, ci provo, a darci un occhio. - Alex brollo
I punti 1-4, se li fa bene, rendono superfluo lavorare su unpaper. Usare dei TIFF dovrebbe cambiare molto poco, queste JPEG non sono molto compresse. Sarebbe interessante invece vedere come si comporta con una risoluzione maggiore. Nemo, è possibile (in modo semplice) avere qualche pagina di prova in risoluzione più alta? Altrimenti potresti provare a fare qualche scansione in condizioni simili di un vocabolario qualunque e vedere come si comporta. - Laurentius (disc.) 22:59, 21 mar 2011 (CET)
No, non credo sia possibile: tanto vale chiedere il vocabolario intero, mi sa (fra una cosa e l'altra). Nemo 10:25, 22 mar 2011 (CET)
Sui primi risultati (che fra un po' Alex mette nel Toolserver): l'OCR è quasi inutilizzabile, quanto ci vuole per il character training completo? Una volta sistemato quello ci serve un rtf per provare delle estrazioni di dati (anche solo delle prime 100 pagine va bene). Se però l'OCR resta pessimo, bisogna provare a fare la correzione "manuale" delle parole non riconosciute all'interno di FineReader; se questo non è possibile e non si può trovare aiuto da altri (vedi sopra) allora bisogna trovare qualche altra soluzione. Una volta completata l'elaborazione ci sarà utile l'esportazione delle singole pagine in JPG, per caricarle nell'IA e farci fare il DjVu. Nemo 10:39, 22 mar 2011 (CET)
Il character training completo è un'entità astratta. E' una procedura totalmente manuale, e in presenza di file con risoluzione non ottimale (che infila elementi "random" nelle immagini) praticamente non finisce mai. Le cose si complicano esponenzialmente se oltre al carattere si tenta anche di fare il training specifico per la formattaziane. Un lavoro impossibile, io mi ci metto solo se le pagine hanno alcuni caratteri strani, ma i formati sono molto poco variabili. Non è il caso del vocabolario. - Alex brollo
Ho capito, ma bisogna pur fare delle prove: questo è l'obiettivo cruciale, tutto il resto è fuffa e se non procediamo qui siamo bloccati su tutti i fronti. Hai fatto il character training per una decina di pagine (significative)? Poi bisogna rifare l'OCR automatico sulla base del dizionario creato, no? Vediamo quanto migliora l'OCR. Se non migliora proviamo con con 20-30 pagine di tutti i tipi e vediamo se migliora. Se non migliora cerchiamo di capire (nella sezione apposita) se il problema è la qualità delle scansioni; se non c'è niente da fare facciamo tutta la correzione manuale dell'OCR in FineReader trovando qualcuno che abbia voglia di farlo, con un PC abbastanza potente e la tua licenza o un'altra che compriamo apposta; se non riesci a fare i tentativi precedenti perché il computer è troppo lento, idem ma allora ci serve che scrivi bene quali impostazioni deve usare per evitare che debba imparare da zero come funziona il programma. Nemo 11:32, 31 mar 2011 (CEST)
Non assicuro affatto di potermi gettare nell'avventura del training; il numero di ore necessario è notevole. Appena trovi questo ipotetico volontario con PC potente e FineReader 10 installato, mettimi in contatto con lui, gli passo in qualche modo i documenti FineReader (che contengono tutto quello che il programma è riuscito a fare: comprese le immagini delle pagine raddrizzate al meglio, una per una) e lui va avanti. Inutile spiegare adesso, ovviamente, i trucchi (quei pochi che conosco): tutto dipende dal livello di conoscenza dell'ipotetico volontario. --Alex brollo (disc.) 17:16, 31 mar 2011 (CEST)
L'ipotetico volontario dovrebbe avere FineReader da te, non puoi prestare la licenza? Comunque, ci vuole cosí tanto anche per fare una decina di pagine e poi ripetere il riconoscimento automatico? Hai provato? Nemo 13:24, 1 apr 2011 (CEST)
Ho provato a fare un po' di training. Durante il training, viene presentata l'immagine elaborata delle lettere non riconosciute con sicurezza dopo pre-elaborazione; ti confermo che la pre-elaborazione consiste nella trasformazione in puro BN, e dalle immagini che ho visto sono ben evidenti i difetti da insufficiente risoluzione. Inoltre, risulta evidente che FineReader si è impaperato spesso proprio sui lemmi, che non riesce a "isolare in una regione autonoma".
Il tempo richiesto dal training "su una decina di pagine" equivale a molte, molte ore. Per fare le cose bene, si sta parecchio; in una mezz'ora non ho fatto che una decina di righe. Alex brollo
Grazie per le informazioni, adesso me ne occupo io direttamente per capire come funziona. Nemo 11:45, 19 apr 2011 (CEST)
Ieri Alex ha completato il trasferimento dei suoi primi "elaborati", adesso vedrò di trovare un PC con Windows per lavorarci... Nemo 12:16, 17 mag 2011 (CEST)

Illustrazioni[modifica]

Una cosa utilizzabile con relativa facilità fin da subito sono le illustrazioni. Chiedo ad Alex di caricarle nel Toolserver e poi disinteressarsene del tutto perché se ne può occupare qualcun altro del tutto indipendentemente dal resto. Nel voc1-100.zip trovo 318 immagini; a parte alcuni errori sulle pagine rovinate, sono tutte illustrazioni molto ben ritagliate. Il problema è caricarle col titolo giusto. Serve qualcuno (chiunque si intenda un po' di bot e simili) che recuperi le informazioni giuste. Negli HTML si possono trovare cose come

<div><img src="voc1-100 - 0016_files/voc1-100 - 0016-1.jpg" style="width:51pt;height:74pt;"/>
<p><span class="font4">Abaca.</span></p></div><div>

con qualche variabilità di a capo e cose simili. Bisogna estrarre tutte queste informazioni per poi caricare in Commons (in questo esempio) qualcosa come "Vocabolario Zingarelli 1922 - Illustrazioni - Abaca.jpg" con in descrizione (o nel titolo) anche la pagina. Nemo 10:39, 22 mar 2011 (CET)

Se il formato è circa sempre uguale non dovrebbe essere un problema. Ma voc1-100.zip dove si trova? - Laurentius (disc.) 13:57, 22 mar 2011 (CET)
lo zip l'ho per ora spedito a Nemo per mail. Roba di stamattina, non ho avuto nemmeno il tempo di aprire le cartelle e guardare i nomi dei file. Soppongo però che - essendo divise in una cartella per pagina - già abbiano nel loro nome traccia della pagina da cui provengono. Mi sento un po' in imbarazzo, e si vede, temo che anche il mio cervello abbia un processore poco potente e troppo poca RAM per questo lavoro. ;-) --Alex brollo (disc.) 14:59, 22 mar 2011 (CET)
Finalmente ho aperto una cartellina dei file associati a una pagina in html. Trovo un'immagine, il programma l'ha chiamata voc1-100 - 0053-1.jpg. Siamo a posto: un po' di aritmetica semplice, si tratta della figura 1 della pagina 53 nella serie 1-100 (ossia: della pagina 53). Conclusione: le figure possono essere raccolte in un unico contenitore, e rinominate con calma, il nome ha tutti i dati peri il loro riconoscimento/ridenominazione. Nel frattempo siamo a 300 pagine "trattate". --Alex brollo (disc.) 00:57, 23 mar 2011 (CET)
L'algoritmo che ho scritto sopra è sbagliato, perchè in realtà le pagine sono poi sdoppiate... ma non è un problema insolubile.:-) - Alex brollo
Dunque, ho creato l'apposita commons:Category:Illustrations from Vocabolario della lingua italiana by Zingarelli, 1922 (ristrutturando tutte le categorie correlate per piazzarla bene...). Come titolo direi di usare "Abaca - Illustrazione dal Vocabolario Zingarelli 1922 - p. 53 n. 1.jpg". "Abaca" va recuperato dall'html; 53 è il risultato di (x-100)*200+y dove x è 100 preso da "voc1-100" e y è 53 preso da "0053-1" (può essere necessario correggere qualcosa dove la numerazione delle pagine fosse sfalsata per quanto detto sotto); 1 è preso sempre da "0053-1". Nemo 11:00, 31 mar 2011 (CEST)
Alex ha scritto sotto di aver caricato tools:~alebot/zingarelli/immagini.zip. Nemo 09:10, 7 apr 2011 (CEST)
Se volete le posso caricare io. Intanto penso a come mandarle su già un po' categorizzate come si deve. -- Basilicofresco (msg) 08:03, 12 apr 2011 (CEST)
Certo che vogliamo, grazie! Fa' un fischio se ti serve aiuto per l'approvazione del bot. :) --Nemo 20:44, 14 apr 2011 (CEST)
Rettifico, gli HTML si trovano in [5] [6]. Nemo 19:30, 15 apr 2011 (CEST)

Purtroppo c'è un problema: nelle prime 40 pagine ad esempio ci sono 30 immagini. Di queste:

  • 7 hanno una didascalia corretta (indipendentemente dalla formattazione)
  • 10 hanno una didascalia errata (es. abbaiare anziché abbaino)
  • 6 mancano di qualunque didascalia
  • 3 hanno la didascalia dentro l'immagine
  • 2 sono state saltate

Il vero problema sono le 10 con la didascalia presente ma errata. Guardando il file djvu poi... beh, l'ocr direi che ha lavorato molto bene, il testo è spesso di difficile lettura persino per un umano. Non riusciamo a procurarci una buona scannerizzazione? Esistono altre edizioni più reperibili? (magari anche più recenti di uno o due anni, tanto tempo che abbiamo finito...) -- Basilicofresco (msg) 07:41, 20 apr 2011 (CEST)

Tutto ciò è alquanto sconfortante. Non ho ben capito che cosa voglia dire che mancano di qualunque didascalia (intendi anche nel dizionario stesso?) o sono state saltate (non sono sono state riconosciute come immagini?), mentre le didascalie errate a questo punto ci costringono a una correzione dell'OCR anche prima di usare le illustrazioni. Nemo 12:16, 17 mag 2011 (CEST)

Aggiornamenti[modifica]

lemme lemme vado avanti[modifica]

Ho lanciato l'OCR sulle pagine 701-fine. Prossimo passo, risistemazione-renaming di massa delle illustrazioni. Datemi la radce definitiva dei nomi delle immagini per Commons; io ci aggiungerei un suffisso -pag-numero dove pag è il numero di pagina djvu, e numero è il numero d'ordine dell'immagine nella pagina. Se mi date conferma, e magari mi date anche un uggerimento sulla categorizzazione Commons delle immagini, mi facilitate il lavoro. Quanto al djvu, mi pare che i djvu prodotti da Aubrey siano eccellenti e "definitivi", se siete d'accordo suggerirei di pubblicarli già su Commons, per facilitare gli "agganci" nel momento del caricamento delle illustrazioni. --Alex brollo (disc.) 07:30, 25 mar 2011 (CET)

Grazie per gli aggiornamenti, ma ti prego, rispettiamo la suddivisione wiki in sezioni di questa discussione, altrimenti impazzisco. Delle #Illustrazioni si parla sopra. Ribadisco che secondo me dopo averle caricate nel Toolserver te ne dovresti disinteressare e lasciare il lavoro ad altri (che discuteranno sopra di questi dettagli), a meno che ti bastino pochi minuti per pensarci.
I DjVu di Aubrey sono carini e leggibili, ma hanno pagine tagliate (come le 11 e 12 del vocabolario) e un OCR atroce, non ci servono a quasi nulla né in Wikizionario né in Wikisource quindi meglio non caricarli. Gli "agganci" di cui parli è bene farli solo dove servono cioè in Wikisource, no? Dopo (quando ci sarà qualcosa di stabile cui agganciarsi). Nemo 11:00, 31 mar 2011 (CEST)
Non concordo sul fatto che non servano in wikisource: se sono leggibili, servono, anzi sono indispensabili. Mi pare che stia invece emergendo il problema se serva wikisource. :-)
Illustrazioni: ok, le carico "brutalmente" su toolserver e lascio ad altri la gestione (renaming compreso). --Alex brollo (disc.) 17:16, 31 mar 2011 (CEST)
Ma infatti non sono leggibili. Solo il DjVu in sé lo è, le pagine col testo a fronte conterrebbero per lo piú caratteri a caso. Nemo 13:26, 1 apr 2011 (CEST)
finita la prima passata[modifica]

Completato l'OCR, adesso la fase dura-durissima: la verifica e correzione degli errori umani e software.

Il primo errore umano che ho trovato è la mancata scansione di una doppia facciata: mi mancano le pagine 9 e 10 (numerazione cartacea del vocabolario). Nell'immagine VocabolarioDellaLinguaItaliana_0010.JPG infatti sono rappresentate le facciate n. 8 e 11; i lemmi passano da abbrivio a aborto. Evidentemente era stata strappata una pagina.

Il secondo errore software è quello del mancato split automatico delle facciate. Ho trovato per ora due casi, ma devo verificare ancora.

Che fatica. :-( --Alex brollo (disc.) 08:57, 27 mar 2011 (CEST)

Altro errore di scannerizzazione: le jpg 401 e 402 sono relative alla stessa facciata pag. cartacea 792 e 793. L'errore compensa e bilancia quello dell'assenza delle pagine 9 e 10 (e quindi probabilmente il controllo pagine globale risultava "falsamente giusto"). Cancello le due pagine e ri-salvo... :-( --Alex brollo (disc.) 00:25, 28 mar 2011 (CEST)
Com'è venuto il testo ocr? Ci sono molti errori o ha funzionato bene? -- Basilicofresco (msg) 18:57, 28 mar 2011 (CEST)
La mancanza era nota, purtroppo questa è l'unica copia che ci sia in giro. Nemo 11:00, 31 mar 2011 (CEST)
Ricaricato in dropbox copia corretta del file djvu[modifica]

Ho rimosso da Vocabolario I.djvu condiviso in dropbox le due pagine duplicate (cadevano in 803 e 804); io aggiungerei due pagine vuote nella posizione delle pagine mancanti (le pagine cartacee 9 e 10), da inserire dopo la pagina djvu 19 (che corrisponde alla cartacea 8). Comments? Tomatoes? --Alex brollo (disc.) 09:41, 28 mar 2011 (CEST)

Wikianamente, ho aggiunto due pagine vuote con una dicitura che spiega che si tratta di pagine mancanti. Tutto sarebbe pronto per il caricamento su Commons, se si accettano alcune pagine molto "storte". Le più storte sono le pag. 11 e 12 cartacee (nel file Vocabolario I.djvu). Che famo, correggiamo o carichiamo? --Alex brollo (disc.) 14:21, 28 mar 2011 (CEST)
Sono piuttosto sicuro che da qualche parte in Wikisource ci sia uno standard sulle pagine vuote (se ricordo bene «[page intentionally left blank]»), basato su un qualche standard bibliotecario o qualcosa del genere; poi controllo, comunque credo di poterlo facilmente classificare come il meno importante dei nostri problemi. :-p Nemo
Le pagine assenti sono cosa assai diversa dalle pagine vuote (senza testo), proprio come un insieme vuoto è un insieme vuoto ed è cosa diversa da "nulla". Io preferisco avere delle pagine vuote piuttosto che delle pagine assenti. Se la sequenza delle pagine non è corretta, l'esperienza mi dice che poi nascono dei bei problemi. Comunque, adesso i dile djvu dovrebbero essere OK: le pagine doppie sono state cancellate, quelle mancanti sono state inserite come pagine "dummy". Purtroppo, i blocchi che erano tutti di 200 pagine non lo sono più; un blocco ha 202 pagine, un altro 198... e non rifarò il lavoro. --Alex brollo (disc.) 17:16, 31 mar 2011 (CEST)
Per "pagina vuota" intendevo appunto "pagina vuota messa per indicare l'assenza di una pagina". Nemo 13:31, 1 apr 2011 (CEST)
Il punto[modifica]

A questo punto abbiamo:

  1. due djvu discreti, di 80-90 Mby l'uno, teoricamente caricabili su Commons, condivisi;
  2. un ocr disponibile sia in forma txt "estratto" dal layer testo dei file djvu, che incorporato nel file djvu stesso ed estraibile automaticamente, pagina per pagina, qualora si decidesse di creare due files Indice: su Wikisource, condivisi;
  3. una batteria di file FineReader 10, ognuno comprendente circa 100 doppie facciate / 200 pagine, da cui si possono esportare vari formati di file, fra cui un txt (non ancora condivisi)
  4. la collezione delle immagini intercalate nel testo in formato jpg a buona risoluzione (estrazione automatica con FineReader, qualità "high" (non ancora condivise)

Il possibile e realistico contributo di wikisource lo limiterei a:

  1. creazione dei due file Indice per permettere una "rilettura collaborativa"; questa eventualità richiede obbligatoriamente che siano caricati su Commons i due file djvu;
  2. test per l'individuazione di possibili algoritmi postOCR che agevolino la correzione/formattazione del testo.

E adesso, che famo? --Alex brollo (disc.) 16:52, 31 mar 2011 (CEST)

È tutto scritto in Wikizionario:Importazione_dizionari_PD#Tabella_di_marcia e ne stiamo discutendo in #La "mia via" (Alex).

File su toolserver[modifica]

Ho aperto in toolserver la cartella http://toolserver.org/~alebot/zingarelli/. Vi trovate dentro, per ora, testo_completo.zip, che contiene l'OCR txt completo del dizionario, come FineReader l'ha fatto, senza training. Man mano che produrrò cose, le metterò là.

per qualche motivo il file pare difettoso, lo ricaricherò; i testi sono anche in DropBox. Se avete urgenza chiedetemeli via email. --Alex brollo (disc.) 07:50, 1 apr 2011 (CEST)
Sto ricaricando il file, in questo momento; e subito dopo caricherò immagini.zip che contiene "as they are" la collezione delle figure, in jpg ad "alta" risoluzione. Anche qui non sono del tutto soddisfatto: alcune sono duplicate. L'allineamento sarà piuttosto faticoso. Ma.... hopreferito accelerare i tempi e condividerle, così come FineReader le ha prodotte. --Alex brollo (disc.) 22:10, 1 apr 2011 (CEST)
stesso file immagini.zip, ricaricata una serie che aveva qualche problema (gruppo da 700 in poi). --79.31.236.99 17:08, 2 apr 2011 (CEST)

Progetti futuristici: hOCR[modifica]

Ieri sera ho avuto una lunga conversazione don federico Boschetti riguardo all'OCR in generale; so già che gli esiti saranno severi (mal di testa, senso di inadeguatezza, depressione ecc:). Vi segnalo che esiste il formato file hOCR che consiste in un file html in cui sono incorporati gli elementi spaziali dell'output OCR. Esiste anche un gadget Firefox che si chiama "hOCR editor". La cosa mi era totalmente sconosciuta; il fatto curioso è che ne avevo inventato inconsapevolmente una specie di prototipo.... Studierò la cosa, e fra qualche-molto tempo vi dirò se la cosa presenta qualche interesse in generale, o per il caso che stiamo discutendo. Mi pare di capire comunque che ci vuole un output XML del programma OCR; nel caso dello Zingarelli, ne potremmo avere due diversi, entrambi di qualità bassina (uno da IA, uno dall'OCR incorporato nel dile djvu di Aubrey), mentre il mio fineReader 10 non lo produce. Esiste poi una serie di "cose" che maneggia Federico, e che si chiamano "allineatori"; la sola parola mi ha riempito di tenerezza. :-) --Alex brollo (disc.) 11:10, 30 mar 2011 (CEST)

Continua a scrivere qui, invece di andare fuori tema in lista, che ti leggiamo. :-p Questa cosa ci servirà, se mai ci servirà, solo molto piú avanti, se mai dovremo produrre un DjVu con OCR corretto e mappato, meglio non affaticarcisi la mente ora: adesso la priorità è il testo. Nemo 11:00, 31 mar 2011 (CEST)

OCR con FineReader 11[modifica]

Ciao, Alex, Xavier non era in grado di aiutarmi, quindi – poiché ho accesso a una potente macchina Windows per qualche giorno da un amico – ho appena comprato una licenza di FineReader 11 e ho caricato le prime 600 pagine da qui: [7]. Per il momento ci ho lavorato solo un'ora, ecco i risultati.

  1. Secondo te quelle immagini sono adeguate? Non mi sono messo a scaricare i 20 GB (10 compressi) delle immagini originali anche perché avevano dei margini un po' sbagliati, ma non sono sicuro che la risoluzione fosse la stessa né che la versione RIT non abbia qualche perdita di qualità. FineReader si lamentava della risoluzione incorretta di alcune immagini, specie quelle "finte" (intenzionalmente bianche, per lo piú), e di alcune diceva di alzare la risoluzione rispetto ai 300 dpi, ma erano solo due quindi ho ignorato.
    • Ho visto che la documentazione, per i libri malmessi, suggerisce i 400 dpi, ma dice che andare oltre non serve a molto. D'altro canto non credo che la risoluzione sia il problema (a parte che è già 400 o 300 dpi), dato che le imperfezioni della stampa si vedono benissimo...
  2. Vedo che FineReader consuma allegramente tutti i gli 8 processori, ma non ha un consumo enorme di RAM. Mi piacerebbe potere aumentare il limite, qualunque esso sia, che mi impedisce di caricare tutte le 1200 pagine insieme. Non ho ancora controllato la documentazione. Basta non aggiungere 1800 pagine alla volta al documento in corso; anche 1200 se le pappa tutte allegramente.
  3. Come mi dicevi, la vera tragedia è il riconoscimento delle aree. Perché riconosca gli esponenti, devo cancellare le aree automatiche, selezionare le due colonne, ritagliare gli esponenti e le immagini, riaggiungerli come aree separate a uno a uno. Sarebbe già un miglioramento se ci fosse un comando che in un colpo solo ritaglia un'area e la trasforma in un'area separata.
  4. Una piccola grande sfida sono i segni grafici: [8]. Non sapevo bene come fare dalla schermata di verifica, ma ho attivato la verifica con addestramento nelle opzioni e mi consente di inserire caratteri speciali fra cui spero di trovare qualcosa di adeguato almeno come segnaposto. Suggerimenti? Mi sono inventato delle equivalenze quasi sensate, il difficile è ricordarsele quando si fa l'addestramento.
  5. L'addestramento è molto macchinoso (ho fatto dieci righe di una colonna!), ma impara velocemente. Purtroppo molte lettere hanno delle imperfezioni, ma penso che questo sia un problema ineliminabile del libro originale (non ho ancora controllato le microdifferenze alle diverse risoluzioni disponibili). Un problema, non enorme, è che nel corsivo non sempre due lettere adiacenti sono due rettangoli separati, servirebbero dei parallelogrammi o dei poligoni liberi. Nei casi peggiori risolvo creando una legatura (ad es. "fi"). Vedremo dove mi porta la cosa. Non ho ancora controllato come salvare il dizionario ma penso che non sia difficile.
    • Il dizionario è disponibile: [9]. Quando smetto di lavorarci io può migliorarlo o usarlo qualcun altro. ;)
    • Sto cercando di capire quanto farne. Ho trovato la schermata per le statistiche della pagina (alt+invio) che dà il numero di caratteri incerti per la pagina, ma nulla, nella documentazione, per il complesso del documento tranne che nelle "hot directory" dei "task automatici". Per esempio, riconoscere metà di una pagina col 12 % di caratteri incerti li ha ridotti al 7 % su quella pagina e dal 10 al 9 in un'altra. Probabilmente vale la pena di passare una giornata o due a fare l'allenamento dei caratteri su una dozzina di pagine.
  6. Analogamente, FineReader è un po' semplicistico e non si aspetta parole e caratteri latini e greci in un libro in italiano, ma ovviamente il nostro dizionario ne è pieno. Ho aggiunto una marea di caratteri al dizionario italiano dall'editor di lingua e questo dovrebbe aiutare, ma in realtà quello che mi serviva era soprattutto l'addestramento di cui sopra.
  7. Secondo te, una volta che FineReader guadagna dimestichezza coi caratteri del mio libro, imparerà anche a riconoscere meglio le aree, ad esempio non spezzando a metà orizzontalmente una parola alta il doppio delle sue vicine? In alternativa o in aggiunta, esiste un modo per fargli capire come deve riconoscere le aree? Ho visto che si può salvare un modello di aree, ma sospetto che sia una mera griglia, inutile nel nostro caso poiché ovviamente gli esponenti sono sempre ad altezze e di lunghezze diverse.

--Nemo 16:53, 28 ago 2013 (CEST)

Se hai trovato tutto questo in un'ora, quanto tirerai fuori da FR in qualche giorno? o_O
Mi avvilisce molto osservare come uno ci mette un'ora a capire quello che ci ho messo giorni e settimane. :-(
Cominciamo dalla difficoltà principale che ho trovato: il riconoscimento delle aree, in particolare delle parole con font diverso dal contesto, che spezza a metà. Disgraziatamente avviene in tutti i lemmi, uno per uno. Non ho trovato soluzioni, se non quella di correggere le aree a mano. Ho avuto l'impressione che sarebbe stato molto più veloce correggere il testo finale. Non ho trovato nulla che possa aiutare a risolvere o mitigare il problema. Ma non credere che abbia esplorato la documentazione a fondo.
Lettere adiacenti corsive: il trucco l'hai già trovato: addestrare a una "legatura".
Una volta che avrai salvato il documento in formato FineReader, si porrà il problema di come utilizzare, al meglio, il suo contenuto. Il bello è che si possono provare e riprovare vari modelli di esportazione; molto dipende da cosa vuoi farne, ma soprattutto da come pensi di rileggere per correggere gli errori OCR che saranno inevitabilmente molti. Come strategia penso sia quasi più importante decidere come organizzare la rilettura di quanto sia importante ridurre gli errori di OCR. Come procederai, e quale sarà il formato finale? --Alex brollo (disc.) 21:31, 28 ago 2013 (CEST)
Ci ho messo di meno perché mi avevi messo sulla buona strada! Proverò a studiarmi un po' meglio la documentazione. Per prima cosa voglio completare l'addestramento dei caratteri per almeno una manciata di pagine, per finirne due ci sono volute ore... --Nemo 22:55, 28 ago 2013 (CEST)
Avevo finito lo spazio sul disco e ho dovuto cancellare tutto e ricominciare daccapo, per fortuna l'addestramento dei caratteri l'avevo salvato. Adesso per farne mezza di pagina ci ho messo 40 min, sarò addormentato oggi o ricordavo male l'altra volta... La "buona" notizia è che separare le aree su tutte le pagine non serve a nulla e anzi sarebbe controproducente secondo me, perché si perde l'allineamento delle righe e non si capisce a che definizione si riferisce quale esponente (allora tanto vale non averli). Non sempre però gli esponenti vengono tagliati a metà, forse se riesco a fare abbastanza addestramento dei caratteri qualcosa di buono ne viene fuori. Mi ci devo mettere di buona lena oggi! (Ultimo giorno, poi dovrò ricorrere alle macchine dell'ufficio Wikimedia Italia.) --Nemo 15:46, 2 set 2013 (CEST)
Ulteriori aggiornamenti sopra. Se riesco, stanotte carico un DjVu e forse altro in archive.org oltre al dizionario aggiornato; l'allenamento lo dovrò proseguire successivamente. --Nemo 23:41, 2 set 2013 (CEST)

Da quando ho lasciato la casa del mio amico non sono piú riuscito a lavorarci, fra WikiLovesMonuments e altro; per fortuna Sannita si è offerto volontario, magari riusciamo a dividere un po' il lavoro. :) --Nemo 13:31, 3 nov 2013 (CET)

Wikimedia Indonesia[modifica]

Ho sentito da Siska e John vandenberg dei progetti di Wikimedia Indonesia per l'espansione delle voci di id.wikipedia e non solo. In pratica:

  • digitalizzazione di un'enciclopedia sotto diritto d'autore, messa in uno pseudo-Wikisource privato;
  • trascrizione a pagamento dell'intero testo;
  • parallelamente, concorsi di creazione di voci (con punti per ogni aspetto come immagine, fonti, interwiki ecc.) che hanno già creato parecchie migliaia di voci.

In alcuni wiki come w:min: la creazione di voci in massa è stata seguita dall'aumento del traffico e degli utenti attivi. L'idea è che attirare utenti attivi senza contenuto è probabilmente una battaglia persa mentre un innesto iniziale ("seeding") può funzionare. Vedi anche m:Category:Free Your Knowledge 2012‎ e http://www.wikimedia.or.id/wiki/Digitalisasi_Konten . Forse dovremmo fare qualcosa del genere? --Nemo 13:56, 23 mag 2015 (CEST)