View Single Post
Old 18th April 2011, 02:57   #84  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 2,695
Quote:
Originally Posted by frustum View Post
Another common problem is too much clipping. The defaults for autolevel are set to match what it was with version 0.3, when I inherited it, which ignores the bottom 0.4% and top 0.4% of all pixels, pushing all of them into the clipping range. This is typically too much, and can often be fixed by setting it to something smaller like 0.1% or 0.05%.

For both of the above situations I have some ideas for heuristics which would improve the situation, but it doesn't seem possible to avoid all possible pitfalls.
You've mentioned this several times in this thread, and to deal with it you added the "ignore" parameters. This greatly improved the usefulness of this filter. However, you've asked several times prior to this post for ideas for another heuristic to help cope with this fundamental problem, so here are a couple of ideas. Everything that follows, except for the last paragraph, focuses on calculations made within a frame (as opposed to the averaging that you do across "n" frames).

It seems to me that you need to introduce the additional concept of pixel grouping. Starting with a pathological case, under almost all circumstances I can think of, pure white single dots should be ignored when doing the levels calculation. To take the simple case, if a dot is 255 and all immediately adjacent pixels are a value "x" less than this, then the dot should be thrown out of all calculations.

This extreme case seems fairly straightforward (as are most extreme cases). As the number of adjacent pixels that are as bright or brighter (or as dark or darker) increases, more "thought" should be given to including this group of pixels in the calculations.

With this concept, the larger the grouping of spots that exceeds the upper or lower limits (ignore_high, ignore_low), the more likely your algorithm should include them in the calculations, even if the threshold for total number of pixels beyond the boundary hasn't been exceeded.

One other heuristic would be to add the concept of an outlier. You obviously know the statistical definition. The visual problem I'm trying to define is where you have something like a specular reflection from a window pane, something like you'd get if you were videotaping out the front of your car, and the sun hits the rear window or chrome bumper of the car in front of you. This would give you a big area of pure white, and the auto-exposure in the camera would reduce the overall exposure, but you would sill have the huge number of pure white pixels. The histogram of the result would have this huge number of pixels at or around 255, but then a huge gap between those and the rest of the histogram. Situations like this might be detected by looking for large gaps in the upper and lower boundaries of the histogram, with virtually no pixels at all between this big spike of pixels at the very end of the histogram, and the point at which the normal tail of the histogram resumes. If this additional heuristic existed, such video would still be automatically corrected, even though a very large percentage of pixels were nearly pure white.

The following really bad ASCII art is attempt to show this. My suggestion is that the "hump" on the right side should be ignored (the real-life example would probably have the grouping on the right much closer together so it looks more like a single spike). The length of the "dead zone" between the two humps would be the "tip off" that the upper pixels are bogus.

So here's the heuristic: the narrower the right-hand hump; the closer that hump is to 255; and the bigger the gap of almost no pixels between that hump and the tail of the main distribution, the more aggressively the algorithm should ignore all the upper pixels.

There is also the issue of a one-frame departures from average, such as you get when someone uses a camera flash. Such frames should not be part of the moving average. However, I assume you already do this.
Code:
|
|           * *
|          *    * ** 
|         *         *                    *
|         *          *
|        *            *                 *
|       *              *                   *  
|      *                *           
|     *                  *             *    *
|   *                     *************      *
_______________________________________________[
johnmeyer is offline   Reply With Quote