You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=348) [details] Tiff containing DotRange tag DotRange tag in the supplied DotRange.tif looks like: 50 01 Tag= 0x0150 01 00 Type= 0x0001 (BYTE) 02 00 00 00 Count=2 00 ff 00 00 00=0 ff=255 tiffinfo: The problem occurs with versions 3.9.1 and 3.9.2. If the DotRange tag is 0..255 (type=BYTE) tiffinfo displays: Dot Range: 65280-20 Versions 3.8.2, 4.0.0Beta4 and 4.0.0Beta5 display this DotRange correctly: Dot Range: 0-255 tiffdump: Shows this tag as: DotRange (336) BYTE (1) 2<0xff 00> This occurs for versions 3.8.2, 3.9.1, 3.9.2. Versions 4.0.0Beta4 and Beta5 show it as DotRange (336) BYTE (1) 2<00 0xff> tiffcp: Copies this DotRange tag to type=SHORT, but fills it incorrectly. The tag becomes: 50 01 Tag= 0x0150 03 00 Type= 0x0003 (SHORT) 02 00 00 00 Count=2 00 01 ff 00 0x0100=256, 0x00ff=255, so 256-255?? This occurs for versions 3.9.1 and 3.9.2. Versions 3.8,2, 4.0.0Beta4 and 4.0.0Beta5 create a correct new DotRange tag.
I think it is a tiffdump problem in 3.9 branch. I have made a few fixes so it should work correctly now. Best regards, Andrey
Fix works for tiffdump only, not for tiffinfo and tiffcp. Tested with cvs branch-3-9 (on 20100704): tiffinfo (with the supplied DotRange.tif test file): Dot Range: 65280-47 tiffcp creates a tiff with a 256-255 (type SHORT) dotrange tag.
Eric, I can't reproduce this bug on my side. Both tiffcp and tiffinfo from 3.9 work as expected. I need more info from you on this problem: building and execution environments, full command lines and full output of tiffinfo/tiffdump. Best regards, Andrey
Andrey, It looks like bsearch (in tif_dirinfo.c) is causing the issue. There are two DotRange entries in the table, one with TIFF_BYTE and one with TIFF_SHORT. The result depends on which entry bsearch hits first. If it finds the TIFF_BYTE entry you get the strange values. If it finds the TIFF_SHORT entry you get the correct values. Because bsearch is a binary search you'll never know which one is found first. In case TIFF_BYTE is found, _TIFFPrettyPrintField in tif_print.c expects two uns16's, but gets two uns8's. Just as a test I replaced bsearch by lfind which resulted in correct DotRange values shown from tiffinfo. Am I right? Kind regards, Eric
Eric, Thanks for nailing this subtle issue down. Your analysis is right, but not complete. There are four tags that should be handled separately from the other ones: TIFFTAG_PAGENUMBER, TIFFTAG_HALFTONEHINTS, TIFFTAG_YCBCRSUBSAMPLING, TIFFTAG_DOTRANGE. These tags have count >1, but handled inconsistently with other multivalue tags. Instead of TIFFSetField(tif, count, pointer_to_value_array) application should use TIFFSetField(tif, count, value_array[0], value_array[1]) for these four tags. The same is for TIFFGetField(). That is inconvenient, but we are sticking with that for backward compatibility. And this special case is not handled properly everywhere. Actually it is TIFFWriteNormalTag() that should be fixed, maybe some other places too. I will try to work this out ASAP. Best regards, Andrey
I have checked in the fix for tif_dirwrite.c in 3.9 branch. Please, test it in your environment. Best regards, Andrey
Andrey, Ran tiffinfo, tiffdump and tiffcp (built from 3.9 branch as retrieved from cvs on 20100706 23:30 UTC). These results looked fine to me. FYI: I only looked at the results, not at internal details/behavior. Noticed that tiffcp now keeps the DotRange tag type for this DotRange.tif image intact (TIFF_BYTE to TIFF_BYTE). tiffcp from HEAD (4.0) does not (TIFF_BYTE to TIFF_SHORT). Even the 3.9 branch tiffcp behaves different on different platforms now. I guess it depends on which entry bsearch finds (either TIFF_BYTE or TIFF_SHORT), that type is the type that is written. Thanks, Eric
(In reply to comment #7) > Noticed that tiffcp now keeps the DotRange tag type for this DotRange.tif image > intact (TIFF_BYTE to TIFF_BYTE). tiffcp from HEAD (4.0) does not (TIFF_BYTE to > TIFF_SHORT). Even the 3.9 branch tiffcp behaves different on different > platforms now. I guess it depends on which entry bsearch finds (either > TIFF_BYTE or TIFF_SHORT), that type is the type that is written. I think that is not important as we have correct behavior when reading and writing these tags. I am consider this one closed. Best regards, Andrey
Created an attachment (id=467) [details] tiffdump output from 3.9.4 and 3.9.5
This patch (cvs diff -r 1.13.2.2 -r 1.13.2.3 tools/tiffdump.c) appears to break...well, everything. Using the files in http://download.osgeo.org/libtiff/pics-3.8.0.tar.gz, I ran a regression, on linux (x86_64) between tiffdump from 3.9.4 and tiffdump from 3.9.5. The 3.9.4 version produced identical output as all earlier versions (modulo formatting changes) [*]. However, 3.9.5 gets, well, a LOT wrong. For starters: diff test394/quad-tile.rpt394 test395/quad-tile.rpt395 4,5c4,5 < ImageWidth (256) SHORT (3) 1<512> < ImageLength (257) SHORT (3) 1<384> --- > ImageWidth (256) SHORT (3) 1<2> > ImageLength (257) SHORT (3) 1<32769> But imagemagick's identify app reports: $ identify libtiffpic/quad-tile.tif libtiffpic/quad-tile.tif TIFF 512x384 512x384+0+0 8-bit DirectClass 209KB 0.000u 0:00.010 That is, tiffdump 3.9.4 got this correct; 3.9.5 is wrong. I've attached a tarball that includes the tiffdump output, for both versions, for all images in pics-3.8.0.tar.gz, along with a "diff" between them. The snippet above is just the tip of the iceberg. I suggest reverting this patch, and trying again to fix the original reported problem some other way. [*] I've been using this procedure as a regression test / smoke test for the cygwin libtiff distribution for years.
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.
