problem using leptonica on mac OSX 10.4 for tesseract

[GoogleCodeExporter]

What steps will reproduce the problem?
1. .Installed leptonlib-1.67
2.Compiled tesseract 3.00 and installed
3. Ran teserract

What is the expected output? What do you see instead?
Expected tesseract to produce the OCR result.  Got the following errors
Tesseract Open Source OCR Engine with Leptonica
Error in findTiffCompression: function not present
Error in tiffGetCount: function not present
Error reading file ./namefile

What version of the product are you using? On what operating system?
leptonica 1.67 on mac OSX 10.4; tesseract 3.00

Please provide any additional information below.

you can find additional information here:

http://code.google.com/p/tesseract-ocr/issues/detail?id=340#c0

Original issue reported on code.google.com by Oduss...@gmail.com on 4 Jan 2011 at 12:39

[GoogleCodeExporter]

The failure to read tiff files is expected, because
you must have libtiff.  This worked before because tesseract
had its own tiff reading code, but this is deprecated
in tesseract 3.00.

The fix is to download the tiff library so that it can be
linked when you build tesseract.

Original comment by dan.bloo...@gmail.com on 4 Jan 2011 at 7:50

• Changed state: WontFix

[GoogleCodeExporter]

Actually, I think this is a bug in the Leptonica autoconf file.  If you look at 
the output I've attached, you'll see that I do have libtiff.a, it does define 
TIFFOpen, but the Leptonica config still doesn't see that.  This is with 
Leptonica 1.68 on OS X Leopard.

Original comment by Bill.Jan...@gmail.com on 22 Apr 2011 at 12:50

Attachments:

• foo.txt

[GoogleCodeExporter]

The problem is that the check for libtiff won't succeed unless you specify 
-ljpeg and -lz on the test line.  It should read (in autoconf.ac):

AS_IF([test "x$with_libtiff" != xno],
  AC_CHECK_LIB([tiff], [TIFFOpen],
    AC_DEFINE([HAVE_LIBTIFF], 1, [Define to 1 if you have libtiff.]) AC_SUBST([LIBTIFF_LIBS], [-ltiff]),
    AS_IF([test "x$with_libtiff" = xyes], AC_MSG_ERROR([libtiff support requested but library not found])),
    -ljpeg -lz
    )
)

Original comment by Bill.Jan...@gmail.com on 22 Apr 2011 at 12:56

[GoogleCodeExporter]

Technically, this isn't Leptonica's fault. There's no reason to assume that 
libtiff will be built with JPEG or zlib support. To actually require this would 
be extremely bad practise. Who's to say what an arbitrary library may or may 
not require? As an example, Leptonica just added WebP support. Should we 
require that all users of Tesseract install libwebp?

If you had libtiff installed as a shared library then this would be determined 
automatically. Unfortunately static libraries carry no dependency information. 
This is why libtool archives (.la files) were invented. If you had installed 
libtiff from source then a libtiff.la file would have been placed alongside 
libtiff.a. I'm not very familiar with OS X, particularly from a developer's 
perspective. Where did your copy of libtiff come from? If you don't want to 
install it from source and your package provider does not install shared 
libraries or libtool archives then one workaround is to request these libraries 
explicitly when calling configure.

LIBS="-ljpeg -lz" ./configure

Don't assume I'm just being awkward here! Leptonica isn't alone as this is a 
common situation in open source software. libtool archives are the official 
solution as far as autotools is concerned.

Original comment by JerseyChewi@gmail.com on 25 Apr 2011 at 11:43

[GoogleCodeExporter]

> Technically, this isn't Leptonica's fault. There's no reason to assume that 
libtiff will be built with JPEG or zlib support.

Technically, there's no reason to assume that.  Practically, though, it will be.

>  ... one workaround is to request these libraries explicitly when calling 
configure.

> LIBS="-ljpeg -lz" ./configure

But what user would know that they would have to do that?  I do a lot of this 
stuff, and it took me a while to figure it out.

But I think you have a point.  The change shouldn't be to add "-ljpeg -lz"; it 
should be to add "$LIBS" to the check.  That way only libraries that have 
already been found will be on the line.

Original comment by Bill.Jan...@gmail.com on 3 May 2011 at 7:18

[GoogleCodeExporter]

I agree that it is important to avoid unexpected gotchas for the users. I have 
certainly seen the amount of mailing list traffic this can generate! I'll see 
what I can do but I'd still like to know where your copy of libtiff came from. 
Installing from source will give the shared library and the libtool archive by 
default. Package managers will probably always install the shared library.

Original comment by JerseyChewi@gmail.com on 3 May 2011 at 8:12

[GoogleCodeExporter]

Apologies for the crazy delay here. Trying to clear the backlog in my inbox. :)

I've found a good compromise. Instead of adding "-ljpeg -lz" to configure.ac, 
we can add "${ZLIB_LIBS} ${JPEG_LIBS}". This way, zlib and JPEG will be 
included if you have them but otherwise they are not strictly required. If you 
only have a static libtiff, it might fail if you explicitly disable zlib or 
JPEG support but you're not going to do that!

Dan, please merge this and mark this as fixed. Please also close #53 as that is 
a duplicate.

Original comment by JerseyChewi@gmail.com on 21 Aug 2011 at 8:28

Attachments:

• libtiff.patch

[GoogleCodeExporter]

Thanks -- much appreciated!

Patch applied.  Will go live for 1.69.

Original comment by dan.bloo...@gmail.com on 22 Aug 2011 at 5:34

• Changed state: Fixed

[GoogleCodeExporter]

Issue 53 has been merged into this issue.

Original comment by dan.bloo...@gmail.com on 22 Aug 2011 at 5:35

[GoogleCodeExporter]

When will 1.69 be released ?

I've added "${ZLIB_LIBS} ${JPEG_LIBS}" in configure.ac in this way:

AS_IF([test "x$with_libtiff" != xno],
  AC_CHECK_LIB([tiff], [TIFFOpen],
    AC_DEFINE([HAVE_LIBTIFF], 1, [Define to 1 if you have libtiff.]) AC_SUBST([LIBTIFF_LIBS], [-ltiff]),
    AS_IF([test "x$with_libtiff" = xyes], AC_MSG_ERROR([libtiff support requested but library not found])),
    ${ZLIB_LIBS} ${JPEG_LIBS}
  )
)

Then, I've recompiled leptonica (configure, make, make install & ldconfig), 
then recompiled tesseract (autogen.sh, configure, make, make install & 
ldconfig) and the problem persist:

# mtifftest /tmp/5f2408ff4cbe8ee92c976d1bde97f17d/page1.tif 
/tmp/5f2408ff4cbe8ee92c976d1bde97f17d/page1.txt
Error in writeMultipageTiff: function not present
Error in pixaReadMultipageTiff: function not present
Error in pixaDisplayTiledInRows: pixa not defined
Error in pixDisplayWithTitle: pixs not defined
Error in pixaDisplayTiledInRows: pixa not defined
Error in pixDisplayWithTitle: pixs not defined
Error in pixaDisplayTiledInRows: pixa not defined
Error in pixDisplayWithTitle: pixs not defined

# rpm -qa | grep libtiff
libtiff-3.8.2-7.el5_6.7
libtiff-3.8.2-7.el5_6.7

Please advice 

Original comment by alfonsov...@gmail.com on 27 Feb 2012 at 12:28

[GoogleCodeExporter]

I think 1.69 may be close so Dan might want you to try that instead. Otherwise, 
please post your config.log.

Original comment by JerseyChewi@gmail.com on 27 Feb 2012 at 12:34

[GoogleCodeExporter]

My leptonica-1.68 config.log, thanks in advance

Original comment by alfonsov...@gmail.com on 27 Feb 2012 at 12:55

Attachments:

• config.log

[GoogleCodeExporter]

configure:11561: checking for TIFFOpen in -ltiff
configure:11586: gcc -o conftest -g -O2   conftest.c -ltiff  -ljpeg -lz >&5
/usr/bin/ld: cannot find -ltiff

The RPM you mentioned does not include libtiff.so, just libtiff.so.3. It looks 
like you need libtiff-devel. Also, you don't need to set LIBS manually if 
you've applied the fix. This should only be set when absolutely necessary.

Original comment by JerseyChewi@gmail.com on 27 Feb 2012 at 2:39

[GoogleCodeExporter]

I've installed libtiff-devel, recompiled leptonica and recompiled tesseract... 
but the problem persist, althought the message are a bit different:

# mtifftest /tmp/5f2408ff4cbe8ee92c976d1bde97f17d/page1.tif 
/tmp/5f2408ff4cbe8ee92c976d1bde97f17d/page1.txt
Warning in getSortedPathnamesInDirectory: no files found
Error in fopenReadStream: file not found
Error in pixaReadMultipageTiff: stream not opened
Error in pixaDisplayTiledInRows: pixa not defined
Error in pixDisplayWithTitle: pixs not defined
Error in pixaDisplayTiledInRows: pixa not defined
Error in pixDisplayWithTitle: pixs not defined
Error in pixaDisplayTiledInRows: pixa not defined
Error in pixDisplayWithTitle: pixs not defined

Attached is the leptonica config.log, and here is some relevant configuration

There are some weird errors talking about a file ac_nonexistent.h that is not 
in the leptonica package, ¿maybe my compiler is more sensible?

Original comment by alfonsov...@gmail.com on 28 Feb 2012 at 6:06

Attachments:

• config.log

[GoogleCodeExporter]

This is a different problem entirely. It looks like it built correctly, at 
least in terms of TIFF support. Over to Dan I think.

Original comment by JerseyChewi@gmail.com on 28 Feb 2012 at 8:50

[GoogleCodeExporter]

I solved the problem by installing some missing components (yum install 
tcl-devel libpng-devel libjpeg-devel ghostscript-devel bzip2-devel 
freetype-devel libtiff-devel), the newer version of ImageMagick, and 
reinstalling Leptonica and Tesseract.

Thanks for the support

Original comment by alfonsov...@gmail.com on 7 Mar 2012 at 12:58

[GoogleCodeExporter]

Incidentally, I'm not sure 1.71 compiles without libwebp-devel installed. 
pixReadHeaderMem calls readHeaderMemWebP which is wrapped inside a #if 
HAVE_LIBWEBP in webpio.c. So adding to the list: (sudo yum install svn automake 
libtool gcc-c++ libwebp-devel libjpeg-devel libpng-devel libtiff-devel 
giflib-devel)

Original comment by mcfarlan...@gmail.com on 8 Jul 2014 at 2:07

[GoogleCodeExporter]

Please file a new issue about that. This isn't the first time, Dan needs to 
test building without any libraries. ;) Unfortunately I didn't get a chance to 
test it myself this time.

Original comment by JerseyChewi@gmail.com on 8 Jul 2014 at 12:07