Sending in 16bit creates artifacts and the feed is in 8bit
TD 23680 commercial
Windows10
also tried on OSX high sierra
I’ve experienced this as well. I recommend using Pack TOPs with Touch In/Out TOPs instead, it’s more reliable for streaming anything > 8bit.
This thread has some additional info from Derivative: FIXED: [2020.22080/2019.19160 -Win10 (x64)] bouncing interlaced NDI
On a side note: it would probably be best to just get rid of the 16-bit/‘Native’ parameters in the NDI TOPs, since even under simple circumstances they don’t seem to function:
Do you see this in other content that isn’t noise? In my experience NDI doens’t handle noise well since it’s intended for broadcast viable content, and in general generative noise like this isn’t sent over broadcast really.
Just so I can check though, can you send me your exact TOP file with those noise TOP settings?
Interesting that 16-bit noise is interpreted differently from other 16-bit sources; I would love to learn more about these discrepancies and their causation(s).
I tested this with a 16-bit PNG via Moviefilein TOP, and indeed, it worked as expected.
Here is the tox file from the above use case: noise-ndi-16bit.tox (646 Bytes)
May be something else happening here too though. It works fine with 16-bit fixed, but 16-bit float is failing. I’ll take a look at it.
1 Like
i first noticed it while sending kinect pointcloud data (16bit float).
Using touchout (thanks dylanroscover!) allowed me to move on with the project at work and when I tried to replicate it at home (using a different sources) I didn’t have the bug thats why didn’t reply yet
1 Like
Thanks for the report. This specifically happens when the RGB values go outside the 0-1 range (which only can happen with floats). Since NDI is a fixed point format that uses YUV, my RGB->YUV conversion was failing when values were outside the 0-1 range. I now clamp the values before doing the RGB->YUV conversion.
Fixed in the next release.
1 Like