Values entered into the colorize module don’t always seem to be right. Primary colours seem to be right, but entering other manual values directly into the HSL sliders doesn’t create the colour you expect.
For example, if I use the global picker to sample a colour in HSL, then enter those values into the colorize module, putting the source mix slider to zero, the solid colour created is not the same as the one the global picker sampled.
Example here (the locked swatch is the one I entered into colorize):
I suspect this may be to do with where the colorize module is in the pixelpipe, but I still can’t get the right colour if I put the colorize module before the input color profile module.
Am I missing something really obvious here? Or is this module not acting like you would expect?
Thanks Todd, but didn’t work for me.
I sampled an orange with LAB and got 68, 46 and 75. I converted to HSL and got exactly the same values as if I had sampled in HSL = 30, 100 and 50.
After putting those values in Colorize and moving the module after Output color profile, the value I get is 39, 86, 43 in HSL (62, 21, 65 in LAB).
But even if it were to work, that would be really cumbersome to do and seems like the module isn’t working as intended (or at least not as needed).
Darktable’s picker, working, display and histogram profiles have a complicated relationship. If you set everything to Rec709, you get an exact match, but 270, 100, 50 is mapped to a bluish purple:
I’m actually experimenting with the colorize module for various things. One application for it is to use the divide blend mode to remove colour casts. If you have something in your image you know should be white, you can sample it, enter the HSL values into colorize, then use the divide blend mode to restore that colour to white. There are also various other things I want to try from my Photoshop days. Nothing critical, but it bugs me when a module doesn’t seem to behave the way I want it to
color calibration can deal with mixed lighting, if masked - just make sure you use it with CAT in all instances. Ignore the warning about white balance being applied multiple times.
Aurélien Pierre’s videos are rather technical, and not always well organised, but he is the author of those modules, so if you want the details, check him out.
Others (@s7habo, @Bruce_Williams, @Rico…) may be better at presenting how to use them.
Those two are modern modules. The left-over LAB modules may not be very reliable/actively updated any more.
Thanks @kofa, but that’s not working for me either. I’m still getting the discrepancy between colorize and the global color picker, and that display profile just messes up my colours anyway, so it’s unusable.
Interesting it worked for me or seemed to…not until I moved it after output though but I wonder what happens if you use the hex code as that can be input in the module….still the pipeline processing will always impact it as its not like using a layer in photoshop……
I don’t understand those screenshots. What am I supposed to see, with colorize turned off in both of them?
And yes, Rec709 linear is certainly not an appropriate display profile.
darktable’s pipeline sometimes requires one to set a weird display profile in order to see what’s going on in the pipeline (e.g., if your working space is Rec2020, setting the histogram and display profile to Rec2020 is needed to pick Rec2020 values directly from the pipeline, if you want to analyse that – which is rarely needed).
Yes, I was just showing how the colours have changed after changing the display profile so that I can’t even differentiate between shades of red, green, blue, etc. as seen by the main image. This would make it impossible to take any samples with this display profile.
I’ve done some more testing, and I’ve found that if I just have my histogram profile set to Linear Rec709 RGB (display profile kept at “system display profile” which I think is sRGB), then I get no discrepancy between the global colour picker and the colorize module.
The problem now though is that my global colour picker readings are not accurate with what they’re supposed to be:
So, changing the histogram profile would seem to just be a temporary workaround to get the colorize module to work for my intended application. Am I right?
I’m left wondering if this is all working as designed, or whether we need a change request to get the HSL values matching the global colour picker. This is not my area of expertise so perhaps there’s a perfectly good reason why the colorize module is working in a different space. But from what I can tell, the global colour picker is detecting the correct RGB values when the histogram profile is set to sRGB.
sRGB and linear Rec709 have the same primaries, but sRGB is non-linear.
Anyway: if you do this exercise to learn about darktable’s pipeline, maybe it has a merit. On the other hand, if you want to learn about correcting colour casts, I suggest that you don’t try to carry over techniques from Photoshop. Try color balance rgb and color calibration instead.
I’m doing this to experiment. I’ve been using darktable for several years and am very familiar with color balance rgb and color calibration. I just find it interesting to learn new techniques and to see what darktable can and can’t do. This issue with colorize is not very important, but it seems to be an annoying quirk. As I mentioned in my previous post, other modules work as you might expect, such as color lookup table, even though that’s a very LAB-based module.
@priort , I’m not sure what your latest screenshots are showing me. The solid colour that you created in colorize is not the same colour as you sampled even though the values are the same. As I see it, the global picker shouldn’t show a different colour after colorize has been added to the pipeline if it’s just a solid colour of the same luminance with no blending operation. Unless I’m misunderstanding what you’re showing me…?
I think just that, the pickers (global and in colorize) are selecting the same hue and sat from the same roi but the result of the module doesn’t seem to provide that if your histogram profile is sRGB. But for me as long as the histogram profile is linear 709 and not sRGB it seems to be working… Linear is the key and 709 so that the values you see are closer to srgb… for me it seems to work okay also if its linear rec2020 but you won’t get rgb values in the ball park of srgb if you switch the picker to rgb from HSL
Here is the color checker with an ROI colorize disabled.
Ok, I see what you mean. Yes, the pickers do pick the same values, but as you say, it needs to be done with a different histogram profile to get the intended result.
The experiment I was doing is not really important, so I won’t beat a dead horse. But it seems to me as if its inconsistent functionality. If I enter manual values into color lookup table and spot color mapping in color calibration, it works as expected, so just a bit annoying that colorize doesn’t.
I assume if I take any RGB/HSL values from a program outside darktable, I would encounter the same problem, so it’s not just an issue with colour pickers.
I imagine colorize is not a module that many people use, so this is really not a big deal.
So currently there is an issue raised by a user. He presents a png file that is a checkerboard of two colors… so at 100% you nicely see the color.
Now for the picker set to average you will get values that are done with simple addition of the two and then / 2 essentially… The picker I think might to some blurring etc but in any case the resulting color is rose as the math is done in sRGB… The use speculates that this should acutally be converted to linear rgb do the math and then back to sRGB to report the values… the result in that case is a light green. This of course now also impacts what could happen with scaling and previews.
I think Aureilen took a look over on his fork and argreed… The poster presented the same argument. AP noted that the scaling module came after the output profile and it should apparently be before or AP suggested even before filmic and then you could also introduce some sharpening behind it and before the output profile… So he made both color out and the final scaling modules visible so they can be moved pending a pipeline reordering…
I think the DT devs are looking at it as well but not sure where that will go…
AP has also remove the histogram profile. In DT there is an issue that because the display profile is positioned in front of the histogram profile then a bad profile can impact the data and for sure often the only way to see true clipping and gamut is to set the display profile temporarily to something like linear rec2020…your image looks like crap but now you don’t potentially have the display profile clipping the data before it gets transferred to the histogram profile… There are several threads around the issue on github and you can easily check your display profile by doing that exercise to see how it impacts things… AP has decided to remove it all together so his rebranded Ansel now goes from working to Display and when you export it exports in the selected display profile or what you set your export profile to. I am not 100% sure how he reworked the picker calculations… last I checked it was only partially working… rgb values were not showing only LCh and Lab… So I think he has some work to do…regardless there can be some nuance to how these values get delivered and some of this is what @kofa was alluding to I believe…
One of the major discussions came here… and you can see even then the conversation between the devs was required to come to an understanding of how it was all working…
This one sort of explains what I was trying to describe about checking your display profile and why…
It may have been tweaked a bit but I think it can still be an issue…
