This looks like one of those 1 vs 0 math calculation oversights. I bet it’s an easy fix.
Have a project already open with any color palette, in this case DawnBringer32 -
Open a non-indexed image and select “Current Palette” for your palette choice.
The image will get indexed, but all your palette colors get offset 1 place to the right -
Did a little more testing.
Yeah you’re right - images with alpha have the issue. Those without an alpha mask I can successfully quantize using the current project’s palette. I only tested a few formats, though.
Of course, indexed images are not affected since they don’t need to be quantized when opened. They open and already have their own palette.
The issue is only with images that are both true color/non-indexed and non-flat/have alpha transparency.
Here’s a zip of 3 test images - https://drive.google.com/file/d/1N1fvUZgn8v_c0dHoIPcrm747PoNPkHrU/view?usp=sharing
Before trying to open these test images, already have a project open with a simple palette you can easily notice changes to, if unwanted palette changes do happen.
Test images in the linked zip get differing results:
"FORCES DEFAULT PAL_BMP_RGB_8bit_no transparency.bmp"
Open, using the “Current Palette” option and this file will not use the current palette. It gets forced to use the default palette. Is BMP format being treated differently?
"MESSES UP CURRENT PAL_PNG_RBG_8bit_has transparency.png"
Open, using the “Current Palette” option and this file will cause the palette to get changed - all colors offset by 1, as described above.
"DOES WORK AS EXPECTED_PNG_RGB_8bit_no transparency.png"
This one works as expected. It’s not indexed but I can open it and index it using the current palette no problem.
