Re: RGB->HSI->RGB

"Hendrik Belitz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Have you already tried this with floating point values? Since the
conversion
> functions use real numbers, using fixed point / integer variables doesn't
> seem to be the best way here.  An exact solution to problem is not
> possibkle at all, I think (Just look at all those PI's in the formulas...)
> Also you should think about the fact if it's really appropiate to convert
> the image into another color space. In many applications its more useful
to
> create a HSI image from an RGB image and retain the original.

Thanks for the response.
Yes I do the intermediate calc's in fp but the quantisation involved in
going back to 3 bytes can still accumulate.
The problem is that in my app, the user can edit pixels in HSI and then go
back to RGB. Reversing these edits should leave you with exactly the same
rgb values but of course the quantisation means it doesn't always. I could
minimise the drift by only reconverting those pixels which were actively
changed but that doesn't fully address the problem.

>
> > I suppose one solution would be to use some form of look-up table and
its
> > inverse, but the number of permutations seems too large for that.
>
> I agree with that.

The algo' I'm using for rgb->hsi is based on a hexagon rather than a circle
so no Pi's are involved.
On inspection, it looks like this algo could be done using 255^2 look up
tables rather than 255^3. 255^2 x 1 byte tables might just be workable. I
need to look into it a bit more.

Thanks again
Pete