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 <even.roua...@spatialys.com>
to tiff, me
On samedi 4 mars 2017 18:51:20 CET jcup...@gmail.com wrote:
> tar xf tiff_4.0.6-2ubuntu0.1.debian.tar.xz
> tar xf tiff_4.0.6.orig.tar.gz
> cd tiff-4.0.6
> for i in ../debian/patches/*.patch; do patch -p1 < $i; done
Actually to reproduce, you need to apply the patches in a precise order
with
for i in `cat ../debian/patches/series`; do \
patch -p1 <../debian/patches/$i; done
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
if( dp->tdir_count > 0 && data[dp->tdir_count-1] !=
'\0' )
{
TIFFWarningExt(tif->tif_clientdata,module,"ASCII value for tag \"%s\"
does not end in null byte. Forcing it to be null",fip->field_name);
data[dp->tdir_count-1] = '\0';
}
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
--
Spatialys - Geospatial professional services
http://www.spatialys.com
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to tiff in Ubuntu.
https://bugs.launchpad.net/bugs/1670036
Title:
4.0.6-2ubuntu01 has problems reading and writing JPEG compressed
images
Status in tiff package in Ubuntu:
New
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-Region.svs 0 0 0 100 100 x.png
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-write-png: Premature end of JPEG file
and x.png is not a valid PNG image. The test .svs image may be
downloaded here:
http://openslide.cs.cmu.edu/download/openslide-testdata/Aperio/
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tiff/+bug/1670036/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
