Allow 1 mode images to be inverted

[radarhere]

Allows autocontrast, equalize, invert, posterize and solarize to support 1 mode images.

Alternative to #6033

[dov]

Is this always correct? My special case used the shortcut that if you interpret a 1-bit image as a 8-bit image and apply a linear inverse 8-bit lut on it then it is equivalent to inverting each bit. But this is not valid for a general lut. How exactly does image.point() work for a 1 - bit image?

[radarhere]

if you interpret a 1-bit image as a 8-bit image and apply a linear inverse 8-bit lut on it then it is equivalent to inverting each bit

Following you so far.

But this is not valid for a general lut.

So you're concerned that the methods other than invert won't be correct?

	L	1
autocontrast
equalize
invert
posterize
solarize

[wiredfool]

I'm not sure there's any point to autocontrast, equalize, posterize or solarize on 1 bit images. They're just fundamentally not 1 bit operations.

[radarhere]

In terms of the code, it is simpler to support those operations than to exclude them.

[radarhere]

How exactly does image.point() work for a 1 - bit image?

I'm not following this part of your question. It works in the same way that it does for an L mode image. A 1 mode image just happens to only have 0 and 255 values, and nothing in the middle.

[wiredfool]

Yes, but those operations aren't properly defined for 1 bit images. It's valid for invert, but that's it. You're getting the same image back in the other cases (except for solarize).

I think it's wrong to attempt these other transforms on a 1 bit image.

[radarhere]

Ok, I've removed support for the other operations.

[dov]

Great! I just tested and your Image.point() version it is actually faster than my translate() implementation. Before testing I thought it might be slower since the documentation for Image.Point() states that it does the lookup one pixel at a time. But that is actually not true for 1-bit images as they are processed the same as L images with the lookup table applying to eight bits at a time. As long as nobody assumes that in Image.point() they can use lookup table of all zero and one 255, "since 1-bit images only have gray levels 0 and 255", we're fine.

(On a C level invert() can be speeded up by 1. getting rid of the redundant lookup table and just doing a bitwise NOT and 2. doing the processing size_t (typically 64 bits) at a time. But I doubt any users of PIL.Image care about that.)