Translating a specific colour(-code) to a 0-->1 number: Colour Toning -> L*a*b blending

[Jade_NL (Jacques)]

My interest in setting up colour/toning schemes using Colour Toning, specifically the L*a*b blending method, has been rekindled by a recent topic and I’m running into something I’ve been wondering about:

• Is it possible to correlate a specific colour to a specific value in the colour curve IN section?

For example: If I have a colour, hex code #013950 (RGB 1, 57, 80 / HSL 197, 98, 16) and want to translate that to the 0-1 scale that’s being used, I now have to eyeball it and come up with ~0.574.

I do realize that the actual colour is a combination of both the colour and opacity curve combined. I am hoping that I can ignore the luminosity/brightness part and come up with a reasonable ballpark number to use.

EDIT: These schemes aren’t load-and-forget, but starting values, that’s why I’m only partially interested in the luminosity starting points. These obviously need tuning once they are loaded, but the colours present should stay and are the important part.

[Thanatomanic (Roel)]

I’m not entirely sure what you want… What do you mean by “curve IN section”?

Going from #013950 to RGB(1,57,80) assumes we’re dealing with an 8-bit value. The maximum value is 255, so the fractional values should be 1/255 ≈ 0,0039, 57/255 ≈ 0,224 and 80/255 ≈ 0,314.
You can do whatever you want with those values when you assume they’re encoded in a certain color space. Assuming sRGB and D65 primaries you can calculate, for example, the luminance lightness using this step from sRGB to linear RGB to XYZ followed by going from XYZ to Lab using the right matrix from here and then just keep the L*-value.

[Jade_NL (Jacques)]

@Thanatomanic

What do you mean by “curve IN section”?

Yeah, that part might not have been all to clear. Maybe this will help:

The number, 0.5407, is the one that corresponds with the above mentioned #013950. As you can see I use 5 colours based on this colour scheme:

What is that number 0.5407 and do the provided link(s) give me that one based on one of the three colour codes I mentioned in my first post?

Thanks, I’ll have a look at the links you provided!

[Thanatomanic (Roel)]

I’m now pretty sure these links are not very useful to your particular problem
Thanks for the video… I don’t have an immediate answer for you. I’m not sure where those exact numbers come from either or how they are mapped.

[Jade_NL (Jacques)]

@Thanatomanic

I’m now pretty sure these links are not very useful to your particular problem

I’m rather glad about that to be honest… Had a look and that is the kind of maths I’m not at all familiar with.

@Thanatomanic

I’m not sure where those exact numbers come from either or how they are mapped.

Not your fault, but that is one thing that sometimes bothers me: At times running into seemingly arbitrary number ranges. I’m sure there is a logic behind it, but not always easy to find (if at all).

Anyway: Thanks for taking the time/effort to have a look at this!

[age]

Could it be hue (from hsv) / 360 ?
https://www.colorhexa.com/013950

[XavAL (Xavier Bartol)]

To me, @age is right.

But to get the right number you have to know both:

• the color space those patches refer to
• the working profile you are using

Bear in mind that when using the Color Toning tool and adjusting by hand those numbers, both color spaces must be the same.

Your best bet would be following these steps:

1. check the working profile you will be using in your image (you can’t change it from the moment you use the Color Toning tool onwards), and make sure it’s the same as the one the color patch is encoded with
2. open the Gimp, create a selection or draw a square, open the foreground color selection dialog and enter the hexadecimal number there. Click Ok. Paint the square/selection with the new color.
3. with the Color picker, control-click in one of the rulers and drag into the colored square. Then in the Sample points dialog, choose HSV. The value you need is the Hue (H), including decimals. Divide it by 360. Copy the result.
4. go to RT: use or create a control point and in the Output (O) field, paste the calculated value (note the color is not an input, but an output color, that is, the color that will be added on top of your image).
5. done

Now a couple tricky points:

• make sure about which color space those hex patches refer to (usually they will refer to sRGB)
• if you need to convert a color from one color space to another (sRGB in the hex patch, to ProPhoto in your working profile), do it in the Gimp, between points 2 and 3 (paint in the same color space of the reference patch, and after that convert to the working profile color space). By default the Gimp should create new images in sRGB color space, but check it beforehand, just in case.

I really haven’t checked it thoroughly with that exact toning method, but it should work.

Hope it helps

EDIT: I’ve changed the color picker dialog with the color samples dialog, because it seems the color picker only shows sRGB values, no matter which color space the image is in.

[Jade_NL (Jacques)]

@age

Could it be hue (from hsv) / 360 ?

I gave this a quick try using the numbers in the above posted colour patch and the eyeballed colours I used in the L*a*b blending module and that doesn’t seem to work (as in: some aren’t even in the ballpark).

I also referenced a rather obvious one: Red (FF0000), which has a value of 1.00000 (or 0.00000 don’t know if 1=0 in this case) on the scale used in the module.

@XavAL

But to get the right number you have to know both:

• the color space those patches refer to
• the working profile you are using

I really do not understand why this would come into play at all to be honest.

The way colours are represented are, have to be, unique, this is true for all the methods out there if I’m not mistaken. I never heard anyone say that 255,0,0 is only true when using colour space X.

• “Red” → FF0000 / 255,0,0 / 16711680 / 53, 104.576, 40.000 / …
• “Turquoise” → 30d5c8 / 48, 213, 200 / 3200456 / 52.3870, 0.2351, 0.3476 / …

I don’t see how working profiles and/or colour spaces would influence that. You might decide to pick a colour that is outside of a specific, narrow colour space. It is important to realize that and its possible consequences but I see this as a side-note and not a basic part of trying to translate ColourX to a unique number between 0 and 1 that is used by the L*a*b blending module

If your monitor is calibrated or not isn’t even of importance here, assuming all is done on the same monitor. Other issues come into play though, that is for sure.

My search seems rather simple: Translate a unique known number into another unique number where both numbers represent the exact same colour.

Maybe this cannot be done in this specific case. I know of another case that, to my knowledge, doesn’t have an exact formula to go from one to the other: RGB (or similar) to Pantone (you can approximate it).

[XavAL (Xavier Bartol)]

@Jade_NL

I really do not understand why this would come into play at all to be honest.

Well, you don’t have to believe me. Just make a color toning of an image (whatever image and toning) and then change the working profile. You will see for yourself

The fact is that (0,255) is valid in any color space. It only has to do with the bit encoding (in this case 8 bits per channel)

BUT (255,0,0) in sRGB makes reference (is just a coordinate relative to some primaries) to a certain hue of red, which was chosen to be the sRGB red primary. And that red primary is not at all the same as the ProPhoto red primary hue. So (255,0,0) is NOT the same color in sRGB as in ProPhoto

Same thing happens with hex values, as is just another way of showing the relative coordinates

My bet is that RT sets just a relative coordinate in the O field, so when you change the primaries (the color space), you also change the color used while toning the image

Can’t add any examples as I’m not in front of my computer, sorry

Hope it makes more sense now

[Jade_NL (Jacques)]

@XavAL

Well, you don’t have to believe me. Just make a color toning of an image (whatever image and toning) and then change the working profile. You will see for yourself

This is not about (not) believing you. I think we might be talking about different things though.

@XavAL

The fact is that (0,255) is valid in any color space. […]
[…] Same thing happens with hex values, as is just another way of showing the relative coordinates

This part I understand: Colour spaces are different and if encodings/working profiles do not match from image ↔ program you get unintended/unwanted results.

I also know that all the ways of writing unique colours down are just numbers (R65536 + G256 + B*1 → long decimal number → short HEX number for example).

What I do not get is why this matters in my question about translating from/to a unique number.

This is RawTherapee, which has a default ProPhoto working profile, and no other software is being used. At this point I’m not even looking at the image itself, because it is of no concern at all at this point. This is the only thing that I’m looking at:

In this example those 5 colours are to be the base for a new, baseline colour scheme. Specific colours affecting specific shadows, mid-tones and highlights ranges.

Right now, if I come across an interesting colour scheme I want to try out (random one) I have to eyeball those colours when applying them. “All” I want to do is translate #E0BBE4/224, 187, 228 into a correct value I can use (the highlighted one in the above image).

I have tried to get a clue from the RawPedia section about this, but to no avail (might be saying more about me then about the page though )

BTW: Your participation is very much appreciated. It might turn out that I’m full of it and that all the stuff you mentioned is (very) relevant after all.

[XavAL (Xavier Bartol)]

I’m not at home right now…

Give me a few hours and I will add a few examples with relevant explanations, please

It is quite easy to understand, the moment you see it in images. And no, it’s not in Rawpedia. It’s one of the things I’ve learnt while writing the Spanish documentation

[Thanatomanic (Roel)]

FWIW, the relevant code for the processing based on the curve is found here:

Beep6581/RawTherapee/blob/8bf1098d7b00b936d711bb9baef7345611c23a83/rtengine/improcfun.cc#L4025-L4093

[Jade_NL (Jacques)]

@XavAL: Had another go at it to get my head around it and I think I get it now. I would appreciate it if, when time permits, you’ll explain it in your words one more time just to see if I have it right though.

I followed your GIMP steps, and after some false starts I had it working and noticed the differences in end-results depending on the colour space you are in. Took me a while to realize why the differences are noticeably bigger for some of the colours compared to others: I’m assuming this happens because the edges of a wide vs a narrow colour space are further apart, so colours in the middle have almost identical values, but the closer you get to the edge the bigger the difference get as well.

This would also explain why @age’s solution works for some colours, but not for others (if, like i did, one ignores the colour space altogether).

Very interesting and another reason why colours are hard to get your head around at times

[XavAL (Xavier Bartol)]

The best way to understand something is getting your hands dirty…

So let’s try again: first a sample image color-toned in RTdev.

Quite striking difference, in my opinion. The only thing changed between them is the working profile, shown in the image. Those are screen captures, so both images have suffered the same conversion to the display profile.

Note how different are all the colors, not only the most saturated. You can say the sRGB is mostly a desaturated version, but I can see different hues, not desaturated hues.

Now a simple explanation with it’s own flaw, that I will comment later:

This is a CIELuv graph, which shows colors in a more perceptual way than the traditional CIExy diagram.

Here I have hand-plotted approximately the same coordinates (RGB values) in both color spaces (smaller triangle is the sRGB gamut; bigger triangle is the ProPhoto gamut), and you can easily see how much different the resulting colors are.

The drawback of this example is that RGB values can’t be plotted in this diagram (nor in the CIExy diagram) straight away, as the RGB color model is three-dimensional, and the diagrams are just a 2-D projection of the real 3-D coordinates. So the points I have plotted shouldn’t really be that far away. But I think you can get the idea anyway.

The point is, no matter what the maths are behind the Color toning tool behavior, after you have applied some toning to your image, if you change the Working profile the colors of the toning also change.

Similarly, if you apply certain sRGB coordinates in an image where RT expects e.g. ProPhoto coordinates, you won’t get the hue you expect.

And almost everybody in the Internet thinks, works and talks in sRGB terms (even RT defaults to sRGB in several places), so most probably the patches and images you will find published all over the web will be encoded in sRGB, unless stated.

You may think that this is an RT bad behavior, but I truly think this is how it should work, but (a big but) it lacks some way of specifying to which color profile and to which color model the coordinates you enter pertain.

Hardcoding an assumption that all the custom coordinates will be given in sRGB, and then automatically convert them into the proper working profile would be flawed from the start, because that way you would never be able to use toning hues outside the sRGB gamut.

Hope it makes more sense now.

@Thanatomanic, sorry but I can’t understand what the algorithm does with the color values (the value entered in the O field). I only said what I think RT does based on «this is what I see, so this is what most probably RT is doing».

[Jade_NL (Jacques)]

@XavAL

Hope it makes more sense now.

Yes, yes it does!

Your reply also tells me that I did, at last, have the correct idea about how this works. You did fill in some of the blanks and uncertainties (hue / [de]saturation)

@XavAL

You may think that this is an RT bad behavior, but I truly think this is how it should work, but (a big but) it lacks some way of specifying to which color profile and to which color model the coordinates you enter pertain.

I didn’t think that RawTherapee implemented this badly, I do think that some info needs to be added to RawPedia about this. Especially were it concerns seemingly(!!) arbitrary number ranges. On the other hand: RawTherapee does have documentation, something that many FOSS projects lack

I’m not a developer, but the hard-coding statement (it being bad) does make a lot of sense.

I’ve been playing with GIMP, RawTherapee and working profiles and I think I’m going to opt for using GIMP and change the sRGB space to ProPhoto RGB when I need to reference specific colours so I can keep working in that much broader profile in RawTherapee (or do the convert to sRGB and colour toning step as the 2 very last steps in RT).

Anyway: Thanks you for the time and effort to explain this to me (you especially, but also the others, of course)!

[XavAL (Xavier Bartol)]

You’re welcome.

Just a note: please take into account that I have edited my first post, so instead of using the color picker, it’s better using the sample points.

Good luck!