w3c
Alternative palettes
https://github.com/Crissov/PNG-extensions/blob/master/aPLT.md
For indexed-colour images,
aPLTcan be used to define alternative palettes for the defaultPLTEchunk. The intention of this is to provide a simple method to display differently coloured variants of the same image which is frequently needed in sprite files.
choose an appropriate palette based on the name or external environment parameters
That sounds a bit vague, could you elaborate?
When I originally wrote this, I was dealing with Twemoji and Emojione graphics, so the idea was to support something like heart-emoji.png#palette=pink or princess-emoji.png#dark-skin.
I mentioned perhaps moving away from 79 byte limits in #25. I think whatever we decide on there should apply here as well. The last comment showed Media Fragments which is a good example of how these issues could be related.
Should the Palette name field allow Unicode? We ran into a problem with the iCCP chunk restricting to Latin-1.
I could imagine someone naming a palette something outside of Latin-1.
If we allow Unicode, should we perhaps mention how the Media Fragments document allows UTF-8 to Latin-1 translation via %.
If character encoding is to be relaxed then perhaps it should be done for tEXt and zTXt too, the reference implementation has never enforced Latin-1 encoding of the text fields and this has lead to compatibility issues with existing images: https://github.com/randy408/libspng/issues/123
The only sensible fix was to not enforce Latin-1 for those fields, discarding the chunk isn't ideal if libpng keeps it.
libpng does not check the text fields when encoding either: https://github.com/glennrp/libpng/blob/e19a576157911315c1e045fcd0e4dec3e80fba81/pngwutil.c#L1556
This could also be used to support slightly different images for light mode and dark mode.
An interesting idea, that would allow archival of palette cycling artworks, such as those by Mark Ferrari (here), etc.
Please also consider how this might be abused. e.g. concealing nsfw images, stenographic image text, etc.
In this case it should be an extension to APNG that would not update frame data for each frame but update its palette. If this extension is implemented, it also makes sense to allow to modify palette and frame data at the same time.
I saw some developers were complaining that APNG requires the same palette for all frames when GIF allowed separate palettes for each frame. This makes APNG not absolutely better then GIF. Such an extension would fix this issue.
