Hello all,

first of all: great software and forum! And I hope I am correct here, with my question (and maybe proposal).

I would like to know, if there is a possibility to achieve the following effect with current tools in Krita. And if not, whether it would make sense and is feasible to implement such a tool in the future.

The idea is about intuitively coloring greyscale drawings. Currently I would start by using the HSY mode with my brush, select a hue/saturation and start drawing over the greyscale image. That will keep the greyscale value as V in a HSV model and add the selected HS to get a HSV color. So far so good. BUT this result tends to become darker than the greyscale, because the human perception of a 100% saturated, 100% "light" (not darkened) red is not 100% light, but (depending on color space) maybe 30% grey.
Example: I start of with a 30% grey. I paint a 100% saturated red over it and receive in H0° S100% V70%. If want to make a perceptual greyscale from it, I would receive something like 49% grey (70% lightness value * 70% red value)

I think (not 100% sure) I refer to this effect described on wikipedia: https://en.wikipedia.org/wiki/HSL_and_HSV

A more perceptually relevant alternative is to use luma, Y′, as a lightness dimension (fig. 12d). Luma is the weighted average of gamma-corrected R, G, and B, based on their contribution to perceived luminance, long used as the monochromatic dimension in color television broadcast. For the Rec. 709 primaries used in sRGB, Y′709 = 0.21R + 0.72G + 0.07B; for the Rec. 601 NTSC primaries, Y′601 ≈ 0.30R + 0.59G + 0.11B

Or the other way around: if a pixel of the base greyscale image I want to colorize has value 0.7 (scale 0..1), this could mean that the target colored pixel is a 70% grey, or a fully saturated red with 100% value. Or something in between, depending on the saturation. Or a 100% fully saturated green with 90% value. I think this illustrates the issue best. Sorry if this is too confusingly expressed.

Now the question: given that I have a greyscale base image with 70% grey, I select a saturated red and paint on that grey. Is it possible that the program does not use take the hue 0° and keep the 70% lightness, but instead it recognizes that saturated red corresponds to a 100% saturated red and thus lightens the value to 100%.
If I took a saturated green with maybe 90% perceived lightness (just notional), then the value would not be lightened to 100% but somewhat less, so the perceptional lightness of green + value together appears like the 70% grey. Is this possible at present? Maybe the calculation does take too much time to be reasonably applicable.

Please feel free to correct me or ask if I am mistaken or unclear.

Thanks in advance for your help and advice,
Michael

I think it can be manually achieved after colorization by splitting the hsv channels, calculating the perceptional value (brightness)of the H and S channel, inverting it to get the darkness and add it to the value channel. But it would be good to have a tool/setting doing that in realtime. Maybe there is a setup of (filter)layers to achieve that? Does anyone have an idea? I'd be glad to hear it.

BR
Michael

Uhm, the 'color' blending mode is HSY where the bottom layer's Y is combined with the top layer's HS. I think that's what you are looking for.

Hello TheraHedwig,

thank you for the proposal. I suppose this is what I currently do, kind of. But it does not do what I intend.
The point I wanted to make, is that a saturated color itself has a particular lightness.

Practical example: If I have a completely saturated red (0°) image with value 100% and use the gimp function "desaturate" in brightness-mode, I receive exactly a 50% grey.
Now, the intention is to do the opposite. I take the resulting 50% grey image, choose the saturated red color and use the tool|mode to paint over it. When I do so in Krita, I receive R255, G72, B72. Well, that corresponds to 0° S72% V100%, which is not what I had expected, either. I guess that has to do with different conversion coeffs in Gimp and Krita?

But my actual intention was to get back to 100% saturated red form the 50% grey base color, which itself is the result of the conversion from red to greyscale.

No, the coeffs are the same. There's something slightly different going on.

say we have luma coeffs 0.2126, 0.7152, and 0.0722 (rec 709). So Y = r*0.2126+ g*0.7152+ b*0.0722.

Red is 255, 0, 0 in 8bit.

We normalise red to 1, 0, 0.

Luminosity = 1*0.2126+ 0*0.7152+ 0*0.0722 = 0.2126
Then for 8bit, 0.2126*255 = 54~ so 21%

So if gimp's desaturate turns red to 50% grey, then it's using HSL to destaturate. So you want to use the HSL's color blending mode instead.

Hello,

yeah, that makes sense.
I have checked GIMP again and after preparing a test image with 100% red (0°), green (120°) and blue (240°), I can confirm that the V100% converts to 50% grey.
If I use the luminosity mode, blue really converts to V7%, red to V21% and green to V71% (value).

Thank you very much for pointing that out!!!

The combination of 7% blue, 21% red and 71% green (+factions) sums up to 100% and represents the weighting of the color fragments. I've got that. But now I realize that this value of 7% is MUCH darker than the 100% saturated, 100% value blue is perceived (my personal impression). I would estimate that a bright, saturated blue rather corresponds to a 50% grey. What do you think, is that only me who thinks that 7% (almost black) is too dark to represent that blue?
Looks like this becomes more complicated and I have to invest more time in analysis. Maybe have a look at the lightness value of LAB format?

Thanks again for the clarification.

BR
Michael

Yes, 7% is too low, but this is because that percentage is not meant for a gamma corrected enviroment, but rather a linear enviroment: https://docs.krita.org/Gamma_and_Linear

It's not possible to make the blending modes work linearly, so it's best to switch to a 16bit linear space to get it working that way.

Hey Thera,

It's not possible to make the blending modes work linearly, so it's best to switch to a 16bit linear space to get it working that way.

I guess I have to take some time to compute what exactly you mean and how the a 16bit linear space will resolve the problem.

Again, thanks a lot to push me forward!

BR
Michael