Since it’s impossible to fully index palettes with over 256 colors, it’d be a lifesaver if one wants to work with, for instance, the Sega Genesis palette, that has 512 colors.
hi, Switch_Z. you can have palettes with more than 256 colours. what i do is following:
- import palette i wish to use as gpl
- use FastBit colour picker
- often i also have a colour chart on screen to pick colours more quickly, something like this:
i load palette just to check if selected colour is indeed included and use WolftrooperNo86’s script for actual colour selection. if i feel like i want to pick colour more naturally, i pick it from colour chart and again check if that colour is in the palette. if it isn’t, FastBit checker can pick the closest colour for me.
since bigger palettes are very hard to navigate i believe this is the best way how to work with larger palettes we have now.
you can download gpl palettes for probably any hardware you wish (for example mega drive palette here). or optionally it is not hard to generate your own gpl palette by script (i use free program called processing for that).
Hi there @Switch_Z! I’m not sure but probably you are looking for an Indexed mode with 9-bit (or big as 16-bit). At the moment this is not supported, you can have a palette with more than 256 colors, but indexed mode only support 8-bit per pixel.
We thought about the possibility to handle indexed images with 16-bit per pixel, that could be an option in the future.
@dacap This is exactly what I meant, I apologize for not phrasing it correctly. And thanks for your notice! Looking forward for that to be a reality!
1 Like
@Olga_Galvanova @Ethan_Buttazzi And thanks for taking your time to reply!
well now i know this and i want it, also i tried it seems that even doing create palette from sprite it doest regonize i didt undestaqnd it feel like it gets the color but sligly different i dont know
see
i just picked a color from the screen and isn’t anywere on the palette it should have picked something.
edit: see this
now
the one on the palette is just slighly different
edit two:
after further investigation it became obvios that whatever algorith you use to pick colors from the sprite goes badomcaboncas after 256
even the palette gets wonky too that up
exacly 256 colors here
one more color and boom
thats a bug that should happen
@dacap this needs a fix as soon as possible dude like next patch
There is a fix for v1.3 using octrees for these cases where the image has more than 256 colors, but it’s not automatic by default (or not chosen automatically). Still thinking if it should be the default mode (it doesn’t work when the image has transparencies):
Probably it should be the default mode when there is no semi-transparent colors.
Why not add also method from my script for images with colors count <= 255. Or 1.3 it will be exact in this cases?
The main issue right now for sprites with less than 256 colors is the RGB → Indexed conversion. It’s using the 5-bit RGB cube which reduce the precision for the color matching if there are similar colors in the palette.
Octrees will work as the dictionary (actually better because octrees are faster and specially made for these cases).
1 Like
Just in case as a comment: Aseprite needs to handle all kind of images (sprites with few colors and big photos). So if some specific algorithm or data structure requires a lot of memory (or time) to finish to convert a big picture from RGB to indexed (e.g 4000x4000), the algorithm cannot be used because as it can easily produce a crash. Generally we need more generic solutions (instead of specific tailor-made solutions). (And just in case, there are several cases where Aseprite doesn’t handle big pictures correctly, e.g. RotSprite, we’ll be working to fix that too.)
well why dont you do this:
measure the pros and cons in each case the one that has more would be the default
ps: also cant you do an error catcher, and cancel a process if its will cause a crash in aseprite?
I’m just working on a way to use octree in almost all cases (I think the only case it cannot be use is when semi-transparent pixels are in the canvas or palette). But it will delay the v1.3 release.
When there are limited colors it will be better to use algorithm without quantization. Fixed hashmap with good amount of buckets should be enough to handle exact colors plus semi-transparent colors. Semi-transparent colors may be important too. For example, our rendering pipeline support semi-transparent palette entries for certain sprites (with TRANSPARENT blending mode) and it will be good to handle them natively. It can be added afterwards in 1.3.xx releases.