Printable Version of Topic Click here to view this topic in its original format

Unofficial VirtualDub Support Forums > VirtualDub Filters and Filter Development > Ntsc<->pal Gamma Convert

Posted by: bregdan Feb 15 2003, 02:06 AM

WARNING: NEWBIE ALERT - LONG POST I have been looking at using VirtualDub to convert NTSC to PAL and wanted to find some information about the standards. I knew that the frames per second were different, and that the sizes were different but I didn't know that there was a gamma "set" in the standards. I found that the gamma is theoretically different for the standards. NTSC is specified as 2.2 and PAL is specified at 2.8 although many references say that neither one is enforced and studios use "what looks best" . As (from what I can see) standard colour conversions would require a known gamma to revert to a gamma of 1 to make them accurate. Without a known gamma colours are not as good for filters being run on them, and you are more likely to have to "play" with contrast and brightness to make them look more/less washed out/rich. I also found a page (PDF) at http://www.bmva.ac.uk/bmvc/2001/papers/40/accepted_40.pdf which might solve this problem. So, would a filter that implemented this be a) possible and useful or would it cause more problems on the loss in the conversion? Any comments? Pete p.s. I might not have explained this very well because my brain is failing due to all the maths I don't understand!

Posted by: phaeron Feb 15 2003, 03:29 AM

BT8x8 chips already do gamma correction when capturing RGB, although not for YUY2. Generally, gamma is the least of your concerns when capturing video -- with most devices you will be lucky if the top 10% or so of your luma range isn't clamped to hard white. Also, gamma correction really stresses the accuracy of 8-bit component RGB. According to Blinn, you need about 12 bits of linear RGB to reproduce 8-bit uncorrected RGB. Working with 12-bit or 16-bit per channel RGB isn't much fun. Finally, VirtualDub's levels filter can apply a gamma correction curve, although it is a "pure" gamma (x^power), and lacks the initial linear ramp specified for NTSC/PAL.

Posted by: bregdan Feb 15 2003, 04:17 AM

Thanks, I thought this might be the case - oh well. Pete

Posted by: Morsa Feb 16 2003, 02:39 AM

Why is so tedious to use 16 bit precision internally in Vdub. Isn't MMX suitable for such a task? Just a question.

Posted by: phaeron Feb 16 2003, 05:27 AM

Intermediate results require more precision. If you are already using 16 bits for your input and output values, you don't have any more bits for computation. In particular, scaling pixels currently uses 8x8->16 multiplies, whereas doing 16x16->32 requires a bit of shuffling and twice the operations. Also, MMX uses 16-bit signed values, and 16 bits per channel requires twice as much memory bandwidth.

Posted by: Morsa Feb 16 2003, 07:52 AM

So, if I understood well, using an internal precision of 16 bit per channel for 8 bit per channel inputs for gamma correction giving an output of 8 bit per channel would be a nonsense.. Am I correct?

Posted by: phaeron Feb 16 2003, 09:57 PM

Not nonsense, but wouldn't work enough to be useful. Gamma correction is a non-linear transform, so if you use 8-bit for both corrected and non-corrected values, you end up with a fairly big precision chasm at the black end (something like 15 values out of 256). To avoid losing so much precision, all intermediate bitmaps need to be at least 12 bits/channel. Gamma transforms, for the most part, can't be done in MMX -- they are much, much more efficiently done in scalar code with table lookups.

Posted by: Morsa Feb 16 2003, 11:08 PM

So, look up tables is the usual way.Thank you. How does levels filter work in Vdub? What do you mean by intermediate bitmaps? Does Vdub use this kind of precision? Sorry If I didn't understand correctly.

Posted by: phaeron Feb 17 2003, 12:59 AM

The levels filter uses a 256-point lookup table. In RGB mode, levels(r,g, = [ f®, f(g), f( ]. In YUV mode, RGB is transformed into [ y, r-y, g-y, b-y ], and levels(r,g, = [ (r-y) + f(y), (g-y) + f(y), (b-y) + f(y) ]. The lookup table itself is computed in floating point arithmetic on filter chain startup. Most of VirtualDub's MMX filters unpack 8-bit channels to 16-bit, do math at 16-bit, and then pack back down to 8-bit. The point about intermediate bitmaps is that if you choose to do gamma correction around a group of filters, the precision of the whole chain is limited by the precision of the weakest link and thus it is pointless to use higher precision in the gamma transforms if filters are still taking 8-bits/channel in and out. This doesn't preclude you from putting the gamma transforms into a single filter and having that filter work in 16-bit or 32-bit, however. In general, I've found that trying to apply straight 1.8 or 2.2 curves results in really nasty video, and usually use 1.4 instead. I don't know whether it's because I've been conditioned to PC color or because there's a hidden nonlinearity somewhere else in the pipeline.

Posted by: fccHandler Feb 17 2003, 01:21 AM

You gotta love those emoticons that magically appear when you're trying to write some serious scientific stuff (I especially like the copyright symbol)!

Posted by: Morsa Feb 17 2003, 05:33 AM

The same happens for me. I cannot apply a gamma higher than 1.4 without making the video washed out.

Posted by: bregdan Feb 17 2003, 11:17 PM

I'm not sure that I asked the right question here (interesting though the answers are) if you go to the original http://www.bmva.ac.uk/bmvc/2001/papers/40/accepted_40.pdf that I gave, maybe it's not gamma correction as such but a way of getting more accurate colours which ignores(?) gamma and brightness. I might (probably have) got the wrong end of the stick here so just tell me to shut up and I will

Powered by Invision Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)