Doom9's Forum - View Single Post

frustum · 11th November 2010, 11:26

Fred --

In your chicken picture, I'm not surprised that the whites are blown out, as they are a small percentage of the pixels. This is a feature of the algorithm that autolevels 0.3 uses, and which I didn't change in 0.4. The algorithm is to ignore the darkest and brightest 1/256th of all pixels (~ 0.4%) when determining the min/max luma for a frame. The intent is to avoid outliers in the distribution such that a stray noise pixels doesn't throw things off. If this feature didn't exist, if you had even one pixel with luma <= 16 and one with luma >= 235, autolevels would be a no-op.

Perhaps the best approach for this would be to add a parameter which specifies what fraction of outliers to ignore, and have it default to 1.0/256.0 for backwards compatibility. Another approach would be to still ignore outliers, but to clamp them to 16/235. Any opinion on which is better?

The color shift issue you see is no doubt due to the very hacky implementation of luma mapping for RGB I added. While it is infinitely better than what was there in 0.3 (which was to silently accept RGB as if it was YUV), it still leaves a lot to be desired. I spent only one evening on it and it seemed OK for the videos I tried, but I regret rushing it out now that I've seen some of the problems that occur. A great torture test is to try "somevideo.tweak(cont=0.05).converttoXXX.autolevels()" and see what happens beyond the expected heavy quantization.

Tonight I tried some less hacky but still hacky schemes to do the luma mapping in RGB space while still keeping the RGB proportions (in the just release 0.4, each of r,g,b are clipped independently). They all suffered from different failing corner cases.

So, I stole the yuv2rgb and rgb2yuv conversion routines from avisynth's guts (convert.h) and did the most direct code I could: one pixel at a time, convert rgb to yuv, remap the y using the same table I use in the yv12 code path, then convert back to rgb. That gives a nice image and isn't nearly as slow as I had feared it would be. If I go this route, I'd like to drop the "matrix" parameter, which I copied from the greyscale() filter. It is probably overkill as converttoyv12() from rgb is hardcoded for just one mapping function, not a choice of three.

Overall, I recommend not using 0.4 and getting tied into rgb (mis)behavior that I will fix soon.

BTW, I picked up this tip from a thread from a couple years ago. If you suspect that your components exceeding legal bounds, which is likely with autolevels' output, you can confirm it with limiter(), like this:

autolevels.limiter(show="luma")

Boondoggle --

Can you try your case with the 0.3 autolevels dll? I haven't changed yv12 processing, other than a very small fix to the scene detection logic.

11th November 2010, 11:26	#57 \| Link
frustum Registered User Join Date: Sep 2010 Location: Austin, TX Posts: 40	Fred -- In your chicken picture, I'm not surprised that the whites are blown out, as they are a small percentage of the pixels. This is a feature of the algorithm that autolevels 0.3 uses, and which I didn't change in 0.4. The algorithm is to ignore the darkest and brightest 1/256th of all pixels (~ 0.4%) when determining the min/max luma for a frame. The intent is to avoid outliers in the distribution such that a stray noise pixels doesn't throw things off. If this feature didn't exist, if you had even one pixel with luma <= 16 and one with luma >= 235, autolevels would be a no-op. Perhaps the best approach for this would be to add a parameter which specifies what fraction of outliers to ignore, and have it default to 1.0/256.0 for backwards compatibility. Another approach would be to still ignore outliers, but to clamp them to 16/235. Any opinion on which is better? The color shift issue you see is no doubt due to the very hacky implementation of luma mapping for RGB I added. While it is infinitely better than what was there in 0.3 (which was to silently accept RGB as if it was YUV), it still leaves a lot to be desired. I spent only one evening on it and it seemed OK for the videos I tried, but I regret rushing it out now that I've seen some of the problems that occur. A great torture test is to try "somevideo.tweak(cont=0.05).converttoXXX.autolevels()" and see what happens beyond the expected heavy quantization. Tonight I tried some less hacky but still hacky schemes to do the luma mapping in RGB space while still keeping the RGB proportions (in the just release 0.4, each of r,g,b are clipped independently). They all suffered from different failing corner cases. So, I stole the yuv2rgb and rgb2yuv conversion routines from avisynth's guts (convert.h) and did the most direct code I could: one pixel at a time, convert rgb to yuv, remap the y using the same table I use in the yv12 code path, then convert back to rgb. That gives a nice image and isn't nearly as slow as I had feared it would be. If I go this route, I'd like to drop the "matrix" parameter, which I copied from the greyscale() filter. It is probably overkill as converttoyv12() from rgb is hardcoded for just one mapping function, not a choice of three. Overall, I recommend not using 0.4 and getting tied into rgb (mis)behavior that I will fix soon. BTW, I picked up this tip from a thread from a couple years ago. If you suspect that your components exceeding legal bounds, which is likely with autolevels' output, you can confirm it with limiter(), like this: autolevels.limiter(show="luma") Boondoggle -- Can you try your case with the 0.3 autolevels dll? I haven't changed yv12 processing, other than a very small fix to the scene detection logic.