[Bug-ocrad] Re: OCRAD project: library is needed

[Dmitry Katsubo]

Hi Antonio!

Thank you very much for your comments. I knew that there are minor
things, which we cannot see from our side. I am happy that test case has
shown the problematic places.

On 13.07.2010 21:21, Antonio Diaz Diaz wrote:
> As soon as you want. If the rc1 is ok for you, I can release 0.20
> tomorrow.

>From my side it would be nice if you accept into mainstream a small fix
for "clean" target in Makefile (should remove ocrcheck, as Debian
builder complains on that binary if it not removed). I send the complete
Debian package (see Makefile.in.patch inside).

Unfortunately, I cannot push the package to Debain repository, as I am
not Debian Developer. If somebody can help me to sign my PGP key, I can
look for a sponsor.

On 11.07.2010 14:27, Antonio Diaz Diaz wrote:
> Hello Dmitry,
> 
> Dmitry Katsubo wrote:
>> I expect that "N" in test cases 1 and 2 is recognized not worse then via
>> API. Also API recognizes "r" and "t", which may trigger false positives.
> 
> Recognition via Blob is giving "better" results because you are
> cheating, twice. :-)
> 
> First, Blob is supposed to represent a "blob of ink", that is, black
> pixels must be contiguous and must touch the four sides. By adding a
> white frame you have "enlarged" the Blob, but this can break the code.
> 
> Second, you have again "enlarged" the blob in line 107 by using "width,
> height" instead of "right, bottom". the correct code is:
>   Blob* b = new Blob(0, 0, width-1, height-1);
> 
> After correcting those two errors (see attached file), Blob and API
> results are the same. "N"s aren't recognized because they are too small
> (<10 pixels high), and short, thick slashes are often recognized as "r"
> or "t".
> 
> To solve the problem with the small "N"s, I have just released
> ocrad-0.20-rc1 which reduces the height limit for "N" to 9 and includes
> the function "OCRAD_scale". See an example of use in line 152 of the
> corrected test case attached.
> http://download.savannah.gnu.org/releases-noredirect/ocrad/ocrad-0.20-rc1.tar.gz
> 
> http://download.savannah.gnu.org/releases-noredirect/ocrad/ocrad-0.20-rc1.tar.lz
> 
>> When I change to OCRAD_greymap, I get the following result:
> 
> This is because in OCRAD_bitmap 0 is white, while in OCRAD_greymap 0 is
> black. You need to invert the values (see attached file) or pass invert
> = true to OCRAD_set_image. For a description of map values see ocradlib.h:
>    The format for each pixel depends on mode like this:
>    OCRAD_bitmap   --> 1 byte  per pixel;  0 = white, 1 = black
>    OCRAD_greymap  --> 1 byte  per pixel;  256 level greymap (0 = black)
>    OCRAD_colormap --> 3 bytes per pixel;  16777216 colors RGB (0,0,0 =
> black)
> 
> 
> Best regards,
> Antonio.


-- 
With best regards,
Dmitry

ocrad_0.20-1_i386.build
Description: Text document

ocrad_0.20-1_i386.changes
Description: Text document