potential bug in pointresize found

[scharfis_brain]

Today, I was playing a little bit with AVIsynth's internal functions and found out, that pointresize returns garbage, when resizing to exactly a third of the source resolution!

example:
source clip: 768x288
pointresize (256,288) ---> delivers a totally green or black image with 256x288 pixels...

can anyone reproduce this?

[Si]

Can you post our exact script because things like this can easily be due to other filters.

regards
Simon

[scharfis_brain]

it doesn't matter in which context the pointresizer is.

even a simple script likeavisource("blabla.avi")
pointresize(256,288) (blabla.avi is 768x288)

returns a blck picture.

[Si]

Confirmed
avisource("d:\vtest\test.avi")
pointresize(160,576)

gives a green screen
test.avi is Huffyuv 480x576

regards
Simon

[scharfis_brain]

found a workaround!

avisource("blabla.avi")
pointresize(1536,288).pointresize(256.288)

works for me

(blabla.avi 768,288)

[Mug Funky]

hey yeah... YUV modes return green, RGB modes return black.

script:


start = MPEG2Source("G:\Allegro non troppo\chapter10_1.d2v")

finish = MPEG2Source("G:\Allegro non troppo\chapter10_.d2v")

unalignedsplice(start,finish).converttorgb32()

pointresize(last.width/3,last.height/3)

[IanB]

See attached file "resample_functions.cpp" at http://sourceforge.net/tracker/index.php?func=detail&aid=976183&group_id=57023&atid=482673 for a fix.

Problem potentially occurs for all odd multiples and sub-multiples of both width and height. i.e. 1/5, 1/3, 3, 5, 7, ...

Issue is divide by zero at lines 199 and 252.

IanB :)

P.S. This "You may not post attachments" is a real pain in the butt!

[Bidoche]

Your fix will probably output garbage too.

The problem is the produced coeffs should add to FPScale, when each of yours values FPScale already.


see http://cvs.sourceforge.net/viewcvs.py/*checkout*/avisynth2/avisynth/src/filters/resize/pattern/Attic/maker.cpp?content-type=text%2Fplain&rev=1.1.2.3 for 3.0 version of the pattern coefficients generation code.
That one is easier to understand.

[IanB]

Originally posted by Bidoche
Your fix will probably output garbage too.

The problem is the produced coeffs should add to FPScale, when each of yours values FPScale already.
Theoreticly yes. True I am only dealing with the case of 0/0 and forcing the result to 1 (which is the correct limit in this instance). Trying to prove the code for other cases with (non-zero)/0 fried my brain:confused: I am pretty sure the PointResize with exact odd (sub)multiples is the only case which give divide by zero. Probably the safest thing to do is throw an exception for the other case, this would at least avoid garbage output and warn the user. I'll upload an amended version.

Edit: Opps env->throw... is not available here, Force Total3 = 0.0 (Black/green pixels) as a hack. Wider mods needed:mad:

see http://cvs.sourceforge.net/viewcvs.py/*checkout*/avisynth2/avisynth/src/filters/resize/pattern/Attic/maker.cpp?content-type=text%2Fplain&rev=1.1.2.3 for 3.0 version of the pattern coefficients generation code.
That one is easier to understand.
But not any easier to mathematicly prove.;)

Do we have any budding mathemagicians:devil: that can prove the sum(coeef) is never zero for filter orders greater than 1 (PointResize).

IanB

[Bidoche]

True I am only dealing with the case of 0/0 and forcing the result to 1 (which is the correct limit in this instance).
0/0 is no limit, it's undetermined.
Just to convince you of it, what would be the limit of 0/0 + 0/0 = (0 + 0)/0 = 0/0 ... ?

Probably the safest thing to do is throw an exception for the other case, this would at least avoid garbage output and warn the user. I'll upload an amended versionThat maybe the case.

The simplest solution may to slightly shift the input values (add 1E-5 ?) to avoid the zero case.

[Manao]

double PointFilter::f(double x)
{
return 1.0;
}It should do the trick. With PointFilter, the FIR's size is only 1, so we don't care at all about the value of the coefficient.

[IanB]

Originally posted by Bidoche
0/0 is no limit, it's undetermined.
Just to convince you of it, what would be the limit of 0/0 + 0/0 = (0 + 0)/0 = 0/0 ... ?
True, 0/0 is no limit, but in this very particular case we are looking for A/A as A approaches zero
and the limit for this very particular case is indeed 1. I admit mathemagicly this is really dubious but unwinding the code does actually result in the required answer 1 (in fact the coeff are always 1 for PointResize).

The simplest solution may to slightly shift the input values (add 1E-5 ?) to avoid the zero case.

I tried that as the first quick standard hack and it didn't work. 0/1E-5 is still zero which still cause black/green frames. Doing it to both ends, i.e. T+1E-5/T+1E-5, still fails when T=-1E-5 but that only causes single black/green lines.

The code needs to be rearranged to totally avoid the condition in the first place. I just can't see how to. It took me hours just to unwind and prove the PointResize case, I couldn't prove the Bilinear or higher order cases, but I fear that it might just be possible for the coefficients to sum to zero in the higher order filters when just the wrong conditions occur, I just couldn't find any.

IanB:(

[IanB]

Originally posted by Manao
double PointFilter::f(double x)
{
return 1.0;
}It should do the trick. With PointFilter, the FIR's size is only 1, so we don't care at all about the value of the coefficient.

Sneaked an insightful answer in while I was pondering wood in forests of trees.:D

but unwinding the code does actually result in the required answer 1 (in fact the coeff are always 1 for PointResize).

And Manao kicks a spectacular goal.:cool:

IanB

P.S. I have compiled this up and extensively tested it, it seems to work very well, I have updated my patched source into bug tracker on source forge, it now include Manao's fix plus parse time exception handling if the sum of coefficients is ever zero.:)

[Bidoche]

@Manao

the PointFilter is like this in the cvs:double PointFilter::f(double x)
{
x = fabs(x);
return (x<1.0) ? (x) : 0.0; // Can somebody confirm this function?
}
Changing it to return 1.0 will certainly fix this 0 problem.

[sh0dan]

You are the best!

Committed to CVS!

(I just removed the commented out, wrong code)