as designed HSL Formulae used instead of HSI

[dcarr]

Hello

I believe that the ChannelExtraction, ChannelCombination and PixelMath processes, as well as the cursor Readout Data, are using the Hue, Saturation, Lightness (HSL) colour model when the user selects the Hue, Saturation, and Intensity (HSI) colour model.

I understand there are differences in terminology when working with the various colour models, but from the best of my understanding, HSI is very different to HSL.

Documentation

I believe the formulae for converting RGB values to HSI values (esp. Si and I) provided in the PixInsight documentation for ChannelCombination may in fact be those that should be used for HSL. For example, HSI Intensity (I) should be (Red+Green+Blue)/3; however, the formula provided as (Max+Min)/2 is actually the formula for HSL Lightness (L).

Processes

I performed cursory checks on the ChannelExtraction and PixelMath processes, as well as the cursor Readout Data, using the attached test image, and they do appear to use the HSL formulae, not HSI. The test ‘single-color’ image has values Red = 0.90, Green = 0.75 and Blue = 0.30. Using ChannelExtraction in the HSI mode should result in a grayscale 'Intensity' image with a single value of 0.65. However, the resulting Intensity image has a value of 0.60, which would result from using the formulae for HSL.

ChannelCombination Process

I have not checked the behaviour of the ChannelCombination process when using ‘HSI’, but I suspect it is using HSL conversions.

Solution (?)

I suggest simply relabelling the documentation and process labels as HSL in ChannelExtraction, ChannelCombination, PixelMath and cursor Readout Data.

Actually, I find this a relief. HSV and HSL are relatively easy to convert to/from RGB. I find HSI a more difficult beast to work with, and I was perplexed by how HSI conversions were being implemented in PixInsight. Although the HSI/RGB interconversion formulae are well established, I believe the HSI gamut is much larger than that for RGB, so some combinations of Hue, Saturation and Intensity will lead to RGB values greater than 1.0 (>255 if you are using 8-bit values). In short, I believe ‘Intensity’ limits the valid ranges of saturation. My initial partial (and imperfect) solution when creating HSI sliders has been to rescale RGB values to fit into the range [0,1], leading to Intensity and Saturation sliders affecting each other (mostly as they should). Simply clamping also causes movements in Hue. Fun

 

[Juan Conejero]

I implemented our HSI color model this way on purpose to avoid a nightmare of confusion with color component identifiers throughout the entire platform. See, for example, the PCL documentation for the main RGB-to-HSI conversion function:

PCL: pcl::RGBColorSystem Class Reference

pixinsight.com

As the documentation says:

HSI is more often known as HSL. However, we reserve the L identifier exclusively for the CIE L* component (lightness) in PCL.

To see a good practical example of the kind of problems derived from using the HSL name instead of HSI:

PCL: pcl::RGBColorSystem Class Reference

pixinsight.com

The RGBToHSIL() function gives you the H, S, I (which is L) components plus the CIE L* component. We really don't want to deal with things like RGBToHSLL(), which is confusing, or RGBToHSLLStar(), which is ugly, or having to use LStar (and then aStar, bStar, cStar, hStar) everywhere. So, the best and cleanest solution was renaming HSL to HSI. This is a PixInsight idiosyncrasy that you should follow in your implementations. Simply call it HSI instead of HSL if you are in PixInsight.