Re: tiff:photometric and CCITT compression

Am 10.10.23 um 19:13 schrieb Bob Friesenhahn:
> On Tue, 10 Oct 2023, frechefuchs via Graphicsmagick-help wrote:
>>
>> an encoder should:
>>
>> 1. invert the image,
>> 2. compresses it with CCITT compression scheme,
>> 3. set PhotometricInterpretation to 1 (BlackIsZero).
> 
> You make good points (in the spirit of TIFF!), but it is worthwhile to 
> recognize that CCITT Group3 and Group4 compression represent ITU FAX 
> standards, which have particular expectations/requirements.
> 
> A typical expectation of FAX is some black on a mostly-white page. 
> According to https://en.wikipedia.org/wiki/Group_4_compression, 
> compression will be poor if this is not the case.

Sure.  And I'm not arguing with a personal use-case, but purely with the
TIFF specs.  For FAX-like content no-one should ever use BlackIsZero in
TIFF images, because, as you say, compression then becomes ineffective.

But for white-on-black content, in turn, CCITT compression is
ineffective.  A hypothetical use-case is digital reproduction of a
microfiche archive where content is often-times preserved in negative
colour.  If an archive chooses to digitize negatives as-is, that could
mean a substantial set of white-on-black images.


> Another expectation is that it should be possible to take the bits 
> from the TIFF file and feed them in prescribed order to a real FAX 
> machine and that the bits are transferred as expected.  FAX machines 
> do not understand "tags".

I wouldn't worry too much about BlackIsZero images failing here.  As I
said above, those should be the exception.


> It would be good if GraphicsMagick can write IETF RFC-compliant TIFF 
> files.  It likely does not do that now.  A prepared profile to enforce 
> all of the correct parameters would be useful.
> 
> I am not against making it possible to encode a TIFF file as you 
> describe (if libtiff itself will accept it),

Libtiff may be fine.  When creating images with IM and option
-define quantum:polarity=min-is-black, I get the expected output of
tiffinfo and with the image viewers I've tried I couldn't observe an
inverted image (ristretto, geeqie, gthumb, eog, eom).


> but am providing some reasons ([...], and likely not read correctly
> by other applications)
Yeah, you could perhaps do bad things, like providing an oddly
parametrized TIFF document that is in-line with the specs to someone,
hoping the recipient's decoder refuses to display it.  And later argue
about legal effectiveness of the delivered document.  TIFF is a can of
worms and certainly has a number of dark corners that are worth to
exploit^H^Hre. :-)

But again, WhiteIsZero is the default for bi-level TIFF images, and I'm
neither advocating to change that nor to build an automatism that tries
to recognize white-on-black images and set BlackIsZero without
user-interaction.  I'm worried about the current behaviour where GM
disables compression automatically, leading to unexpectedly large documents.

Best,
fux