You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=423) [details] 2-band 1-bit uncompressed tiff test I've arrived here after following dependencies in R & rgdal, through GDAL. My apologies if this seems familiar to anybody. I've attached a test tif (2bands1bitlt.tif), which is a 2-band 1-bit uncompressed TIFF. I run tiffcp: tiffcp -c g4 2bands1bitlt.tif 2bands1bitltg4.tif tiffcp -c none 2bands1bitltg4.tif 2bands1bitltnone.tif The uncompressed files differ: tiffcmp 2bands1bitlt.tif 2bands1bitltnone.tif I can examine the files using R & rgdal, and the compressed version (2bands1bitltg4.tif) is the left half of the full version (i.e., the right half is all 0). The error is then unsurprisingly propagated into 2bands1bitltnone.tif. This is with libtiff-3.9.4 on Red Hat 3.4.2-6.fc3.
I forgot to mention that 1-band 1-bit CCITT-compressed TIFFs and multi-band 1-bt LZW-compressed TIFFs seem to work properly. I also forgot to set the importance correctly.
Created an attachment (id=424) [details] 3 band example I noticed that the amount of the original image that is conserved in the corrupted file is proportional to the number of bands. With a 1-band file, the CCITT-compressed output is entirely correct. With a 2-band file, only the left half is correct. With a 3-band file, only the left third is correct.
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.
