So in this sprite, I have < 200 total colors (around 185), and I am in RGB color mode. When I use this option here, it generates the correct number of colors, however I noticed something quite odd: NONE of the colors in my sprite are in the palette at all.
Notice in the bottom left how every single color (except the transparent Mask) has the pink “!” button to add a color that doesn’t exist in the palette yet.
I confirmed this when I switched my sprite from RGB mode to Indexed mode, and everything on my sprite hue shifted slightly. Whatever algorithm is being used for this button only seems to be kinda close and not quite as exact as I was hoping it would be.
Not sure if this functionality is intended, but it seems very much “not working properly” to me. In the meantime is there any better way to pull all the colors from my sprite into my palette without having to add them one at a time? Anyone know of any scripts out there that do that?
Are you sure your image has under 256 colours? The sprite portion of your screenshot has more than 256 colours, so it’d not surprising that Aseprite would struggle to generate an accurate palette. The highlights/shadows near where the gradient part meets the hand-pixelled end adds a lot of colours.
And doing so produces that palette on the left, of 212 colors. If there really were more colors than that in my sprite… wouldn’t it populate them accordingly? I’m not sure I understand what this button does then if it’s not simply grabbing each instance of unique color that exists on the sprite and adding them sequentially to the palette. If it doesn’t do that, then it seems I need to make a script that does. Up until this point I could have sworn that’s what it did, but please correct me if I got the wrong impression about it.
I think that is what it’s meant to do, but Aseprite has some issues creating and handling palettes larger than 256 colours, so the behaviour might not be correct when you’ve got images with too many colours.
Even the script will still cause issues since you’ll end up with a palette with more than 256 colours, I think xP I think your best bet would be to clean up the problem area (that soft black overlay towards the sides) and then generate the palette. You’ll probably end up with a better-looking image too.
It’s nothing to do with the amount of colours. I tried it with an image that doesn’t even have 256 pixels, never mind colours and NOT ONE of the colours selected is actually from the image, just as the OP says.
So in fact the feature doesn’t appear to do anything at all…it just grabs some quite similar colours…? Very odd.
Interesting. I wonder if perhaps Aseprite uses the image’s embedded color profile when displaying the image but a default one when creating the palette from it (or vice versa)…
Interesting. I wonder if perhaps Aseprite uses the image’s embedded color profile when displaying the image but a default one when creating the palette from it (or vice versa)…
Yes I think you could very well be right about that. Leastways it seems to be a legitimate bug since clearly it shouldn’t be doing that. I wanted to get all the colours from an image so I could use the shading option but if the colours all don’t match it’s not gonna work at all.
Hi there! The actual implementation of color quantization should use the exact colors if the sprite has less than 256 colors, and start lossing precision if there are more than 256 colors. Since v1.3 version there will be an alternative implementation with octrees.
Anyway @hasen if you could share with us at support@aseprite.org a sprite with less than 256 colors that would be great, we could check what is failing.
Losing precision means not one single colour is in the palette? Seems more like zero precision. So you’re saying it doesn’t work at all if the colours are over 256? The OP and myself have found that none of the colours chosen for the palette are in the image.
Does Aseprite have a way to count the colours in an image? Seems to me it shouldn’t make any difference how many colours there are since the precision shouldn’t drop to zero for over 256 colours anyway…?
The issue of counting colors and having 100% precision is a memory vs performance problem. When we create a palette from the sprite, Aseprite v1.2.25 uses a linear search to keep 100% precision when the image is lower than 256 colors (a linear search is the slower option). But after finding more than 256 colors, it starts using an histogram of RGBA values and then using a median cut algorithm to find a good set of 256 colors (the “good set” is highly questionable). Also the histogram is reduced in precision (5 bits for Red channel, 6 bits for Green channel, 5 bits for Blue channel, and 5 bits for Alpha) to avoid using a lot of memory (the best histogram would have 8 bits of precision per channel, that would be 4*256*256*256*256 bytes = 16GB).
In v1.3 we have added an alternative algorithm to match RGB values through an octree. This is still in beta testing phase.
In my first 2 hours of using ASESPRITE OP, but I had the same problem. It turns out that making the palette and applying it are different things. After you make the palette go to Sprite > Color Mode > Indexed and it will try to apply your 256 colors.
I was trying something similar to pixelate and colorize an original picture (and see how it turns out). After doing the above, I put the sprite back in RGB, reduced a few colors from the palette by hand that I didn’t think were necessary. This didn’t show at all in the RGB sprite. I then turned the sprite back to indexed, and back and forth.
