Changing to another custom palette flaws

[kevincrans]

What I'm used to now is that when loading a custom palette any time, it won't apply until I select current, if that's accidentally alrdy selected before loading the image&palette, I change alpha Treshold for the same effect.

1. However, when loading the 2nd custom one, the button is still on current and changing the custom palette reverts to the previous one, even when locked. I either expect A. the whole image making a palette swap (like when u edit current palette) or B. make all pixels reselect the nearest value from the new palette (the proper one).
2. When loading a palette, all partial transparency gets omitted. I have to use pinta's transparency, which is also flawed for the tmi.
3. This is that Treshold works like a mask and I don't have the ability to add transparent colours to the palette.

You can test with this good looking web palette I made for a 8-bit mod:
top216.json

[steffest]

Hey! Thanks for testing dpaint.js :-)

1: Yes, I see your point. That's awkward.
I'll probably make a change that changes to the settings in the "reduce palette" don't auto-apply, but that there's a "apply button" you have to click, which will then also (re)take the current palette if the setting is set to "current"
(and maybe with an "auto-apply" option, becasue sometimes it's handy to quickly step through different settins and see the result instantly)

2: yes, that's a bit by design. Dpaint.js is targeted towards image formats for retro-systems like the Amiga and there is no real transparency there. You can paint transparent pixels if the brush is transparent, and have layers that are transparent, but a color itself doesn't have transparency. I don't think that will change any time soon.

3: Hmm.. I see. I my head, color reduction and alpha transparency don't go together (because you'll end up with more/different colors then you asked for) but I see you point. The "threshold" should be optional so that transparency can be retained. I'll put it on the TODO.

Thanks for the feedback !

[kevincrans]

True, I agree with your decision on 2. Not trying to convince you, but I alrdy use no other values for transparency than 0%, 33%, 66% and 100%. GBA uses 1-bit alpha for a reason (however, if it's 0, then all other channels are wasted, but that could be efficient for the hardware colours & not having to redraw flickering sprites).

[steffest]

Confirmed that nr1 is actually a bug - will be fixed soon.

[steffest]

The "apply" bug has been fixed.
I added an "apply" button to re-apply the color reduction with current settings and if the palette option is set to "current", it now always takes the currently loaded palette.

Next to that, the "Alpha threshold" is now a checkbox.
If not enabled it leaves the alpha layer alone, keeping the transparency.
I'm not 100% sure that color reduction is 100% accurate for transparent pixels, especially when dithering is involved.
Colors get surprisingly complex surprisingly fast when transparency is involved ...
I'll keep this issue open for further testing.

[steffest]

Ah, forgot to mention; you can test this on the dev version on https://www.stef.be/dpaint/dev/
The dev version loads the current development codebase, which might be unstable, but most of the time it's fine :-)

[kevincrans]

Thank you!