Photometric interpretation for Fax4 / 1-bit images

[197g]

The test image added in this PR has BlackIsZero and is decoded correctly, but the libtiff test image has WhiteIsZero and is decoded incorrectly.

Meanwhile ImageMagick 6.9.11 decodes both correctly, as does GIMP.

I also could not reproduce the issue with imagemagick reportedly writing broken files. Here's the output of convert input.png -depth 1 -compress group4 imagemagick_group4.tiff

imagemagick_group4.tiff

It has WhiteIsZero interpretation and GIMP and imagemagick both open it correctly while tiff crate inverts the colors.

It seems the photometric interpretation needs to be read and honored after all. Either that, or we're the only ones honoring it and THAT is causing bugs.

Originally posted by @Shnatsel in #229 (comment)

[197g]

Thanks for the investigation @Shnatsel, I went off the comment you had linked in the rebase. Should be a matter of switching true and false bits.

[fintelia]

Wait, is the problem just that we don't handle ColorType::Gray(1) in the invert_colors method?

[Shnatsel]

Oh, that sounds likely! Just gotta add a branch for ColorType::Gray(1) it that does *x = *!x;

And probably also add an unreachable!() to the catch-all case there so that it panics instead of silently doing nothing when hitting an unknown color type.

[197g]

Something is weird regardless. In the main branch we have fax34::Color::Black => true for the bitmask and an image with a photometric interpretation of min-is-black. That image never hits the invert block, but apparently decodes exactly as it should despite literally decoding black as max in the stream interpretation?