Bug 2431 - Tiffcp "none" -> "jbig" fails, but "lzw" -> "jbig" and "zip" -> "jbig" succeeded
: Tiffcp "none" -> "jbig" fails, but "lzw" -> "jbig" and "zip" -> "jbig" succeeded
Status: RESOLVED LATER
: libtiff
default
: unspecified
: PC Linux
: P2 normal
: ---
Assigned To:
:
:
: migrated_to_gitlab
:
:
  Show dependency treegraph
 
Reported: 2013-03-30 19:04 by
Modified: 2019-10-01 14:19 (History)


Attachments
Tiff file that has compression scheme None (587.42 KB, application/zip)
2013-03-30 19:04, Timo
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2013-03-30 19:04:30
Created an attachment (id=501) [details]
Tiff file that has compression scheme None

I have a file tussaus_none.tif, which has Compression Scheme: None, as the
following tiffinfo reports:

# tiffinfo tussaus_none.tif
TIFF Directory at offset 0x68e48e (6874254)
  Subfile Type: (0 = 0x0)
  Image Width: 8787 Image Length: 6255
  Resolution: 1199.95, 1199.95 pixels/inch
  Bits/Sample: 1
  Compression Scheme: None
  Photometric Interpretation: min-is-white
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 6255
  Planar Configuration: single image plane
  Software: Adobe Photoshop CS4 Windows
  DateTime: 2012:04:24 03:27:30

When I try to change Compression Scheme to jbig, it fails:
# tiffcp -c jbig tussaus_none.tif tussaus_jbig.tif
JBIG: Multistrip images not supported in encoder.
tussaus_jbig.tif: Error, can't write strip 0.

This error is wrong because there is only one strip, which has 6255 rows. So no
multistrip.

If I change the Scheme first to zip:
# tiffcp -c zip -r -1 tussaus_none.tif tussaus_zip.tif

then jbig succeeded:
tiffcp -c jbig tussaus_zip.tif tussaus_jbig.tif

and the report confirms that:
# tiffinfo tussaus_jbig.tif
TIFF Directory at offset 0x25e70 (155248)
  Subfile Type: (0 = 0x0)
  Image Width: 8787 Image Length: 6255
  Resolution: 1199.95, 1199.95 pixels/inch
  Bits/Sample: 1
  Compression Scheme: ISO JBIG
  Photometric Interpretation: min-is-white
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 1
  Rows/Strip: 6255
  Planar Configuration: single image plane
  Software: Adobe Photoshop CS4 Windows
  DateTime: 2012:04:24 03:27:30

I tested also lzw as an intermediate Scheme and it succeeded also, so it seems
that problematic one is Compression Scheme None.

This bug is odd because all 81 tests passed, so there should not be this like
bug, but may be there is no test for tiffcp scheme:none -> scheme:jbig.

LIBTIFF, Version 4.0.3
Source: ftp://ftp.remotesensing.org/pub/libtiff/tiff-4.0.3.tar.gz
Platform: Centos 6.4 X86_64

Jbigkit is got this way:
# wget
"http://li.nux.ro/download/nux/dextop/el6/x86_64/nux-dextop-release-0-2.el6.nux.noarch.rpm"
# rpm -Uvh nux-dextop-release*rpm
# yum install "jbigkit*"

Package                   Arch        Version             Repository       
Size
===========================================
 jbigkit                     x86_64   2.0-3.el6.nux   @nux-dextop   54 k
 jbigkit-debuginfo   x86_64    2.0-3.el6.nux   @nux-dextop   421 k
 jbigkit-devel           x86_64   2.0-3.el6.nux    @nux-dextop   18 k
 jbigkit-libs              x86_64   2.0-3.el6.nux    @nux-dextop   106 k
------- Comment #1 From 2016-07-19 02:22:37 -------
The patch here seems to fix this:

https://web.archive.org/web/20160719070826/http://www.asmail.be/msg0054670467.html
------- Comment #2 From 2016-07-19 02:52:36 -------
On further testing, the patch by Yuriy M Kaminskiy (linked above) appears to
break *decoding* JBIG -encoded tiff files:

With the patch applied,  I can create jbig encoded tiffs using:

$ tiffcp -c jbig  in.tif jbig.tif

But the following then fails:

$ tiffcp -c g4 jbig.tif g4.tif
------- Comment #3 From 2019-10-01 14:19:53 -------
Bugzilla is no longer used for tracking libtiff issues. Remaining open tickets,
such as this one, have been migrated to the libtiff GitLab instance at
https://gitlab.com/libtiff/libtiff/issues .

The migrated tickets have their summary prefixed with [BZ#XXXX] where XXXX is
the initial Bugzilla issue number.