Problem using HSL values

I am using Aseprite in Steam OS on a Steam Deck, for a long term art project that i have just begun. The project involves a lot of pixel art and animation. My first thoughts were to use Gimp, but I remembered having read your store page on steam store, and I really liked the concept behind the Aseprite program - plus the program had really good reviews (basically Aseprite fit my needs perfectly). so I bought the program and started to dig in.

My first task was to build a very large set of color palettes - Very specific numerical gradients - 36,000 colors in total. it is very important that these numerical values be accurate. So, I started off creating my color palletes by using the palette side bare, positioned on the left side of the Aseprite project window. At the bottom of that side bar there is a button labelled “Foreground color”. If this button is clicked it will pop up a new window that is used for manipulating the color spectrum using numerical input. I started to input my required values using the “HSL” tab in this window, and started to create my required palettes. I would input the values for a single color close the “Foreground color” window and move on to the neighboring swatch and enter the next values, but when I would go back to check the consistency of my work I began to notice a very big problem… the color values were changing on there own!

let me give you a for instance (the following is a real example that can be input under the “HSL” tab in the “Foreground color” window):

(this is a 19 color palette. the first set of numbers are the correct ones that I need to input, and the second set of numbers are the ones that aseprite changes my original values to)

25 95 5
25 95 10
25 95 15
25 95 20
25 95 25
25 95 30
25 95 35
25 95 40
25 95 45
25 95 50
25 95 55
25 95 60
25 95 65
25 95 70
25 95 75
25 95 80
25 95 85
25 95 90
25 95 95

(the following values are the ones that the Aseprite program gives back when the originally inputted values/colors are either reselected or reloaded)

25 92 5
24 96 10
24 94 15
25 94 20
25 95 24
24 94 30
25 95 34
25 95 40
25 94 45
25 95 50
25 94 54
25 95 60
25 95 65
24 94 70
24 95 75
25 94 80
25 94 84
24 96 90
24 92 94

As I said before, the Aseprite program very much resonates with my current artistic purpose, and I very much want to be able to use this program and recommend it to others, but at this point there is really no way for me to continue on here unless this problem can be fixed on steam within the next week or so, and I am also made aware of the developers intention to do so as soon as possible.

I will be paying close attention to this bug report, so please, if there is any intention to resolve this problem before the week is up, let me know so that I can continue on with my work in Aseprite.

Thank you for your time.

Hi @SonOfAGun, actually this is a known issue:

Basically the problem is that colors are stored with RGB values so some HSL/HSV information is lost in the RGB ↔ HSL conversion.

We could fix this using floating points to store RGB/HSL values, but the file format (.aseprite and others) don’t support more than 8-bits per component (24-bit for RGB, 32-bit for RGBA). This number of bits limits the information that we can store for each value, so if we could solve the problem on memory, after saving/loading the file you will have the same problem.

I’m not sure if there is a file format that can store HSL values directly.

I"m by no means a programmer, but it seems to me that the optimal solution would be to implement a locking system on each respective tab (RGB, HSV, HSL) where the lock would allow the user to select what format they desire to work in (default to RGB of course). Then the program could ignore all data concerning the other two formats making saving information much more simple.

I find it difficult to believe that there is no simple solution to storing HSL/HSV values. People have been creating art digitally, using these templates, for quite some time now. I cannot have been the first person to require accurate HSL values.

Hi @SonOfAGun. I’ve been trying a couple of apps and they have the same problem.
One of them does a UI trick: each R, G, B, H, S, L value is persisted with decimals (but only the integer part is displayed in the UI). If one of them is modified, all values are recalculated when changing to the other color space.

Anyway this is a trick, when the image is saved and then loaded into the workspace the colors are adjusted based on RGBA 8 bits per channel and eventually you will see that the colors used will not match the original HSL values chosen.

I think it’s not impossible to do something like what you mention, but it’s not standard.