Re: [Bug-ocrad] 0.18-pre2

[Uwe Dippel]

On Sat, Mar 29, 2008 at 8:08 AM, Antonio Diaz Diaz <address@hidden> wrote:

>  > Any good reason, why you tried scaling at a factor of 2?
>
>  Well, it is the first thing I try when I find small or not well defined
>  letters, because many times improves things.

Interesting, thanks. The scaling by 2 gives a number of better
results. Unfortunately, the scaling done by ocrad has rendered a few
'l' (lower case L) into '}'. So I fell back to pbmpscale (N=2), which
seems to do a good job. But scaling really *is* a great advantage!

Does ocrad allow to set a 'dictionary' of valid characters? What I
mean, is like valid characters are uppercase, lowercase, digits,
punctuation, alphanumeric, or passing a string containing all valid
characters? In some cases, this can be used to increase the accuracy
as well. Like in our application, we use low resolution, but we only
need alphanumeric, '.', '_','-'.  Any ambiguity could fall back to one
of these.

>  > And still another one: is there a chance to scale with different factors
>  > for x and y? I am asking, since we are doing OCR on faxes, and 'normal'
>  > at faxes means 204x98 dpi.
>
>  Ocrad can't currently scale differently in both axes, and I can't
>  remember a case where this could help. But perhaps you could fin one. :)

See above. I have now inserted pnmstretch -yscale=2, followed by
pnmsmooth. It is still not optimal, but at least the ratio is correct.

Uwe