Any 16 - 235 process???

taliesin wrote on 10/2/2002, 5:47 PM
I'm in discussion with somebody who thinks when rendering with the SonicFoundryDV- codec there is a decompression to the colorspace of 16 - 235 (RGB) and then a recompression to 0 - 255.
I think this is false. My understanding is that VegasVideo (using the SonicFoundryDV- codec) only works in 0 - 255 colorspace and this makes it happen to have no losses in luminance.

Any further infos about that issue?

Tnx Marco

Comments

Tyler.Durden wrote on 10/2/2002, 6:12 PM
Hi Marco,

I have no official info, but my logic says: If Vegas has an NTSC broadcast clamp to reduce the range to 16-235, it must be working in the 0-255 range.

Plus, the color generators in Vegas all refer to 0-255.

Plus, when I make a graphic in Photoshop with bars of 0,0,0... 16,16,16... 235,235,235... 255,255,255... and selectively view them with the Vegas Luminance histogram, I see the 0,0,0, and 255,255,255, outside the clamp-range and the 16,16,16, & 235,235,235 inside the clamp range. (They are easily toggled with a cookie cutter FX.)

But then, my logic is always open to qustion. ;)

MPH
taliesin wrote on 10/2/2002, 6:31 PM
Hi Martyh,

your understanding is same as mine. Plus - I made lots of render-tests in the past using a luminance gradient pattern with a range of 0 - 255 and rendered it 10 times doing a pixel-shift with any render generation. And after 10 render generations there happens - NOTHING. My test pattern looks absolutely same comparing original and 10th render generation.

But couldn't it be that only the decompressed state (and this - recompression - is what happens in any render process) is 16 - 235 and when recompressing the file there it will be blown up to 0 - 255 again?
Just a shot in the dark what them might reply to me to my thoughts ...

Is there any way to analyse a file when it is in recompressed state?

BTW: Is it possible I've seen your sign in our german "Videofreunde-Forum"?

Marco

Tyler.Durden wrote on 10/2/2002, 7:02 PM
Hi Marco,

I understand the question, but I don't have a good (proven) answer. My first thought is that testing with so many generations would show change due to rounding error. Since it doesn't degrade, I suspect the data is native 0-255. Just a guess though.

(As for Videofreunde-Forum, I tried to register to see the footage you were testing the chromakey, but my German is to poor to properly navigate the site. I believe another Vf-F user has the name "martyh". Anyway, I think the chromakey technique you describe provides better chromakey than I have seen in any NLE.)

Thanks for the great tips.

MPH