Remove legacy palette generation behavior from rgbgfx without -c

[Rangi42]

rgbgfx must generate palettes from the colors in the input image, unless -c was used; in that case, the provided palettes will be used.

If the PNG file internally contains a palette (often dubbed an “indexed” PNG), then colors in each output palette will be sorted according to their order in the PNG's palette.

Note that the “indexed” behavior depends on an internal detail of how the PNG is saved, specifically its ‘PLTE’ chunk. Since few image editors (such as GIMP) expose that detail, this behavior is only kept for compatibility and should be considered deprecated.

Currently some people have an indexed PNG with more than 4 colors, which only uses 4 of those colors. The legacy behavior of rgbgfx is to use just the 4 colors that are actually used, but keep their order from the indexed palette.

The problem with this behavior is that it means identical-looking input images may not give identical output. If image A uses four shades of gray and is encoded as 2-bit grayscale, and image B is identical but uses an indexed 4-color palette (and you don't know the order because most image editors don't make that info available), then image B will have a different 2bpp encoding than you'd expect from the usual sort-by-darkness rule.

This behavior should be removed. The -c flag is sufficient; users can specify the four colors they want, or edit their indexed palette to have just those colors.

[aaaaaa123456789]

A few notes:

• If an image's palette has more than four colors, but only the first four are used, -c embedded should just take it with no warning. This is currently the only "common" use case that I'm not sure would be covered by -c embedded. Rationale: many tools that support palettes only support them at fixed sizes, which means that they are padded with dummy colors that the image doesn't use; there's nothing to warn about in that case. (If the image actually uses colors with indexes above 3, it should fail to convert.)
• If an image uses only four colors from the palette, but not the first four, the warning could say so. This would tell users what to fix in order to make their images work. (Basically, reorder the palette or use a different palette-generating method.)
• Keep in mind that there are use cases where the actual indexes used for colors are relevant. As far as I can tell, there's no way currently (as in, up to v0.5.2) to tell RGBGFX to use only colors 0, 2 and 3. Embedded palettes should allow this.

[Rangi42]

-c embedded currently complains if your indexed palette defines more than four colors with -c embedded, even if you only use #0-3. The rationale is that if you're manually controlling the embedded palette, you can presumably make it have just four colors.

And yes, -c embedded will work even if you don't use all four of the defined colors; their indexes will be preserved.

[aaaaaa123456789]

-c embedded currently complains if your indexed palette defines more than four colors with -c embedded, even if you only use #0-3. The rationale is that if you're manually controlling the embedded palette, you can presumably make it have just four colors.

MS Paint will be happy to prove you wrong, and so will many other tools. This is just punishing users.

[pinobatch]

"if you're manually controlling the embedded palette, you can presumably make it have just four colors" is true of some tools and not true of others. For example, when using Pillow (Python Imaging Library) to save an indexed image, it's not quite obvious how to make it write a palette with fewer than 256 colors; you have to call PIL.Image.Image.save() with a PNG-specific keyword argument that doesn't apply to BMP, GIF, or other indexed formats that Pillow can write.

[Rangi42]

Please continue discussion of whether unused extra colors should be supported in #1064.

So far it sounds like we're in agreement that the legacy behavior of "rgbgfx without -c" should be removed, so that the input PNG's encoding will not affect the palette generated by rgbgfx.

[ISSOtm]

If the user doesn't specify -c, then they don't care about the ordering of colours, only stability across runs; and thus the encoding detail is irrelevant. The current behaviour is merely for compatibility.

[Rangi42]

Yes, but the current compatibility behavior does mean that identical-looking input images can have different generated palettes depending on this detail of their encoding, which may be surprising even if you don't actually care about the color order.

The only use case not already covered by -c embedded is if the input palette has more than 4 colors but only 4 colors are used, in which case rgbgfx 0.5.2 would output just those 4. #1064 will cover that, so the legacy behavior here can be removed.