'OnlyVerticalBicubicResize' filters in Avisynth

[HarryM]

Hi,

I often need to resize only height of movie. Width without change.

E.g. 'PAL movie'

Crop(12,71,704,434)
BicubicResize(704,304,0,0.5) 'width not changed!

I have any question:

Do exist in LanczosResize, BicubicResize, BilinearResize filters the overskip of width-resize routines (=logically less time for resizing), when I dont need a width-change?

[sh0dan]

yes

[HarryM]

Originally posted by sh0dan
yes

Short and clear answer... :)

Thanks

[sh0dan]

if you want a slightly longer one:

Avisynth has completely separate vertical and horizontal resizers.
If input is the same as output on one axis, that resizer will be skipped.
Which one is called first, is determined by which one has the smallest downscale ratio. This is done to preserve maximum quality, so the 2nd resizer has the best possible picture to work with.

[WarpEnterprises]

Is then my assumption correct:
Resizing only horizontally won't create errors on interlaced videos (I mean the resizing kernel does not mix different lines but "stays" on one line)

[sh0dan]

yes :)

[trbarry]

It is a nice feature that these resizer are smart enough to recognize that the vertical or horizontal value is unchanged and leave it alone. (SimpleResize isn't)

But for awhile now I have toyed with the idea of making a combined BicubicResize. For the most common cases where both the vertical and horizontal sizes change it could eliminate one entire pass through the data by having the vertical resize save the appropriate format that the following horizontal resize wants. This would probably speed it up noticeably for the average case and would not have to affect the above cases at all.

I had actually set out to do this when I instead wrote SimpleResize, but have sort of moved on to other things now. But if someone likes to optimze and happens to have too much time on their hands it might be an interesting thing to look at. ;)

- Tom

[sh0dan]

I'm not sure how much you'd gain by implementing a onepass resizer.

First of all you get massive overhead, since you'll most probably run out of free registers due to the added complexity.
It would also mean you would have a very non-liniear memory access pattern, which can result in penalties - all of us who has written a spatial smooth filter knows how it is.

Whoever wrote the current resizers did a very good job - it's very fast and very flexible.
The horizontal also has per-line unpacking, which speeds up the process massively - this could also be implemented in a one-pass resizer, but you'll probably run into many cache-misses, if your unpacked data gets larger then half the cache size. Otherwise, you'd have to unpack x-lines ahead.

I think you could gain up to 25% by doing a onepass resizer, but I did a profile a week ago on a script, that loaded an MPEG2 file, resized (using lanczos), did Fielddeinterlace() and saved out the result uncompressed using fast repack in vdub.
The resizer took ~ 15% of the total CPU time, so in a typical repack as this would gain 4% encoding speed - (and using bicubic and an MPEG4 compressor, the gain would probably be <2%). IMO not worth the massive complexity of writing a onepass resizer.

(hope this made any kind of sense :rolleyes: )

[HarryM]

I have next question...

Resize filter works with luma (Y) and chroma (U, V) separatelly?

When you want to resize faster, is good (idea- luma is much more important as chroma)

luma (Y) resize precise (like to bicubic resize) and
chroma (U, V) resize less precise (like to nearest neighbour).

[sh0dan]

IMO not in Avisynth. Yes, the resizers operate seperately with luma/chroma internally, but not more seperate than they are in the same X/Y loop.
Implementing different resizers will only make the code more complex, and gain you little speed. In principle what you're supposing is possible, but I doubt it will help much.
I will do a testversion to see how complex it is, and see if there is any gain but it's not high priority.

If you require seperate processing for quality concerns, you can still use MergeChroma/MergeLuma.

[sh0dan]

ok - I was wrong (and I was right) ;)

Implementing it was easy, but it's only possible to do in the horizontal resize, since vertical doesn't have seperate Y/UV processing.
[Edit]: Hence it will not be of any gain, if we implemented it in that one.

Get is at the bottom of the CVS bin site (http://cultact-server.novi.dk/kpo/avisynth/avs_cvs.html)

It is hardcoded to use Biliniar filtering on UV always! Both lanczos and bicubic are affected.
I doubt it will give you much speed improvement though. (I'll try to do a nearest neighbough, if I can do it quick).

[Marc FD]

the bicublin resize is a good concept, but more a planar concept.

BTW sh0dan, would it be possible to have a alpha version of avisynth working with YV12 / I420 planar colorspaces ?? :)

or need i to hack my self my own version :(

[sh0dan]

Did a point sampler (nearest neighbour) using the existing filter - even when only used on horizontal Chroma, it looks like crap - visible artifacts along lines. I can put it up, if you're interested, but trust me, it's not worth the speed.

[sh0dan]

@MarcFD: Patience my friend - still working day and night on float/int32 samples (see the avisynth_2_1 branch in CVS).
If I do a hasty version, it will probably be changed anyway, and I think it should be well tested before we begin to do plugins. Preparing for it is not a bad thing though.

[Marc FD]

i wait... i wait..
but in the meantime i can't work on my new filters, because they are almost all in YV12 :D
i'll use some huge convertion step to use planar colorspace in YUY2.

YUY2->I420->YUY2

it's not lossless, and very very slow(not too much,i've some MMX code under my hands), but it's a good begining to do testing :)

BTW, do you think it would be usefull to adapt VDub's (arbitrary) resize to Avisynth ??

[sh0dan]

Marc, I'll get the sample thing debugged and tested, and then throw myself at YV12 ASAP - I think we have a fairly good idea of how to do it from out previous discussion :)

[Acaila]

Marc FD wrote:
but in the meantime i can't work on my new filters
So all the (YUY2) filters you've worked on so far are now working perfectly and are completely bug free??

[Marc FD]

how to say it ? yes :)
in fact i didn't liked the concept of CopySame and MAM, and some approach i tested with XviD gived me much better result, and almost no quality destruction. So i've stopped developpement on these.

nobody reported a bug in Cnr2/Focus2/MPEG2DecPP for a while.

[trbarry]

Whoever wrote the current resizers did a very good job - it's very fast and very flexible.
The horizontal also has per-line unpacking, which speeds up the process massively - this could also be implemented in a one-pass resizer, but you'll probably run into many cache-misses, if your unpacked data gets larger then half the cache size. Otherwise, you'd have to unpack x-lines ahead.

sh0dan -

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.

What I had considered was having a modified version of the vertical resize save one horizontal line at a time in unpacked format and after each line call a modified horizontal resize to resize that single line from the unpacked format into the output frame. 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.

But I guess you are right it would be only an incremental improvement in the grand scheme of things. ;)

- Tom

[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)...

[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

Absolutely 100% correct :)

[b]

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.