How to identify brightest spots of render and use it as a mask with Compositor?

Hi guys, I hope everyone is doing well.

Is there any kind of “Threshold” node in the Compositor? Or a Node that works in a similar manner?

I’m trying to composite an image on top of a specific material in the compositor, using Material Index/ID Mask and Alpha Over. This part works well.

However, I would like the overlaid image to not appear in the brightest parts of the render.

So far my only way to achieve this is to use a Brightness/Contrast Node, along with an RGB Curves node as the factor in a second Alpha Over Node to remove the overlaid texture from the brightest areas. This is functional but not ideal.

Ideally, I would be able to use a threshold function to identify the brightest parts of the image, then use the result of that node as a mask for my Alpha Over node.

My example .blend file is here:

http://www.pasteall.org/blend/39930

Attached is a shot of the current node setup I’m trying to use, and also a shot of the render I brought into Photoshop. I used a Threshold Adjustment Layer on it to show an example of the sort of output I’d like to see.

Thanks for any help or info.


Attachments


If you want a brightness based threshold mask, first do Separate HSVA to get the brightness (or value V to be exact) and then add a Math node with Greater Than or Less Than function. This will set your threshold and you get a black-white image that you can use in factor inputs or wherever you need. If you want to set threshold on RGBA channels simply do Separate RGBA instead of HSVA.

Awesome, that worked perfectly. Thanks much, kesonmis.

If your image has colour evaluation, a luminance matte will use the proper 709 weights to pull a key for you. Value will be returning max(RGB) last I looked, which isn’t synonymous with the brightest portion of your image.

Yeah, it could be so. Although I’m not sure that max(r,g,b) is the proper definition of Value, must check that out.

If Value does not give what you need, there are also YUV and YCbCr separation nodes. The Luminance value Y should match the rec709 in YCbCr.

There is no canonized HSV implementation; it is a very loose encoding model. It can be expected that many different implementations exist.

Any time one sees YUV, be skeptical, as it is an analog encoding model. YCbCr on the other hand, is a digital encoding model. In both instances, the valuable aspect, the luma/luminance weights, even if it is coded correctly, may or may not match the Luminance matte process, with the matte having specific control over the key.

Frequently, however, because there is so much confusion around luminance weights, YUV (as its inaccurate name suggests) and YCbCr will use found values, which may even be the entirely inaccurate 601, 240M, or some other weights, as well as may or may not include broadcast scaling. TL;DR, avoid both for anything unless you are certain of the implementation and are specifically using the encoding / decoding standard for codec related purposes.

Blender wiki is uncertain on both YUV, YCbCr and Luminance matte component weights. I would not count on any of them to be correct without testing it first. I would presume that YUV is 601 and YCbCr is 709 and that Y means luminance, not luma, but as I said, I would not count on it. And actually this is one of the big problems of Blender compositor. Nothing is certain and explicitly defined in official help files.

There are no hard coded values left for luminance work in Blender to the best of my knowledge, unless someone isn’t relying on OpenColorIO, which obviously carries much graver problems. See https://developer.blender.org/D1082

The problem with both YUV and YCbCr beyond that, is that it is potentially scaled, which is a show stopper for pulling keys, in addition to being explicitly display referred.

Luminance and luma are calculated using precisely the same weights. The difference is that luma has a transfer curve applied while luminance does not, but that is more a byproduct of the range of data and not a singular value. A tad confusing.

Indeed. It often requires code crawling or reading the developer log. Is definitely an area that a casual contributor can take up on the wiki and cite code blocks.

I only chimed in because I happened to know a bit about this particular area and how it is implemented, both on the HSV front and the luminance front.

Thanks guys, a lot of helpful info here.

I tried both ways, and they both work for what I’m trying to do. However, I did notice the Luminance Matte seems to give me a greater range of influence as opposed to the Separate HSVA node.

What I mean is that using the HSVA with Math Node goes from black to white very quickly and harshly, while the Luminance method leaves a lot more gray areas in before it goes stark white or black. I could probably control this more in HSVA some other way, but for now I went with the Luminance Matte since it left a few areas brighter that I would prefer to be that way.

Thanks again, it really helped me out.