AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.12.15 04:30 "[Tiff] Q: Fax photometric", by Chris Losinger
2004.12.18 17:44 "Re: [Tiff] Q: Fax photometric", by Bob Friesenhahn
2004.12.18 18:40 "Re: [Tiff] Q: Fax photometric", by Joris
2004.12.18 20:58 "RE: [Tiff] Q: Fax photometric", by Bill Bither
2004.12.18 23:13 "Re: [Tiff] Q: Fax photometric", by Joris
2004.12.18 21:24 "Re: [Tiff] Q: Fax photometric", by Bob Friesenhahn
2004.12.20 13:34 "Re: [Tiff] configuring for JBIG", by Leonard Rosenthol

2004.12.18 23:13 "Re: [Tiff] Q: Fax photometric", by Joris

The question I have about this image is why does photoshop and some others read it "incorrectly" according to the spec but visually correct? Is the assumption that any CCIT RLE (1D) image that has PHOTOMETRIC_MINISBLACK actually encoded as "Min as White"? Or only with images encoded from this particular vendor (skyline tools)?

Anyone's guess is at least as good as mine; I haven't written Photoshop; I haven't even actually seen the image file you're referring to.

Only thing I do know is that compression method and photometric are independent (except that not all compression methods are physically suitable for all color spaces and such). MinIsBlack means 0 means black, and this is not changed by any particular compression method. Spec clearly says so.

Of course, while writers must write properly (0 means black for photometric MinIsBlack), you could try and compensate for a known bug in a reader, which is what Photoshop might be doing. For instance, if you know a particular software tag value indicating this particular bug, you could reverse the 0 and 1 interpretation in your reader. More sophisticated scheme might be testing a few lines for 0 and 1 frequency, and take the less frequent to mean black. Dangerous matter, of course, for obvious reasons. If bug gets fixed in particular software and software tag value remains the same, or if your bug compensating reader stumbles upon an image that is actually mostly black, you've got a problem. Even less sophisticated 'bug fixes', like interpreting *all* CCITT RLE encoded images as MinIsWhite even if they're MinIsBlack, shouldn't even be considered because it's clearly the absolutely worst thing to do, and might furthermore lead to bug propagation if it is done is something authoritive like LibTiff's RGBA interface (even though it is a bug compensation in a reader - kinda stepping on my own point now, but not really).

What could be a more useful reply to your question, is if you and other people post tagdumps of such MinIsBlack-but-not-really images. That way, we might be able to see a good way of identifying them, and maybe decide on a proper (not to broad) bug compensation in our own stuff (and maybe LibTiff's RGBA interface, though that is not for me to decide).

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be

Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html