You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=532) [details] hand-coded tiff file It appears that tiffcmp may be looking at bits that are not part of the image when comparing images that have extra bits in their data. The attached files, a.tif and b.tif, are both 1 row and 5 columns but are encoded with 4 bits per sample. This means that the data requires 7.5 bytes to represent, so 8 bytes are present in the file. The low four bits of the last byte, which are not part of the image data, differ. (I edited the bits by hand in a text editor.) If you convert these to some other format, e.g. convert a.tif a.ppm and convert b.tif b.ppm, you will see that the two ppm files are identical. However, tiffcmp says Scanline 0, pixel 4, sample 2: 8 6 The files a.tif and b.tif were constructed by hand. I converted a simple hand-coded eps file into an all black file with ghostscript using the tiff12nc format, then copied the file and edited the last four bits. The attached files c.tif and d.tif were originally part of a debian bug report of a false difference reported by tiffcmp. My own analysis of the problem suggested that the problem was in differences in the bits that were not part of the image file, so I created a.tif and b.tif by hand to test my theory. I'm also posting the original files so that they can be used for additional testing. I don't have an original source for the images, but I received them without any indication that they were sensitive in any way.
Created an attachment (id=533) [details] differs from previous attachment in unused bits
I can't attach the original files, but here is where I got them from: http://lasseb.tihlde.org/exherbo/tif1_a.tif http://lasseb.tihlde.org/exherbo/tif2_a.tif So these are what I called c.tif and d.tif, and the two attachments are a.tif and b.tif. It doesn't matter which is which.
I found the original source for the images. They were reported to me in https://github.com/qpdf/qpdf/issues/20.
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.
