RESOLVED: Build 2020.40290 Threshold Alpha Issues

I recently moved to the 2020.40290 Experimental build in order to work with the RealSense L515 for an upcoming project where the interactivity is powered by a depth camera. A certain part of the room will be divided into 6 areas, whenever someone enters the area, the colors of the RGB LED fixtures change. The tricky part is that the installation is a series of RGB fixtures and TouchDesigner needs to output the DMX.

In the past, I used a Threshold TOP to process out the noise in the background and then I export the alpha level of the Threshold TOP to control the visibility of each section. And indeed this is what happens in Build 2020.25380 - the Threshold on the color feed creates the transparency I want. But I want to use the depth feed (I mean eventually I want to use the point cloud in 3D space but that can’t happen on this project) and the Threshold doesn’t create alpha from any of the depth sensors (though it does work with Depth Aligned to Color) The black levels work correctly in the Mattes and Composites, but there’s no visual transparency and no activity on the alpha channel with the depth feeds, even though they are rendered as monochrome. I don’t know if that is a bug or simply something different about the depth feed, so I thought I would mention it.

Hey can you post a sample. toe and I’ll take a look?
Thanks

Here you go!

I set up a simple network - 5 RealSense tops - 2 color images, 3 depth ones, the threshold and Top to Chop.

It happens with both the D435 and the L515 and it only happens to the depth sensors.

Thanks!

Build 2020 40290 RealSense Threshold.toe (3.8 KB)

I’m actually not sure how you saw this happening in the 20000 series? The RealSense TOP is created a Mono image as output, so it doesn’t have alpha. To generate an alpha channel you need to change it’s pixel format in the threshold TOP to to one that has alpha.
20000 series does the same thing though, so I’m not sure exactly what you were seeing in there? Can you show a screenshot of that and share the .toe?

So here is a screenshot of what happens when I set the alpha in the threshold to be the same as the RGB with a RealSense D435 in the 20000 series (exactly as you say, changing the pixel format to add alpha):

This is what happens on the Color Stream with that same Threshold (clearly producing alpha as expected, no change to the Threshold parameters):

I discovered the other day that if I composite an image with the depth stream, the threshold will add the alpha as it does with the color stream:

It’s almost like there is color information missing from the depth output of the RealSense Top, so adding any kind of color channel gives the Threshold the RGB data to behave as expected.

Here is the sample .toe (with the composite disconnected to show the lack of alpha):

Build 2020 25380 RealSense Threshold.1.toe (3.5 KB)

If you middle click on an TOP you can see it’s pixel format. The Composite TOP will take it’s pixel format from the ‘Fixed Layer’, which defaults to the 2nd input. So the Composite TOP is now a pixel format that includes RGBA, which is why you now have an alpha channel to fill in. Directly from the Real Sense TOP the pixel format will be ‘Mono’, which has no alpha, so you need to change the Threshold TOP to be ‘Mono + Alpha’ to get an alpha output from it.

Ah, I see, not only does Mono not have alpha, it has no RGB, so the telling the threshold to create alpha from RGB still does nothing. Changing the pixel format to Mono+Alpha in the Threshold worked as you, thank you.

Its not that it doesn’t have RGB, it’s that that parameter doesn’t ‘create’ alpha, it ‘fills’ alpha, if it exists. If it doesn’t exist in the pixel format, then there is nothing to fill.
Mono is essentially RGB with all 3 values the same (and taking up 1/3 the space)