Description of Problem: tifftopnm ignores photometric interpretation when converting b/w tiff files, at least those compressed with CCITT group 4. Version-Release number of selected component (if applicable): netpbm-progs-9.14.1 is what is in Roswell, but the bug exists in seawolf as well. The bug does not exist in RedHat 6.2. I don't have anything between seawolf and RedHat 6.2 to test against, so I don't know when the bug initially appeared. How Reproducible: always Steps to Reproduce: 1. I am attaching to this report two tiff files: min-is-black.tiff and min-is-white.tiff. These tiff files are both CCITT group 4 compressed tiffs. They are identical except for their photometric interpretation. You can view that information with tiffinfo. Specifically, run tiffinfo on both files and diff the results. The photometric interpretation of a bitotal tiff image tells the viewer whether to interpret a 0 pixel value as white or black. If you view these files with ee, you will see that min-is-white.tiff has black text with a white background and that min-is-black.tiff has white text with a black background. 2. Convert these two files to pbm files with tifftopnm: tifftopnm min-is-black.tiff > min-is-black.pbm tifftopnm min-is-white.tiff > min-is-white.pbm Observe that both files show white text with a black background; i.e., tifftopnm ignored the photometric interpretation tag and treated both images as if they had min-is-black photometric interpretation. 3. Now convert the two files to pbm using imagemagick: convert min-is-black.tiff min-is-black.pbm convert min-is-white.tiff min-is-white.pbm Now you'll notice that the pbm files look identical to the tiff files from which they were converted. Actual Results: Convered above: tifftopnm ignore photometric interpretation Expected Results: tifftopnm should honor photometric interpretation Additional Information: You will find that other viewers than ee including xview, gqview, gimp, etc. all honor photometric interpretation. However, lots of Windows viewers don't. None the less, it is most definitely a bug to ignore photometric interpretation, and it is a bug that has been introduced relatively recently in pbm's life. Very odd given that it links against libtiff as do most of these other tools. Using tiffcp to create uncompressed tiffs doesn't affect this, so the problem is unrelated to the fact that the tiffs use g4 compression. If I have time I may try to fix this and submit a patch. I'm guessing it's going to be a simple fix. I am now attaching the two tiff files. They are very small.
Created attachment 29294 [details] tiff file with min-is-white photometric interpretation
Created attachment 29295 [details] tiff file with min-is-black photometric interpretation
Created attachment 29296 [details] patch to fix this problem
I was right. It was simple. I've attached the patch as a file, but I'm including it here as well. I quick glance through the code will indicate that the line of code I deleted wasn't doing anything. Usually when I find something like this, I report it to the "upstream" maintainers as well, but in this case, I don't know what to do because so many patches are applied. My patch is relative to RedHat's version; i.e., after rpm -bp netpbm.spec.
--- pnm/tifftopnm.c.qdist Thu Aug 23 18:29:32 2001 +++ pnm/tifftopnm.c Thu Aug 23 18:40:07 2001 @@ -501,8 +501,7 @@ case PHOTOMETRIC_MINISWHITE: for ( col = 0; col < cols; ++col ) { - sample = maxval - sample; - PNM_ASSIGN1( xelrow[col], samplebuf[col] ); + PNM_ASSIGN1( xelrow[col], maxval - samplebuf[col] ); alpharow[col] = 0; } break;
Fixed in the latest version, available via rawhide soon. Version: netpbm-9.20-1 Read ya, Phil