Good morning:
I would like more information on how image stretching is performed. The documentation says that an RGB blend clipping is performed trying to avoid clipping in high light areas, ‘as explained by the authors of the GHS script’ (I understand it is David Payne). But I haven’t found any information about it. Could someone explain to me what is done in the Siril script? I understand that if you follow David Payne’s process, you go to an HSL color space, separate and transform L, and join it back to HS and go to the RGB color space. First I would like to know if this is the case, and if so, where the color blending calculations referred to in the Siril documentation fit in. Thanks.
Hello, first of all, what script are you talking about? There is currently no official script using GHS stretching. Therefore, I’m a bit lost.
This document: Image stretching — Siril 1.2.0 documentation
In the Asinh transformation section it is said: “As rgb_original is an average of the 3 channels, one or two channel values will be greater than rgb_original and can therefore clip. This can cause color artefacts when bright, strongly-colored regions are stretched. In order to avoid this problem the RGB blend clipping algorithm is used. This was devised by the same authors as the Generalised Hyperbolic Stretch transforms…”
And a very passing and incomprehensible mathematical explanation is made of what is done with the 3 channels.
OK, but my question concerns this sentence. Currently, no script uses this.
Here, you need to read the authors of the PixInsight Script
Hi fjcaba, it’s true the Siril documentation is a bit terse in this regard. A more detailed explanation is available here:
The Siril implementation is the same as the RGBBlend clip type described at the link. This is used for asinh (because for the simple asinh stretch the colour channels are always linked) and for the luminance based colour models of generalised hyperbolic stretches.
The reference to a script I think was to the PI GHS implementation which was originally a script, but has since been rewritten as a plugin. Mathematically the Siril implementation follows the GHSastro design exactly.
The problem this solves occurs because, while the stretches themselves will never exceed 1.0, when applying them based on luminance you will have at least one channel where the pixel value is greater than the luminance. Particularly with bright and high contrast features like stars you can therefore apply stretches that drive those channels into clipping (values exceeding 1.0).
Siril doesn’t currently offer the other clipping models that the GHSastro code does, however if you want to perform an asinh stretch that stretches each channel independently then you can do so using the Generalised Hyperbolic Stretch tool selecting the independent channels colour model. (By setting SP to 0.0 the resulting stretch is a pure asinh stretch, although the strength parameter D is scaled differently to the stretch factor parameter in the asinh tool.
At some point I’ll get round to improving the documentation of this feature, but it will have to wait until I’ve finished my current work on Exciting New Stuff!!! ™ 
1 Like
Thanks for your answer ajeb78. From this I deduce that the problem could occur, in the case of Siril without a possible solution, if a color image is introduced (both in Asinh and GHS). But if we change the image to Lab* or HSL and work with the L channel we will transform the luminance and by reintegrating it to the other 2 channels (ab or HS), we will obtain the stretching without affecting the original chrominance (although to the human eye we will notice that there is a greater or lesser brightness, the tone and color saturation must remain stable). Finally we would change back to the RGB color space. This way there should be no clipping of any color channels. I’m right?
To an extent. I haven’t been thinking deeply about colour spaces recently but even if you decompose RGB to LAB, stretch L and then recompose RGB, you will get distortion of A and B when recomposing, because different hues have different maximum saturation that can be expressed in a given RGB colour space. If you want your colours to remain as perceptually unchanged as possible then the best options if you’re unsatisfied with Siril’s luminance stretch highlight preservation is decomposing to the most perceptual colour space you can find, probably OKLab though there are a few other possibilities, stretching L and recomposing. At the moment you would have to do the decomposition and recomposition in gimp though.
Thanks for the note about OKLab. Astronomical images are a very particular type of image. Actually, at the beginning of the processing, you should not be aggressive and the stretching should be gentle and iterative. So possibly the risk of channel clipping should not occur except in stars or certain bright nuclei of nebulae (such as M42), and knowing this, perhaps they should be masked or removed before continuing with stretching the rest of the image. But I think it is good to know this to avoid making mistakes or even to have processing options, for now outside of Siril, but available. For example, transferring what we discussed to Python should not be complicated, and knowing OKLab and its benefits compared to Lab, HSV and HSL thanks to your comment (and which I was unaware of), seems great to me. Thank you.