Misapplied patches in 4.0.6-2ubuntu0.1 break reading and writing JPEG compressed files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
LibTIFF |
Fix Released
|
Unknown
|
|||
tiff (Ubuntu) |
Invalid
|
Undecided
|
Marc Deslauriers | ||
Trusty |
Fix Released
|
Undecided
|
Marc Deslauriers | ||
Xenial |
Fix Released
|
Undecided
|
Marc Deslauriers | ||
Yakkety |
Fix Released
|
Undecided
|
Marc Deslauriers |
Bug Description
The patches applied to libtiff 4.0.6 in 4.0.6-2ubuntu01 seem to break JPEG tiff read and write.
To reproduce:
$ tiffcp -c jpeg k2a.tif x.tif
(where k2a.tif is a simple uncompressed RGB strip tiff) appears to work. However, x.tif, the output, will now not read without warnings:
$ tiffcp x.tif y.tif
TIFFFetchNormalTag: Warning, ASCII value for tag "JPEGTables" does not end in null byte. Forcing it to be null.
JPEGLib: Warning, Premature end of JPEG file.
This was working fine until a couple of days ago, so I guess it's one of the most recent patches.
Some packages using libtiff seem to be broken too. For example, openslide, which uses libtiff to load jp2k-compressed slide images, is no longer working:
$ openslide-write-png CMU-1-Small-
TIFFFetchNormalTag: Warning, ASCII value for tag "JPEGTables" does not end in null byte. Forcing it to be null.
TIFFFetchNormalTag: Warning, ASCII value for tag "JPEGTables" does not end in null byte. Forcing it ... repeats 8 more times
openslide-
and x.png is not a valid PNG image. The test .svs image may be downloaded here:
http://
Changed in libtiff: | |
status: | Unknown → New |
information type: | Public → Public Security |
tags: | added: regression-update |
summary: |
- Misapplied patches in 4.0.6-2ubuntu01 break reading and writing JPEG + Misapplied patches in 4.0.6-2ubuntu0.1 break reading and writing JPEG compressed files |
Changed in tiff (Ubuntu): | |
assignee: | nobody → Marc Deslauriers (mdeslaur) |
Changed in libtiff: | |
status: | New → Fix Released |
Even Rouault on the libtiff mailing list has looked into this as well -- he says the cause is a misapplied patch.
Unfortunately i can't link to his mail as the libtiff mailing list archive index has stopped being updated, but I copy-paste his mail below:
-----------
Even Rouault <email address hidden>
to tiff, me
On samedi 4 mars 2017 18:51:20 CET <email address hidden> wrote: 0.6-2ubuntu0. 1.debian. tar.xz 0.6.orig. tar.gz patches/ *.patch; do patch -p1 < $i; done
> tar xf tiff_4.
> tar xf tiff_4.
> cd tiff-4.0.6
> for i in ../debian/
Actually to reproduce, you need to apply the patches in a precise order with
for i in `cat ../debian/ patches/ series` ; do \ patches/ $i; done
patch -p1 <../debian/
I've then compared the patched libtiff/ tif_dirread. c with the official one from CVS, and I understand now what happens in Debian/Ubuntu.
It appears that the following snippet
that in official libtiff is applied in the TIFF_SETGET_ C16_ASCII cases (line 5017 in HEAD) and in the TIFF_SETGET_ C32_ASCII cases (line 5194 in CVS HEAD) has been wrongly applied in Debian in the TIFF_SETGET_ C16_UINT8 case (line 5008) and TIFF_SETGET_ C32_UINT8 case (line 5180)...
This explains the warning about the JPEGTables...
Unfortunately "make check" in the Debian patched libtiff still passes, so they have some excuse. Not so surprised since the test suite is rather small.
Even www.spatialys. com
--
Spatialys - Geospatial professional services
http://