Near-black saturation value confusion

[dmstraker]

Set up a shape or fill layer you can change easily with RGB sliders. Get up the Info panel and set to show HSL.

Now:

• RGB=0,0,0, Saturation = 0%
• RGB=1,0,0, Saturation = 100%
• RGB=1,2,0, Saturation = 100%
• RGB=1,2,1, Saturation = 25%

In other words, a tiny change in RGB makes saturation go all over the place, which can be something of a pain. So if saturation is a measure of distance from grey, it seems it should have the same effect on alternative inter-RGB distances, yet the same gaps here give more expected results:

• RGB=50,50,50, Saturation = 0%
• RGB=51,50,50, Saturation = 1%
• RGB=51,52,50, Saturation = 2%
• RGB=51,52,51, Saturation = 1%

Which raises the question of where all the dark confusion starts. So trying just above zero

• RGB=10,10,10, Saturation = 0%
• RGB=11,10,10, Saturation = 4%
• RGB=11,12,10, Saturation = 9%
• RGB=11,12,11, Saturation = 5%

This makes sense, so it seems the chaos only happens very close to black.

I suspect this is an algorithmic thing. I am hence wondering:

• Wwhat algorithm is used
• Whether the same effect is seen in PS
• What alternatives there might be (such as in the Wikipedia page on colourfulness)
• What arguments there are for the various alternatives.

Thanks!

[thomaso]

12 hours ago, dmstraker said:

• RGB=0,0,0, Saturation = 0%
• RGB=1,0,0, Saturation = 100%
• RGB=1,2,0, Saturation = 100%
• RGB=1,2,1, Saturation = 25%

In other words, a tiny change in RGB makes saturation go all over the place, which can be something of a pain.

I don't know the answers but I wonder, how the Saturation (HSL) "can be something of a pain" with almost 'no' color (RGB)?
I even assume besides the saturation also the Hue value doesn't matter for this kind of black (~ no light).

You can compare RGB / HSL more comfortable at  https://wisotop.de/rgb-nach-hsv.php
There you might notice if you use only 1 of 3 RGB values > 0 , e.g. sliders set to RGB 1,0,0, then the HSL saturation gets set to 100% – but you can move the saturation slider between 0 and 100% without influencing any RGB value. Whereas it becomes quite different as soon a second color of RGB gets selected, e.g. 1,2,0 – then a tiny change of saturation from 100 to 99% immediately influences the RGB values. This immediate change maybe also caused by rounded values, since these samples appear to offer 8 bit only and lack in "decimals" (for instance you can't set Red = 1.5). For more precise values you would use 16 bit or floating point values.

If you are on macOS you can experiment the same with the ColorSync Utility, which not only allows floating points but additionally respects color profiles, which influence the color calculations, too (note in Affinity you can't have a document without color profile). In this sample you see the saturation setting not influencing the RGB values up to a certain value but then change all 3 channels and turn them from 'gray' to 'green' (which again may be influenced by rounded number / lack of decimals):

16 hours ago, dmstraker said:

Wwhat algorithm is used

I am not sure whether you ask for a specific Affinity algorithm? Some formulas, aspects and basic calculations for converting RGB to HSL are mentioned again on this website: https://wisotop.de/hsl-to-rgb.php
Or this RGB to HSL calculation at wiki: https://en.wikipedia.org/wiki/HSL_and_HSV#From_RGB
A more detailed step-by-step description: http://www.niwa.nu/2013/05/math-behind-colorspace-conversions-rgb-hsl/

[dmstraker]

Thanks @thomaso.

I suspect it's in the L<.5, S=(max-min)/(max+min) formula, if AP is using this, so:

min=0, max=1, S=1/1=1

yet a rapid change in S happens with small changes in values

min=1,max=2, S=1/3=0.3

The underlying issue seems to occur any time when min=0, as

min=0, max=n, S=max/max=1

In other words, what defines a 'saturated' colour in this case is not the colour range but whether the minimum is 0.

The defining algorithm at https://en.wikipedia.org/wiki/HSL_and_HSV#From_RGB catches the case where max=0 to prevent a div0 error, but does not address the issue where min=0.

To catch this, presumably some threshold needs to be defined, which may then also need some kind gradient to cloak sudden transition effects.

[dmstraker]

24 minutes ago, BofG said:

The values here for min & max in HSL are defined as [0,1]. Having max as 2 in your example is out of range.

I've not read fully through the rest yet, interesting topic though.

Fair comment. Maybe I was mixing 8 bit with 0..1 or it was just too early (insert appropriate excuse here).

But then it's ratios, so rescaling to 0..1 and still S=(max-min)/(max+min):

min=0, max=0.01, S=0.01/0.01=1

min=0.01,max=0.02, S=0.01/0.03=0.33

Mmm. Issue remains.

For interest I did a spreadsheet map of max vs min with saturation calc, 0.01 steps, and conditional formatting as attached, with red=1, yellow=0.5 and green=0 (also as jpg for visual). You can see the issue discussed down and near the left hand axis.

Practically, it causes problems when you create a saturation map from an image in order to mask other effects.

saturation calc max vs min.xlsx

[dmstraker]

4 minutes ago, BofG said:

I think I've got my head around the HSL scheme, I'm not quite sure though what part of it you are referring to as the issue. Can you dumb it down for me?

The calculation of saturation, and that at just off-black, saturation varies significantly. Hence if you are investigating a dark part of the image, the saturation values are unhelpful.