RE: [AD] Faster hsv_to_rgb()

["AE" <ae-a@xxxxxxxxxx>]

>> I have optimised hsv_to_rgb() by reducing the equasion used to calculate
>> the colour-values. This saves 3 multiplies, 3 to 4 adds/subtracts and
>> reduces by one the number of temporary variables needed. The code is at
>> this URL:
>>
>> http://www.xs4all.nl/~ellman/ae-a/tmp/hsv2rgb.zip
>
>Note that reusing existing variables is very unlikely to make any
>difference
>with modern compilers and generally degrades readability.

x86 machine language has a small number of registers so one less variable
will make a difference, especially if the function is called from another
function that uses lots of variables.


> +      x = v * s;
> +      y = x * f;
> +      z = v - x + 0.5f;

Considering that the above equasion has been re-arranged so much since what
it originally was in colour.c, is it really necessary to use z as a separate
variable now that x is no longer used? The compiler should be smart enough
to realise this, but I doubt that using 'z' instead of 'x' will increase
readability. The only way to increase readability is to include the original
code in comments so anyone looking at it can gain a clearer picture of how
the algorithm works.

Also, most of the Allegro functions that use floats have equivalent
functions that use fixed-point numbers, but the RGB<->HSV functions do not.
Should there be? The problem is that in Allegro, all functions with fixed
and float have float-versions with _f whereas the fixed versions have no
such postfix. If we re-name the existing RGB<->HSV functions so they are
rgb_to_hsv_f() and hsv_to_rgb_f() and write fixed-point versions using the
original names, it would break the API as programs would have to be
re-written to call the _f versions instead or use fixed-point numbers. The
alternative is to post-fix the fixed-point version with _f but then, it
would create an inconsistency in the API which is a bad thing. Or perhaps
the fixed point versions could be postfixed with _fixed. If it is decided
that there should be fixed-point equivalents, I'll volonteer to write them.

I also have code that does RGB<->HLS colour-space conversion. HLS is similar
to HSV except the HSV colourspace is represented by a single hex-cone
whereas the HLS colourspace is represented by a double hex-cone. That is, in
HSV, when V is 1 and the Saturation is 1, the colours will be at maximum
intensity, whereas in HLS, the output will always be white if L is 1, and
the colours will be at their most colourful when L is 0.5 and S is 1. Should
I submit that as well?


AE.