Is there a way around this resizing "bug"?

[absinthe]

Okay, this perhaps isn't really a "bug" per se, but nonetheless ...

I use lanczos to resize as well as to crop. I get my values for cropping by looking at my script in VDub using the 'null transform' filter. Now, it often happens when cropping with precision that you end up cropping one side by an odd number. Now, that's okay as long as the opposite side is also cropped by an odd number (i.e., total crop is even). When the opposite side is not also odd, well then I either sacrifice a line of pixels or leave in a line of black pixels on one side or the other.

Now this all works fine and well until the value which you are left with for horizontal or vertical is the same value to which you are resizing, respectively. That gives an error.

For instance:

LanczosResize(640,272,0,103,720,272)
# i.e. cropping 103 from the top and 105 from the bottom #

will give an error, whereas if the movie was just shifted up or down one pixel in the source it would have been fine (i.e. the "103" would have been 102 or 104).

Also, if I happened to want to resize to something different, such as

LanczosResize(608,256,0,103,720,272)
# i.e. resolution after cropping is still greater than resolution after resizing

That works fine as well.

This has actually happened to me several times, and I've now even found a movie where it happens on the width value as well.

Trying to use the 'crop' command separately before resizing doesn't work. I've gone as far as actually resizing a movie twice in a script to get around this. I'm using AviSynth 2.55 BTW.

Ideas?

-abs

[hartford]

I could be mistaken, but as far as I know, LanczosResize() doesn't have a "crop" feature; only BilinearResize() does.

Could that be the cause of the problem?

[unskinnyboy]

I could be mistaken, but as far as I know, LanczosResize() doesn't have a "crop" feature; only BilinearResize() does.

Could that be the cause of the problem?
From here (http://www.avisynth.org/Resize):

For all resizes you can use an expanded syntax which crops before resizing. The same operations are performed as if you put a Crop before the Resize, there can be a slight speed difference.

[hartford]

Not doubting you, but the syntax makes no sense to me:

LanczosResize(clip clip, int target_width, int target_height, float src_left, float src_top, float src_width, float src_height, int taps)

So LanczosResize(608,256,0,103,720,272)

becomes

Target: 608X256,

Clip left=0
Clip top=103
output_width=720
output_height=272
default_taps

Ok. So, take clip, resize to 608x256, crop left and top, resize to 720x272

I'll be quiet. :)

[Mug Funky]

nah, it takes a 720x480 image, crops that, then resizes to the required output size.

but if cropped input = output, then the resizer is skipped, and it seems a regular crop (with modulo limits) is used.

i'd like to see maybe a bool argument for the resizers that allows the resizer to be used when cropping, so for instance you can quickly swap field order by moving up or down a whole pixel. currently this can only be done in yuy2 space.

i can't think of what such an argument would be called (forceresize=true?), but it would be useful for moving clips around by any number we want, and escaping crop's limitations.

[absinthe]

but if cropped input = output, then the resizer is skipped, and it seems a regular crop (with modulo limits) is used.

i'd like to see maybe a bool argument for the resizers that allows the resizer to be used when cropping, so for instance you can quickly swap field order by moving up or down a whole pixel. currently this can only be done in yuy2 space.

i can't think of what such an argument would be called (forceresize=true?), but it would be useful for moving clips around by any number we want, and escaping crop's limitations.
Yes, I was thinking it would be great if we could just move the whole frame up/down/left/right by a pixel. So this can't be done as of now?

-abs

[Wilbert]

I filed a bugreport at sourceforge. The script of absinthe should work for YV12, but it doesn't. The cropping values should be allowed to be float.

[absinthe]

Thanks, Wilbert.

-abs