AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1994.02.17 16:23 "Fax images gets inverted (sometimes)", by Soren Pingel Dalsgaard
1994.02.17 04:14 "Re: Fax images gets inverted (sometimes)", by Richard Minner
1994.02.18 09:21 "Re: Fax images gets inverted (sometimes)", by Karsten Spang
1994.02.17 16:24 "fax inverted (cont.)", by Soren Pingel Dalsgaard
1994.02.18 09:03 "Re: Fax images gets inverted (sometimes)", by Karsten Spang
1994.02.18 15:44 "inverted fax", by Soren Pingel Dalsgaard

1994.02.18 09:03 "Re: Fax images gets inverted (sometimes)", by Karsten Spang

  1. having 0 bits black, 1 bits white and setting PhotometricInterpretation to MinIsBlack.
  2. having 1 bits black, 0 bits white (done by xor'ing all bytes in the image data area with 0xFF) and setting P..I.. to MinIsWhite.

Now both of these methods should produce the same image. But when we compare the produced tiff files the only difference is the PhotometricInterpretation. The actual compressed image data is identical. If you ever encounter two tiff files with the same image data but different PhotometricInterpretation it means that the one is the negative of the other.

The problem, as I see it, is the definition of fax compression. It tells the implementor how to encode 'white' and 'black' pixels. But Photometric Interpretation has nothing to do with how to compress the image and nothing to do with inverting the image before writing it. Fax compression should instead mention how to encode 0 pixels (white) and 1 pixels (black).

Maybe this should be addressed to the TIFF document maintainers (I'll have to look up their address in the TIFF 6.0 paper).

The question *is* indeed addressed in the 6.0 paper. Before you look up the address of the maintainers, take a look at page 50, which reads

   PhotometricInterpretation. An encoded CCITT string is self-photometric,
   defined in terms of white and black runs. Yet TIFF defines a tag called
   PhotometricInterpretation that also purports to define what is white and
   what is black. Somewhat arbitrarily, we adopt the following convention:

   The "normal" PhotometricInterpretation for bilevel CCITT compressed data
   is WhiteIsZero. In this case, the CCITT "white" runs are to be interpreted
   as white, and the CCITT "black" runs are to be interpreted as black.
   However, if the PhotometricInterpretation is BlackIsZero, the TIFF reader
   must reverse the meaning of white and black when displaying and printing
   the image.

As the client program does not look at compression tag to find the photometric interpretation, the correct way of handling this in a library like libtiff, is to always unpack "white" runs as zero bits. However, currently it does the wrong thing, according to the spec.

There are a lot of TIFF writers (and thus files) in the world that sets the photometric interpretation to min-is-black, together with CCITT compression, that doesn't really mean that the image should be inverted. However, I think that a correction for this should go into the application, not into the library.

Because of all the confusion about this topic, I strongly discourage the use of min-is-black with CCITT compression. BTW, for most images, i.e. images with little black on a white background, inverting the image will result in a poorer compression rate.

Karsten

--------------------------------------------------------------------------------
E-mail: krs@kampsax.dk                                      Karsten Spang
Phone:  +45 36 77 22 23                                     Kampsax Data
Fax:    +45 36 77 03 01                                     P.O. Box 1142
                                                            DK-2650 Hvidovre
                                                            Denmark