We could get rid of the atan2, sin and cos trigonometric functions and calculate A and B to create the 3D space coordinates by creating a linear HUE table in the color conversion we want.

RGB color space:

luma = lightness, and brightness.

hue = color components = red(0 degrees) to green(120 degrees) to blue(240 degrees) to red(360 degrees)

As you can see, there is only a transition between 2 of the 3 RGB color components each 120 degrees.

We can use this as our A and B components.

The first 60 degrees is where A is RED 255,0,0 to YELLOW 255,255,0

The next 60 degrees is YELLOW 255,255,0 to GREEN 0,255,0

This completes the transition in 120 degrees between A and B in 512 steps.

A full 360 degrees = 3 * 512 = 1536 HUE color combinations.

These are all the integer hue color combinations ( without the luma component).

1536 * 256 (luma values) = 393216 RGB color combinations, which is 2,34375 % of all possible 65536 chroma values.

Thus we need a factor to calculate all 65536 different chromas.

65536/1536 = 42.66667 ( forward )

1536/65536 = 0.0234375 ( backward )

CIE color space:

red (0 degrees ), yellow(90 degrees), green(180 degrees), blue(270 degrees) and red(360 degrees)

A full 360 degrees = 4 * 512 = 2048 HUE color combinations.

65536/2048 = 32.0 ( forward )

2048/65536 = 0.03125 ( backward )

Now we can get A and B from a table of 2048 values using the factor or create a table with 65536 precalculated values.

I think 2048 values which only need 1 mul will be faster than a 65536 values without the mul. ( smaller data cache )

3D space:

X = A

Y = B

Z = Luma = ( R*0.1762044 + G*0.8129847 + B*0.0108109 ) ; is the Y value of the CIERGB2XYZ tristimulus matrix.

"And we don't need to mess with negative values because every value is automatically translated to the first quadrant ( X+, Y+ )"

"And we also don't need to use compare instructions because the table is a power of 2, we can use the AND instruction"

This is as far as I understand the CIE 3D colorspace, beware, I could be wrong though.......