New SimpleResize 0.3.1.0

[trbarry]

I just put out a new version of SimpleResize. The only change is to remove the annoying horizontal restriction that the size be a multiple of 4 pixels. Both the input and output sizes must now be a multiple of 2 pixels, required for valid YUY2.

See:

www.trbarry.com/Readme_SimpleResize.txt and
www.trbarry.com/SimpleResize.zip

As always, the source is also in the zip.

- Tom

[Dark-Cracker]

hi,

as always very good job, happy to see u have find time to correct the 4 pixel bug :)

bye

[edit] of course now autodub/autoRV9 support the simpleresize filter , thank u again :) [edit]

[droolian01]

Thanks for doing the extra work tidying up this filter. I use this for every encode, so my cropping has just got that little bit easier.
Briliant!

[trbarry]

We aim to please. ;)

(Actually Dark-Cracker made me feel guilty about it in another thread over in the Xvid forum)

- Tom

[WarpEnterprises]

One application for the WarpedResize is the "conversion" 16:9 <> 4:3.
For that the Pixel Aspect Ratio in the middle of the screen should be correct, that at the borders must then be (intentionally!) wrong.
Can you tell how the PAR for the center can be calculated from the warp factors? (This must be the opposite way of how you arrived at the values in your example).

[sh0dan]

Really great work!

Regarding

// how do I do a __m128 constant, init and aligned on 16 byte boundar?


Use:


__declspec(align(16)) static const __int64 YMask[2] = {0x00ff00ff00ff00ff,0x00ff00ff00ff00ff}; // keeps only luma
__declspec(align(16)) static const __int64 FPround1[2] = {0x0080008000800080,0x0080008000800080}; // round words
__declspec(align(16)) static const __int64 FPround2[2] = {0x0000008000000080,0x0000008000000080};// round dwords


And use align(8) for mmx code. Learned it from ffdshow, that uses it a lot.

[MaTTeR]

Many thanks for the update trbarry:)

[trbarry]

One application for the WarpedResize is the "conversion" 16:9 <> 4:3.
For that the Pixel Aspect Ratio in the middle of the screen should be correct, that at the borders must then be (intentionally!) wrong.
Can you tell how the PAR for the center can be calculated from the warp factors? (This must be the opposite way of how you arrived at the values in your example).

I don't have a formula for it but in my own fooling around I decided it was best to compromise 4 factors, so none are too bad:

1) Very slighly crop whatever sticks out too far.

2,3) Very slightly warp both horizontal and vertical.

4) Leave it very slightly stretched, even in the center.

For instance if each of these accounted for only a 7.5% stretch then the total effect could take care of a 33.5% stretch in one or the other direction. This more than takes care of 16:9 <-> 4:3.

But I can't tell you what it would be at the center. My own formula was only to get 0 curvature in the center but I didn't worry about the rest of it since I was going to compromise there anyway. I think I read somewhere that less than about 10% off in aspect ratio is not bothersome to most folks.

- Tom

[trbarry]

"__declspec(align(16)) static const __int64 ..."

Sh0dan -

Yep, I've since learned about that but didn't change the comment. And I still don't think it works for stack variables. But I did use the __declspec(align(16)) in my last filters.

But thanks. That was fairly frustrating trying to write the SSE2 version and it kept blowing up on that stuff. If it hadn't been for that, and the lousy SSE2 debugging (can't see SSE2 debug regs) then there probably would have been a lot more SSE2 support. ;)

- Tom