HexColor: how the convesion works? what's the maths behind?

[Gounlaf]

👋

I'm trying to understand how the conversion from a "16bit" colors hexa (example: #FFFF000000000000) is converted on 8bits.

The HexColor class parse string, depending on the length, guessing if it's a 8bits form (short like #ff0, or long #ffff00) or 16 bits form. Then it rely on Quantum class to convert it ;

• 16 bits color on Q16 -> no transformation (ok)
• 8 bits color on Q8 -> no transformation (ok)

But:

• 8 bits color on Q16 -> I guess blank is still blank, so a FF will be a FFFF... ; but I don't get it for intermediate values
• 16 bits color on Q8 -> there is loose in precision here ; the amplitude of values is reduced... how does it works?

I'm not at ease with the math behind. It might be "dumb", but I don't get it. Is it just a cross-multiplication?

The reason of it behind is I have a Hex convert/parser built in in KT and I would like to use it instead of doing the whole parsing myself...
So, parsing and converting it to raw value is not a problem.

[Gounlaf]

Got it a bit deeper... It's a simple "ratio".
Why it's 128 & 257 involved? Is a "bitrick"? What I see is that shifting doesn't produce the same value as juggle with 128 & 257.

[dlemstra]

I used the same method as the one that was being used in ImageMagick. I don't know the logic behind this so that is why I asked GitHub copilot for an answer:

How would you scale a 16 bit short to an 8 bit char?

To scale a 16-bit short to an 8-bit char, you can perform a right shift operation by 8 bits. This operation effectively divides the 16-bit value by 256 (2^8), which scales it down to an 8-bit range. Please note that this operation may lose some data because it discards the least significant 8 bits. If you want to preserve more information, you might want to use a different scaling method, such as rounding to the nearest equivalent 8-bit value.

The operation that it suggested was (value16bit + 128) >> 8 and ours is slightly different (((value16bit + 127) / 257)) so I asked which one would be better:

(value16bit + 128) >> 8: This method adds 128 to the 16-bit value (effectively rounding up if the 9th bit is set) and then performs a right shift by 8 bits. This effectively scales the 16-bit value down to an 8-bit range. This method is faster as bit shifting is generally quicker than division, but it might not be as accurate due to the rounding.

((value16bit + 127) / 257): This method adds 127 to the 16-bit value and then divides by 257. This scales the 16-bit value down to an 8-bit range with a more accurate rounding, but it's slower due to the division operation.

So, if speed is a priority and you can tolerate some rounding errors, (value16bit + 128) >> 8 would be better. If accuracy is more important and you can afford a slower operation, ((value16bit + 127) / 257) would be better.

And because in the ImageMagick library we prefer accuracy instead of performance the latter one is used.

[Gounlaf]

So, it's some low level bit tricks 👌

Thanks :)