Problem mit verschiedenen Typen im RGB-to-HSL-Range Procedur

[Sinspin]

I had a few month ago the same thoughts in my mind, why not using this implementation or why not that.
Result is, i use now a version which is as close as possible to the original, since i need to convert both way.

The Single/Float values are confusing at the beginning. But they have an nice advantage, you get much smoother values than you would get with integer!
So, you should keep Single values, if you need to display them, you need to quantize the values.
For example for S with 100, for percent style Saturation. Or at least 360 for the color angle H-Hue, but 360 is by far not enough values for perfect color representation!

[neumimnemecky]

Thank you to all for replies. I am new to graphics topics, and I am on the very beginning. It is just my exploration. I am working on a program which should be able to locate text in image and possibly some easy objects like arrows/images. The program should work with images exported from video or GIF and try to correct some frames. As it is supposed there is just text or mostly the text alone and it is well visible to be recognizable, but I will detect only for such easy characters like T, I, J etc. Then I will move the images or parts of the images (copy from one image to another). So I will not do any image conversion. Now I prepare input params for the program, and the elements to be found are defined by H, S, L (or H, S, V) values + some tolerance or fuzzyness. In the image exported from AVI in very good quality, there is very good quality, but a small tolerance for hue needed.

I am not expert in math or programming, I just need to make program to correct some graphics in video captured during scrolling a website.