'OnlyVerticalBicubicResize' filters in Avisynth

[WarpEnterprises]

Why are you considering resizing that much?
It is very fast already and contributes only minimally to the whole processing time, even if there are no other filters.

[HarryM]

Originally posted by WarpEnterprises
Why are you considering resizing that much?
It is very fast already and contributes only minimally to the whole processing time, even if there are no other filters.

Sure. My motto is 'dumm idea is idea too'...
This is only my idea. It is'nt a 'question of live or death'...

Personally I prefer quality-up over speed-up.


Hmmm, i think...

How much is different product of bilinear and bicubic (or another algorithm) for 'little change' of dimension? E.g. resize from 708 to 704 pixels?

[sh0dan]

Originally posted by HarryM
sh0dan: I have next idea (good for 'B/W mode' in XviD, e.g.).
When I encoding b/w movie and resized this, is needless resize chroma (chroma not exist, only luma, right?).

Can you define next parameter for resize filters like "forced b/w=on/off"? We can 'resize' and 'convert to b/w' at the same time (with much less time)...

No! - We had this discussion some time ago, about combining filters, and IMO we do not need a specialized luma version of every filter. I will not argue if it has a place in XViD, but it doesn't in AviSynth. (V/H)ReduceBy2 are specialized enough resizers, but they are fast enough and general enough to deserve a place.

Besides how many percent of all Avisynth encodes are B/W, wouldn't 5% be a high estimate. How much time would you save? 1-2% of overall time in an MPEG2->MPEG4 conversion? Does it seem worth it to you?

[HarryM]

Originally posted by sh0dan


No! - We had this discussion some time ago, about combining filters, and IMO we do not need a specialized luma version of every filter. I will not argue if it has a place in XViD, but it doesn't in AviSynth. (V/H)ReduceBy2 are specialized enough resizers, but they are fast enough and general enough to deserve a place.

Besides how many percent of all Avisynth encodes are B/W, wouldn't 5% be a high estimate. How much time would you save? 1-2% of overall time in an MPEG2->MPEG4 conversion? Does it seem worth it to you?

I agree.

[sh0dan]

Originally posted by trbarry

Just doing this from memory but I think the vertical resize creates a new frame 1 horizontal line at a time. When it is done the horizontal resize takes one horizontal line at a time and converts it to the unpacked work format, then resizes it.

Absolutely 100% correct

I think this would actually lesson cache hits compared to the current scheme as each unpacked line could be created from register values during the vertical resize and immediately horizontal resized (after the line was done) while still possibly in some level cache.

So, when a vertical line is done, it is stored unpacked in the one line tempbuffer, and immediately resized?!? Sound very reasonable speedwise. It does however sound quite complex codewise, but it should be tested, since it could give up to a 50% speed increase (filteredresizeH is slower than V).

The only problem I see is, in the cases where it would be more optimal to resize horizontally before vertically. Now Avisynth chooses the axis on which it preserves the most detail, so the second resizer has the best possible quality to resize from.

[HarryM]

Originally posted by sh0dan
[B]
Absolutely 100% correct



So, when a vertical line is done, it is stored unpacked in the one line tempbuffer, and immediately resized?!? Sound very reasonable speedwise. It does however sound quite complex codewise, but it should be tested, since it could give up to a 50% speed increase (filteredresizeH is slower than V).

The only problem I see is, in the cases where it would be more optimal to resize horizontally before vertically. Now Avisynth chooses the axis on which it preserves the most detail, so the second resizer has the best possible quality to resize from.

98% users use Avisynth for making personal copies of DVD or TV rips

Answer is clear..., don't you think?
The downsize-ratio by width is generally smaller.