Luminosity Masks Review - A new technique I found and would like to see if these are accurate

I sort would like to know if these luminosity mask are correct or closer to correct with 16-bit integer LAB. I found out a new technique with the usage of threshold filter layer, and color to alpha with index filter mask applied using destination in blending mode. I can’t even confirm that they’re correct because of banding issue as my monitor can’t display 10-bit depth. Also, this technique is improved in terms of details over my earlier one I did way back then. These are LAB images.

What I want to know if the middle connects exactly. I cannot see it due to my monitor issue.

LAB Luminosity Mask.zip (10.2 MB)

On that note, why is MMM generated that way on the Pat Davis tutorial? Actually, there’s another form of middle masking where instead of brighter, it goes darker. That’s pretty easy to generate as all I have to do is manipulate the brightness for duplicated M group layer.

Also, from my finding, the middle of MM, and MMM are apparently shifted. I tried to get super closer to the GIMP results.

1 Like

@Reptorian For the second part of your post, check out Generating mid-tone masks. In general, this method of generating masks should work with any grey scale image. I often use L* as a starting point rather than luminance.

I know of that thread. Upon trying to look at histogram, it seem like the M is where it should be. The brightest is right at the middle, and the others go all the day to dark.

I’m using Krita, afre. The MM, and MMM seems just about right in the histogram. But, I’m more worried about the center of the gradient part of the image.

These layers are generated with clone layers and a bunch of adjustment layers/masks. So, all I need to do is copy and paste, and these masks are automatically generated.

I went back to the mid-tone masks again. Since your TIFs crash GIMP, I opened them using PhotoFlow and converted them to sRGB TIFs. Then I did a threshold to keep only the highest values, cropped half way along the gradients and finally stacked the gradient halves from M to MMM.

Notice that none of the white bars are centered. M’s is to the left. MM and MMM’s are to the right and thus chopped off.

I believe that the M should be fine for the LAB form as each of the half are only the L channel, and the other half is essentially the flipped version of L channel. I used threshold to place them in the middle. It is slightly shifted. The other middle masks was calibrating to based from what I see in GIMP ones, but if GIMP ones are the middle, then gonna put it in the middle. I would test to see if RGB method is different here, but there’s lightness channel just below alpha in color adjustment filter.

Seem like I would need to calibrate if I want it close to RBG middle. Is RGB middle the true “middle”? How do I know the middle is the middle based on data?

I looked up the answer and it has something with logarithmic perception. In the case I would use a different gradient base. I did not used a simple transition of black and white gradient. I used one where the middle gray seem to be in the right place.

@Reptorian The halves are not in the middle. The only reason that I converted LAB to sRGB was to open the TIFs in GIMP. With G’MIC, I simply examined the L* channel and have made the following observations.

  1. The gradients aren’t symmetrical. More sleuthing would reveal that they are 1536px in length so halfway would be 768-769. M’s center is at 717, MM 865 and MMM 795.

  2. Each gradient step is smooth but does not have the same width! Values are stretched for viewing convenience:

  3. a* and b* channels aren’t symmetrical either, respectively. This is MM a*; values are stretched for viewing convenience:

1 Like

I tested the threshold idea destination in idea again and I made a new gradient by hand. The width of these images is 1030, which means the middle should be at 515, and which it is. I’m not so sure how to go by fixing the a and b channel issue. I’m guessing a and b output should be at 32767 where black is 0 and white is (256^2-1 which is 65535). I used 32768 as a and b output. Maybe the desaturate filters in Krita doesn’t seem to play well with the a/b, and in that case, I should probably apply color adjustment filter mask and put a and b to 32768 after applying filter mask.

Krita Gradient_Layer_24.zip (14.8 KB)

One of my idea for Krita team was to have layers to be treated as alpha mask blending mode instead and the difference between grayscale + color to alpha is the the layers to be treated as blending mode is that it isn’t limited to the depth of those filter. It enables so much more things at a higher depth from painting, to game texturing, and even photography like in this case where it’s really needed and one would be to apply filtered clone layers to work with files with something like 8 colors only supported alpha (in most cases, games stuff, and in rare cases other purposes).

They did accepted the idea, so assuming they go along with it, I think I might be able to do this later on without the very problematic issue of Krita filters (some of them) being 8-bit depth, and without the need for “calibration filters”. There’s the issue of Threshold being limited to 255 range, but that’s something which won’t be fixed soon, but it does the job for people who don’t use 10-bit monitor, and not sure if I can say the same about those who use 10-bit monitor.

The gradient is still off. Take a look: