Come integrare tecnologie di riconoscimento in un proprio software
Un'efficace implementazione di una soluzione di
lettura ottica è sufficientemente complessa,
molto più di quello che normalmente ci si
aspetta.
Chi ha necessità di utilizzare tale tecnologia di
solito sceglie prodotti già collaudati e pronti
all'uso che minimizzano gli sforzi e massimizzano i
vantaggi. I migliori prodotti di lettura ottica sono
infatti sufficientemente personalizzabili per poter
soddisfare la maggior parte delle esigenze.
Tuttavia, per particolari esigenze, può essere
necessario realizzare una propria applicazione in
autonomia: a tal fine è possibile ricorrere all'uso
di specifici SDK (Software Development Kit).
Concettualmente un SDK può essere visto come
una "scatola nera" in grado di processare le
immagini secondo le indicazioni impartite, senza
comunque la necessità di conoscere ed
approfondire i complessi algoritmi che sono alla
base delle sue funzionalità.
Praticamente un SDK è costituito da una libreria
di funzioni, di solito resa disponibile come DLL o
come oggetto COM/ActiveX, dalla sua
documentazione d'uso e da alcuni esempi nei
diversi linguaggi di programmazione, quali VC++,
Visual Basic, Delphi, VC#.NET, etc.
Gli SDK dunque agevolano e velocizzano non
poco la realizzazione del proprio progetto,
evitando di dover partire da zero e di scontrarsi
con problematiche già egregiamente risolte.
Ci sono kit di sviluppo che implementano
funzionalità di OMR, ICR, OCR, BCR, Deskew,
Despeckle, Black Border Removal, Imaging, Form
Identification, Form Allignment, Thresholding
Dinamico, etc.
Vista tale disponibilità di SDK, ad un utente
dotato di una infrastruttura IT capace di
sviluppare software, conviene dunque acquistare
un prodotto finito pronto all'uso o svilupparsene
uno in casa?
Non sempre è facile avere le idee chiare sulla
strada migliore da seguire! Entrambe le
possibilità hanno alcuni pro e contro, ma qualche
riflessione può aiutare nel fare la giusta scelta.
Per certi versi è un poco come prendere la
decisione se farsi un abito su misura piuttosto
che comprarne uno già fatto.
Un abito su misura potrà vestire alla perfezione,
meglio di uno già pronto, ma è pur vero che
prima che sia stato realizzato non si potrà
provarlo ad indossare. Similmente un prodotto
finito potrà essere visionato e testato prima di
essere acquistato così da verificare se e come
soddisfa le proprie esigenze, mentre un prodotto
da realizzare su misura, anche se sulla carta
rispecchia in partenza i requisiti richiesti, solo
dopo averlo realizzato si potrà essere certi di non
aver commesso errori progettuali od
implementativi.
Per farsi un abito su misura occorre procurarsi la
stoffa, i bottoni, la macchina da cucire, gli
accessori: per fare in modo che tutto l'occorrente
sia di qualità adatta ed in quantità sufficiente è
quindi necessario avere una certa dimestichezza
con tale attività. Similmente per realizzare un
applicativo di lettura ottica occorre procurarsi
tutti gli SDK che servono, senza trascurare nulla:
ad esempio anche se si devono leggere solo
caselle di marcatura non serve soltanto un SDK
che sia in grado di discriminare tra caselle piene o
vuote, ma serve anche un SDK che sia in grado di
gestire l'acquisizione delle immagini, la
correzione dello skew, la pulizia, l'allineamento
con il template di riferimento e fare tutte quelle
altre indispensabili operazioni che si danno per
scontate e forse non si notano neanche in una
soluzione di lettura ottica pronta all'uso.
Il costo di un abito già pronto è noto a priori,
mentre il costo di un abito su misura è stimabile
solo parzialmente a priori sommando il costo dei
tessuti, degli accessori e della manodopera:
quest'ultima infatti è ipotizzabile su esperienze
pregresse, ma è suscettibile di variazioni in base
alle capacità del "sarto" ed a fattori contingenti
ad esso legati. Similmente una soluzione di
lettura ottica pronta all'uso ha un costo
conosciuto in partenza, mentre per una da
realizzare su misura oltre al costo degli SDK e
degli altri strumenti di sviluppo, si dovrà valutare
anche il costo delle risorse umane necessarie per
realizzarla, che per ovvi motivi potrebbe essere
compreso in un intervallo anche molto ampio di
tempo.
Una azienda che ha la missione di realizzare abiti
su ampia scala può investire in ricerca e può
sfruttare competenze ed esperienze diverse per
arrivare ad un prodotto finito di qualità elevata e
privo di difetti, cosa che invece non può fare un
artigiano che realizza un abito su misura pur
disponendo di materia prima ed attrezzature
valide. Similmente una soluzione di lettura ottica
pacchettizzata è presumibilmente frutto di
ingenti investimenti che chi deve realizzare una
propria soluzione in casa non può permettersi.
Un abito pronto lo si può indossare da subito,
mentre uno realizzato su misura può essere
indossato solo dopo una lunga attesa: si devono
prendere le misure, si deve imbastire, si deve
cucire, si deve rimisurare, si devono fare aggiusti,
etc. Similmente una soluzione di lettura ottica
pronta all'uso può andare in produzione il giorno
dopo averla acquistata, mentre per una soluzione
realizzata in casa bisogna aspettare che sia
prototipizzata, codificata, sviluppata, testata,
corretta, etc.
L'ago della bilancia sembrerebbe quindi pendere
decisamente per l'utilizzo di soluzioni standard
pronte all'uso piuttosto che per soluzione fatte in
casa, pur ricorrendo agli SDK.
Ma chi dunque può essere interessato a
realizzare una propria soluzione da sé ricorrendo
agli SDK?
In prima istanza chi ha esigenze particolarissime,
per le quali non si riesca a trovare una soluzione
di lettura ottica standard pronta all'uso: proprio
come se si è molto in sovrappeso, o si hanno
braccia più lunghe del normale, o se si è
estremamente alti o bassi e non si riesce a
trovare un abito standard che vesta in modo
adeguato e si ricorre all'abito su misura.
In seconda istanza chi desidera realizzare un
applicativo per la lettura ottica estremamente
verticalizzato da non usare solo internamente ma
distribuire a terzi in grandi numeri, a meno
ovviamente di trovare un valido accordo
commerciale con un produttore ed agire quindi
come rivenditore.
Possiamo dunque concludere affermando che
solitamente risulta più vantaggioso utilizzare una
soluzione di lettura ottica standard pronta all'uso
e personalizzabile, piuttosto che svilupparsi una
soluzione in casa, pur ricorrendo all'uso di SDK:
sebbene infatti gli SDK siano indispensabili e di
enorme aiuto, non vi può comunque essere
certezza di costi, di tempi e soprattutto di
risultato nel realizzare applicativi complessi e
completi come quelli inerenti l'estrazione
automatica di dati da moduli e documenti.
