Levels Bug ?

[StainlessS]

Levels Bug ?

I assume, but could be wrong that the original Levels code used a min/max
limiting of the output, which at some later date was converted to using
PixelClip(), this in my opinion is a BUG, and certainly does not lay easy
with the original programmers intent.

I quote from the manual entry on the levels filter:-

"However, the input and output parameters can be larger than 255."

It seems to have been omitted that they could be less than zero too.

It is my assumption from the quote (that I take, to be from the original
Levels programmer), that the intent was to have no limits on either the
input nor output arguments to the levels filter, this was and is, quite a
sensible and flexible stance to take. Unfortunately, using PixelClip() has
almost completely negated the intent. As it now stands, PixelClip has a
slightly larger array (both +ve and -ve) than the normal 0-255 range to
presumably cope with slightly out of range results. BUT, as the quote above
points out, in levels, they could be deliberately far outside of the 0-255
range, much further than PixelClip was designed to 'contain'. PixelClip is
presumably designed to cope with eg rounding errors. In Levels, Arguments
outside the 0-255 range are not errors, only the eventual result should be
limited to the 0-255 range by a a simple min/max solution.

I say, put back what was I presume the original min/max limiting.

Unfortunately, there is at least one script that will fail badly if
the Levels code is amended, InPaintFunc.avs by Reuf Toc, for AVSInpaint.dll,
relies on the above problem. Reuf Toc, uses as output args 0-900,
and relies on PixelClip() out of PixelClip array, to produce all zero's
for those out of array elements. As it happens, it works quite well
as there seem to be a lot of zeros following the pixel clip array in
current versions of Avisynth, but only due to code link order.
I have a ripped out version of Levels source, only difference being that
it always outputs the LUT tables as text files (for use in comparing
Levels output with my Levels Grapher thing), and this alternate version of
the exact same code produces completely different results.

I say that PixelClip() in Levels is a BUG, put back min/max.

Perhaps I am wrong.

What Say YOU.

EDIT: the 0-900 thing in InPaintFunc.avs only affects the
postprocessing of edge of the logo.

[IanB]

I take it you mean this code in levels.cpp@167:- else if (vi.IsRGB()) {
...
map = PixelClip(int(p+0.5));
...
The code has always been like this. Yes using PixelClip() here is unnecessary. Speed is not an issue the op is run only 256 times during the constructor. I will amend the code.


PixelClip() is a very fast solution to min(max(x, 0), 255); but it is limited to input values (-320 < x < 256+320) beyond that we are in Array out of bounds territory.BYTE PixelClip(int x) {
if (x <= -320)
[I]Array out of bounds;
if (x <=0)
return 0;
if (x < 256)
return x;
if (x < 256+320)
return 255;
else
Array out of bounds;
}

[StainlessS]

I take it you mean this code in levels.cpp@167:- else if (vi.IsRGB()) {
...
map[i] = PixelClip(int(p+0.5));
...
I will amend the code.


Yes,

Thankyou.

[StainlessS]

EDIT:- Just removed a lot of rubbish.:stupid: