Color namespaces and their implementation in Delphi or any other programming language
There are few color namespaces (color models). Some of them are better in one field but worse in other. Sometimes it happens that you need to convert some color from one color model to another. This is exact situation which has happened to me. So I decided to find a little bit more information about color models which I need to work with. I went to Wikipedia and Google and found a lot of useful information and few code snippets. That made me happy … but not for long L
Well, here is the situation: there is one color which I need to convert from RGB color model to HSL (HLS) and back but for all that I need all the work to be done with whole numbers. It seems that the task is not complicated. But I have been put in horror by the fact that all the versions of the source code I have found in Internet use different approaches to present color formats. Some represent RGB values as 0..255 but the other as 0..1; HLS values as H – 0..360, S и L – 0..1 or H – 0..239, S и L – 0..240 (e.g. Microsoft). I have seen few another modifications. Weird – isn’t it?
But this is yet far not the end of the story. Later I have been put into more horrible horror. Having tested some variants of a code I have discovered that returned results from the different versions of code almost completely mismatch, though the input was the same for all of them. Suddenly one interesting question came to my mind. Is it possible that Borland (or I should better say CodeGear) or Microsoft do not give us some solution for this, it would seem basic task? And I have appeared right! Both giants give us necessary routines. CodeGear gives us ColorRGBToHLS and ColorHLSToRGB respectively which can be found in GraphUtil unit. You can get access to the Microsoft functions ColorHLSToRGB and ColorRGBToHLS with the help of ShlwAPi unit. Hurrah! – I exclaimed, but again it was too early. Once again a great surprise expected me.
This time the thing was that at the first glance everything seems to work, and even looks like the truth, but it turned out, that as a result – this is just at first glance. The fact is that few colors in RGB model has been found which can be converted into HLS model without any problem, but it is impossible to get the same RGB color back from the HLS model. You can easily make sure in it. Simply run MS paint and enter these RGB values R=196, G=136, B=248 in the Select Color dialog. Remember HLS values. Now change the color to some other. And now enter HLS values which you remembered. Then compare resulted RGB values with RGB values you have been entering at the beginning. See?!
I have found a bug in the ColorRGBToHLS procedure which is in the GraphUtil and reported it in QC (QC#37436: GraphUtil.ColorRGBToHLS). It was rounding issue. I thought that this will save the situation but I was wrong. The ColorHLSToRGB routine was buggy too (QC#37572: conversion issue between ColorRGBToHLS and back ColorRGBToHLS (GraphUtil)) but this time the problem hides in formulas.
Conclusion:
- I still don't understand - is there any standard in this field? If yes, why nobody follows them?
- Don't try to remove those bugs I described above. The problem is not in code - the problem is in the formulas. Yes, yes ... I am saying that HLS color model is buggy!
- No matter which code version you will use (CodeGear, Microsoft, anybody else) - they all works wrong!
