Feature: Index color mode, (pallette changes can impact colors already painted)

[ikeofkc]

Feature request for canvas pallette adjustments so if you're working on something and you want to make different versions of it with different pallettes.

In the program aseprite it's implemented as an index color mode, but it could be implemented other ways possibly. See https://www.aseprite.org/docs/color-mode/?fbclid=IwAR3gex0l5wqaEh7QOEz-czv3681B7k6TRGDIsVRAWFMz7lsMvK9Y196zgIU#indexed

[novhack]

I would personally try to avoid locking a user with a specific color mode when he's first creating a new image project - like Aseprite or Graphics Gale does.

My take on this would be to add three new features to the current palette panel:

• Add a button to palette panel which enables/disables color indexing. If user enables it then everytime a color is changed in the palette the same color in the canvas would be changed accordingly - currently this might be slow with the current replace color algorithm, but once it's accelerated with C++ it could work fine.
• Add button to append all colors that are in the canvas but not in the palette to the current palette. This would allow users that didn't enable indexing to quickly switch from a normal mode to the indexing mode.
• Add a button/feature to merge palette colors when indexing is enabled - one common part for a lot of pixel artists workflows is when they reduce a number of colors in the picture and merge similar looking colors into one.

[ikeofkc]

I definitely agree that opt-in/enabling/disabling is the way to go. When i mentioned this in one of the reddit posts that was also my sentiment.

I'm coincidentally starting to learn Godot and GDscript for game creation reasons. I haven't done much coding outside of some python in blender, and appscript in google sheet. Already it's feeling very fun and easy to learn, so if this isn't implemented in a few months I may fork and study the code to see if I can try my hand.

[hsandt]

Currently following some pixel art class and one piece of advice is "experiment and try to change color palette regularly" which would be much easier with this feature.

To be honest, even on Aseprite where it's possible to do, it requires an extra step (generate color palette from Sprite - otherwise switching to Indexed color when using a different palette will mess up all the existing colors), and I often just use the Eraser tool + right-click to replace primary color with secondary color. To replace colors in a big area, I just set the brush size to something very big. But in Pixelorama, right-click is the same as left-click just using right tool so this doesn't seem to work. So for now I'll have to resort to Aseprite for color replacement, whether local or global.

[basxto]

I just wanna clear up some misconception here:

current replace color algorithm

You don’t replace colors in indexed images. Every pixel has an index and the color is more a rendering thing. That’s what makes these images so small. A 256 color palette only needs 8b per pixel, but can assign them 24b RGB colors, 32b RGBA etc.

Multiple indices can also have the same color. This is necessary when you want to swap palettes. For example you can have a palette with brown eyes and brown hair, with the exact same color used for both but different indices fore eyes/hair. When you load a palette with blue eyes and blonde hair, they’ll result in different colors. For clothing a white/black palette will have more duplicates than a blue palette because they’ll have issues to produce enough bright/dark shades. On hardware that used paletted images that means you could load the image data just once but display it with different palettes in different areas.

What produces even more duplicates is animating images with palette shifting. That’s a retro effect for hardware that used paletted images, because it’s a lot faster to manipulate a few colors of the palette than manipulating image data.

The background of this confusion is probably that "palette" is used to describe two different things. The palette of NES are the 54 unique colors this hardware was capable to produce. But the 16x16 background tiles could use one of four background palettes which again had four colors each. Those four color palettes are subsets of the 54 possible colors, but can be freely defined by the developer. The former palette is nice to produce retro images that use the NES colors, the latter is necessary to produce images that can be used in NES homebrew games.

Edit:
Maybe it’s best to have specific examples
These characters uses 4 color palettes. The First color is always black for the outline, the second color is for hair/clothing color, the third is skin color and the forth is transparent. Head and body could load different palettes to have a hair color that is different from the clothing. Different characters would load different palettes so not all have the same hair/clothing color.

For such objects one color of the palette has to be transparent because the pixels themselves only use indices. GIF can designate one index as being transparent and PNG can use the above mentioned 32b RGBA, which would even allow semitransparent shadows.