2006.01.04 14:30 "[Tiff] tiffcp photometric issue", by Larry Sanders

2006.01.04 16:51 "Re: [Tiff] tiffcp photometric issue", by Larry Sanders

On 1/4/06, Rocky Pulley <rockytriton@yahoo.com> wrote:

I had this issue too. It's a bug in the windows viewer. All other programs that I used showed it correctly. I had a Tiff 2 PDF program that had the same bug, so my fix was to manually change that bit and then invert the file data before putting the tiff in my system. That fixed my problem with the viewer and PDF converter, though it does slow things down just a little for all the bit flipping.

This is pretty much what I thought, but it does beg one question - why does Microsoft's viewer obey the Photometric flag in the original, but not the tiffcp created tiff?

Also, this is less related to libtiff, but does anyone have any pointers on how I might cross-compile libtiff+tools for windows under linux?



Larry Sanders <lsanders@gmail.com> wrote: Hello all,

I'm using tiffcp to convert from lzw to g4. My original tiff is a multipage, black text on white background (MINISBLACK?). The created tiff using 'tiffcp -c g4 orig.tif new.tif' is white text on black background when viewed using 'Windows Picture and Fax Viewer'. It is not inverted when viewing with 'Microsoft Office Document Imaging'. Searching of this list produced a few posts about the the photometric setting which sounds like the problem.

My thought was that 'Windows Picture and Fax Viewer' is ignoring the Photometric tag. However that doesn't make complete sense because I can use tiffset to change the photometric on _only_ the source document. Specifically I can use 'tiffset -s 262 <0|1> orig.tif' to toggle back and forth. However, that has no effect on the tiff created by tiffcp. tiffdump verifies that the Photometric tag is getting set properly. This is a problem because it's also inverted in the 'windows previewer' (at least on the windows box I have here).

Can anyone point me in the right direction? I did look at the code, and didn't see any ideas there (other than the idea of just inverting on the data copy... which seems like a bad idea)