Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 13th April 2011, 19:00   #81  |  Link
markanini
Registered User
 
Join Date: Apr 2006
Posts: 296
It does accent ringing, sometimes beneficial, sometimes detrimental depending on the source. A question I want to ask is when dealing with a difficult source what's a good kernel to use when spline16 and lanczos2 has too much ringing and you want to retain decent sharpness still.
markanini is offline   Reply With Quote
Old 14th April 2011, 00:21   #82  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
Quote:
Originally Posted by PhrostByte View Post
I suspect it's caused by chroma bleeding into luma because of subsampling. Some colors right next to each other can react particularly bad. If you post an example image I can take a look.
Thanks, here's the link. It's a 400x zoom of a 1920x1088 frame h264AVC.

http://www.yellowspace.webspace.virg...R_400xZoom.png
Yellow_ is offline   Reply With Quote
Old 14th April 2011, 04:03   #83  |  Link
PhrostByte
Grand Fruitioner
 
PhrostByte's Avatar
 
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
Quote:
Originally Posted by markanini View Post
It does accent ringing, sometimes beneficial, sometimes detrimental depending on the source. A question I want to ask is when dealing with a difficult source what's a good kernel to use when spline16 and lanczos2 has too much ringing and you want to retain decent sharpness still.
Try Blackman2. I made this nifty little webpage to help people choose a kernel:
http://svn.int64.org/viewvc/int64/re...c/kernels.html

You'll need a browser that supports HTML5 canvas.

Quote:
Originally Posted by Yellow_ View Post
Thanks, here's the link. It's a 400x zoom of a 1920x1088 frame h264AVC.

http://www.yellowspace.webspace.virg...R_400xZoom.png
Yea, that's chroma bleeding. It's more noticeable when color meets white/black/gray/etc., because grays don't actually have chroma. When chroma gets subsampled, it gives the gray some of the surrounding colors' chroma and results in weird colors.

There actually is something I can do to help combat this, though I haven't started any work on it as it's a little complex.
PhrostByte is offline   Reply With Quote
Old 14th April 2011, 14:34   #84  |  Link
Archimedes
Registered User
 
Join Date: Apr 2005
Posts: 212
Spline36Resize >>
ResampleHQ, Spline36 >>

Depending on the source and the used kernel, gamma aware resizing produces dark lines around bright areas where the same 8 bit resizer in AviSynth did not fail (see example above). Tested also with Image Analyzer (which is also capable of gamma aware resizing).

The effect decrease with Lanczos (2 lobes), but not completely. Same with Spline16. With Blackman (2 lobes) and Bicubic (b=0.33, c=0.33) the effect is gone.

ResampleHQ, Lanczos (2 lobes) >>
ResampleHQ, Blackman (2 lobes) >>
ResampleHQ, Bicubic (b=0.33, c=0.33) >>
Archimedes is offline   Reply With Quote
Old 14th April 2011, 18:29   #85  |  Link
Yellow_
Registered User
 
Join Date: Sep 2009
Posts: 378
Quote:
Originally Posted by PhrostByte View Post
Yea, that's chroma bleeding. It's more noticeable when color meets white/black/gray/etc., because grays don't actually have chroma. When chroma gets subsampled, it gives the gray some of the surrounding colors' chroma and results in weird colors.
Ok, thanks for the explanation.

Quote:
Originally Posted by PhrostByte View Post
There actually is something I can do to help combat this, though I haven't started any work on it as it's a little complex.
Good news, look forward to that all in good time.
Yellow_ is offline   Reply With Quote
Old 15th April 2011, 09:47   #86  |  Link
Archimedes
Registered User
 
Join Date: Apr 2005
Posts: 212
Quote:
Originally Posted by Dogway View Post
good balance of both of them:
lanczos (best in my opinion)
blackman (2nd best)
spline16
catmull
Did some further tests and came to similar results. A good compromise between blurring, sharpening and ringing seems to be: Lanczos (2 lobes) and CatmullRom (which is practically the same as Lanczos with 2 lobes).

Bicubic >>
Blackman (2 lobes) >>
CatmullRom >>
Lanczos (2 lobes) >>
Spline16 >>
Archimedes is offline   Reply With Quote
Old 15th April 2011, 11:25   #87  |  Link
TinTime
Registered User
 
Join Date: Jan 2009
Location: UK
Posts: 403
All looks very interesting - thanks for this!

Anyway, I've just found a small bug. If you set src_width or src_height to -0 then it produces some peculiar (although not unattractive ) results. Presumably it should use default values if either of these are set to 0, like AVISynth's resizers.
TinTime is offline   Reply With Quote
Old 19th April 2011, 22:10   #88  |  Link
PhrostByte
Grand Fruitioner
 
PhrostByte's Avatar
 
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
Quote:
Originally Posted by ChaosKing View Post
Benchmark results
------------------

The AVX version seems to be very slow :/
If you don't mind trying a new version, I think I figured out what was going on.

http://sourceforge.net/projects/int6...h.zip/download
__________________
Lanczos4, Spline36, what!? Don't know how to pick a resizer? Take a look at my kernel visualizations.
Want a high-quality, gamma-aware resizer? Check out my ResampleHQ filter.
PhrostByte is offline   Reply With Quote
Old 20th April 2011, 21:52   #89  |  Link
ChaosKing
Registered User
 
Join Date: Dec 2005
Location: Germany
Posts: 1,264
Looks good now or should I say: an amazing speedup :P

It could be that since "linear RGB -> x ", the values ​​are slightly distorted, because my brother started to play Portal 2 on that PC. ^^"

Code:
RGB24 -> linear RGB C: (fastest/slowest/average) wall time speed is 4.64519/4.6013/4.63308 runs/second.
RGB24 -> linear RGB C relative speed: 1.0x
RGB24 -> linear RGB SSSE3: (fastest/slowest/average) wall time speed is 36.5916/36.1973/36.4791 runs/second.
RGB24 -> linear RGB SSSE3 relative speed: 7.8773x
RGB24 -> linear RGB AVX: (fastest/slowest/average) wall time speed is 63.7797/63.3852/63.5543 runs/second.
RGB24 -> linear RGB AVX relative speed: 13.7303x
RGB32 -> linear RGB C: (fastest/slowest/average) wall time speed is 1.96892/1.95244/1.96175 runs/second.
RGB32 -> linear RGB C relative speed: 1.0x
RGB32 -> linear RGB SSE2: (fastest/slowest/average) wall time speed is 38.7904/38.4984/38.6492 runs/second.
RGB32 -> linear RGB SSE2 relative speed: 19.7014x
RGB32 -> linear RGB AVX: (fastest/slowest/average) wall time speed is 61.5876/60.6015/61.2052 runs/second.
RGB32 -> linear RGB AVX relative speed: 31.2799x
RGB32 -> linear RGBA C: (fastest/slowest/average) wall time speed is 1.89056/1.88258/1.8879 runs/second.
RGB32 -> linear RGBA C relative speed: 1.0x
RGB32 -> linear RGBA SSE2: (fastest/slowest/average) wall time speed is 37.478/37.2069/37.377 runs/second.
RGB32 -> linear RGBA SSE2 relative speed: 19.8238x
RGB32 -> linear RGBA AVX: (fastest/slowest/average) wall time speed is 58.1383/57.8567/58.0005 runs/second.
RGB32 -> linear RGBA AVX relative speed: 30.7519x
YV12 -> YUV C: (fastest/slowest/average) wall time speed is 49.1157/48.8132/48.9772 runs/second.
YV12 -> YUV C relative speed: 1.0x
YV12 -> YUV SSE2: (fastest/slowest/average) wall time speed is 293.662/276.124/290.44 runs/second.
YV12 -> YUV SSE2 relative speed: 5.97899x
YV12 -> YUV AVX: (fastest/slowest/average) wall time speed is 291.98/290.154/291.136 runs/second.
YV12 -> YUV AVX relative speed: 5.94473x
YUY2 -> YUV C: (fastest/slowest/average) wall time speed is 73.0191/72.4696/72.8227 runs/second.
YUY2 -> YUV C relative speed: 1.0x
YUY2 -> YUV SSE2: (fastest/slowest/average) wall time speed is 418.173/407.67/416.318 runs/second.
YUY2 -> YUV SSE2 relative speed: 5.7269x
YUY2 -> YUV AVX: (fastest/slowest/average) wall time speed is 441.182/376.143/405.183 runs/second.
YUY2 -> YUV AVX relative speed: 6.04201x
YUV -> linear RGB C: (fastest/slowest/average) wall time speed is 6.26964/5.08769/6.1638 runs/second.
YUV -> linear RGB C relative speed: 1.0x
YUV -> linear RGB SSE2: (fastest/slowest/average) wall time speed is 38.2352/37.4367/37.9741 runs/second.
YUV -> linear RGB SSE2 relative speed: 6.09846x
YUV -> linear RGB AVX: (fastest/slowest/average) wall time speed is 59.4667/59.0774/59.3507 runs/second.
YUV -> linear RGB AVX relative speed: 9.48486x
linear RGB -> RGB24 C: (fastest/slowest/average) wall time speed is 1.91731/1.89385/1.90992 runs/second.
linear RGB -> RGB24 C relative speed: 1.0x
linear RGB -> RGB24 SSSE3: (fastest/slowest/average) wall time speed is 39.3451/38.7191/39.0217 runs/second.
linear RGB -> RGB24 SSSE3 relative speed: 20.521x
linear RGB -> RGB24 AVX: (fastest/slowest/average) wall time speed is 53.6576/51.0381/52.9992 runs/second.
linear RGB -> RGB24 AVX relative speed: 27.9859x
linear RGB -> RGB32 C: (fastest/slowest/average) wall time speed is 1.82714/1.79387/1.81084 runs/second.
linear RGB -> RGB32 C relative speed: 1.0x
linear RGB -> RGB32 SSE2: (fastest/slowest/average) wall time speed is 44.3867/44.0377/44.1762 runs/second.
linear RGB -> RGB32 SSE2 relative speed: 24.293x
linear RGB -> RGB32 AVX: (fastest/slowest/average) wall time speed is 53.4973/45.477/51.7734 runs/second.
linear RGB -> RGB32 AVX relative speed: 29.2792x
linear RGBA -> RGB32 C: (fastest/slowest/average) wall time speed is 1.72983/1.65757/1.71013 runs/second.
linear RGBA -> RGB32 C relative speed: 1.0x
linear RGBA -> RGB32 SSE2: (fastest/slowest/average) wall time speed is 42.1848/39.7659/41.8548 runs/second.
linear RGBA -> RGB32 SSE2 relative speed: 24.3867x
linear RGBA -> RGB32 AVX: (fastest/slowest/average) wall time speed is 48.3195/46.7094/47.833 runs/second.
linear RGBA -> RGB32 AVX relative speed: 27.9332x
YUV -> YV12 C: (fastest/slowest/average) wall time speed is 146.967/143.542/145.766 runs/second.
YUV -> YV12 C relative speed: 1.0x
YUV -> YV12 SSE2: (fastest/slowest/average) wall time speed is 390.946/370.838/383.787 runs/second.
YUV -> YV12 SSE2 relative speed: 2.66009x
YUV -> YV12 AVX: (fastest/slowest/average) wall time speed is 392.435/299.917/359.429 runs/second.
YUV -> YV12 AVX relative speed: 2.67022x
YUV -> YUY2 C: (fastest/slowest/average) wall time speed is 187.74/182.522/186.619 runs/second.
YUV -> YUY2 C relative speed: 1.0x
YUV -> YUY2 SSE2: (fastest/slowest/average) wall time speed is 521.429/455.525/489.856 runs/second.
YUV -> YUY2 SSE2 relative speed: 2.77739x
YUV -> YUY2 AVX: (fastest/slowest/average) wall time speed is 492.264/432.675/468.23 runs/second.
YUV -> YUY2 AVX relative speed: 2.62205x
linear RGB -> YUV C: (fastest/slowest/average) wall time speed is 2.94834/2.44282/2.75141 runs/second.
linear RGB -> YUV C relative speed: 1.0x
linear RGB -> YUV SSE2: (fastest/slowest/average) wall time speed is 38.0381/36.8236/37.6511 runs/second.
linear RGB -> YUV SSE2 relative speed: 12.9016x
linear RGB -> YUV AVX: (fastest/slowest/average) wall time speed is 56.6484/54.8323/56.095 runs/second.
linear RGB -> YUV AVX relative speed: 19.2137x
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth
VapourSynth Portable FATPACK || VapourSynth Database || https://github.com/avisynth-repository

Last edited by ChaosKing; 20th April 2011 at 21:58.
ChaosKing is offline   Reply With Quote
Old 22nd April 2011, 02:35   #90  |  Link
PhrostByte
Grand Fruitioner
 
PhrostByte's Avatar
 
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
Quote:
Originally Posted by ChaosKing View Post
Looks good now or should I say: an amazing speedup :P
Sweet, glad it worked. Those results were about what I expected.
__________________
Lanczos4, Spline36, what!? Don't know how to pick a resizer? Take a look at my kernel visualizations.
Want a high-quality, gamma-aware resizer? Check out my ResampleHQ filter.
PhrostByte is offline   Reply With Quote
Old 13th May 2011, 02:59   #91  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
V6 x64 is giving me a blank screen in occasions. I am trying to prepare for a simple and reproducible scenario.....
henryho_hk is offline   Reply With Quote
Old 18th May 2011, 00:35   #92  |  Link
markanini
Registered User
 
Join Date: Apr 2006
Posts: 296
Quote:
Originally Posted by PhrostByte
I take it from studying your graph that Blackman3, Catmull-Rom, Lanczos2, Spline16 would all make good general purpose resizing kernels and some quick visual test I made seem to confirm this, atleast to the extent that I can't tell them apart and they all look perfectly fine.

Last edited by markanini; 18th May 2011 at 00:39.
markanini is offline   Reply With Quote
Old 18th May 2011, 01:05   #93  |  Link
PhrostByte
Grand Fruitioner
 
PhrostByte's Avatar
 
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
Quote:
Originally Posted by henryho_hk View Post
V6 x64 is giving me a blank screen in occasions. I am trying to prepare for a simple and reproducible scenario.....
Let me know!

Quote:
Originally Posted by markanini View Post
I take it from studying your graph that Blackman3, Catmull-Rom, Lanczos2, Spline16 would all make good general purpose resizing kernels and some quick visual test I made seem to confirm this, atleast to the extent that I can't tell them apart and they all look perfectly fine.
Yes. Start from one of those and if it doesn't look good, try something that improves in the areas you need.
__________________
Lanczos4, Spline36, what!? Don't know how to pick a resizer? Take a look at my kernel visualizations.
Want a high-quality, gamma-aware resizer? Check out my ResampleHQ filter.
PhrostByte is offline   Reply With Quote
Old 20th May 2011, 07:26   #94  |  Link
Lyle_JP
Unreasonable User
 
Lyle_JP's Avatar
 
Join Date: Nov 2003
Posts: 213
Quote:
Originally Posted by henryho_hk View Post
V6 x64 is giving me a blank screen in occasions. I am trying to prepare for a simple and reproducible scenario.....
Unfortunately, I have nothing but reproducible scenarios. I am trying to run the x64 version on sET's 64-bit Avisynth 2.5.8, and every video I feed to ResampleHQ comes out as nothing but a properly resized black screen. It doesn't matter what arguments I use, even all defaults. Source doesn't matter, either. I wish I could be more help narrowing down the issue, but for now this plug-in simply doesn't work at all in my environment.
Lyle_JP is offline   Reply With Quote
Old 25th May 2011, 01:09   #95  |  Link
PhrostByte
Grand Fruitioner
 
PhrostByte's Avatar
 
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
Quote:
Originally Posted by henryho_hk View Post
V6 x64 is giving me a blank screen in occasions. I am trying to prepare for a simple and reproducible scenario.....
Quote:
Originally Posted by Lyle_JP View Post
Unfortunately, I have nothing but reproducible scenarios. I am trying to run the x64 version on sET's 64-bit Avisynth 2.5.8, and every video I feed to ResampleHQ comes out as nothing but a properly resized black screen. It doesn't matter what arguments I use, even all defaults. Source doesn't matter, either. I wish I could be more help narrowing down the issue, but for now this plug-in simply doesn't work at all in my environment.
found the problem. will put a fix out shortly.
__________________
Lanczos4, Spline36, what!? Don't know how to pick a resizer? Take a look at my kernel visualizations.
Want a high-quality, gamma-aware resizer? Check out my ResampleHQ filter.
PhrostByte is offline   Reply With Quote
Old 3rd June 2011, 21:37   #96  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Copenhagen Denmark
Posts: 269
the robidoux ImageMagick filter is not supposed to be used this way

Quote:
Originally Posted by Dogway View Post
...

blurry: principally because of this
bilinear
rubidoux
...
Warning:

The robidoux cubic filter is meant to be used with Clamped EWA (Elliptical Weighted Averaging) resampling, which is different from the way the other cubic filters are generally used.

It is meant to be used with a technique originating from the field of texture mapping, adapted to perform resizing and resampling.
See ImageMagick Examples, the Better and faster image resizing and resampling Libre Graphics Meeting 2011 presentation video as well as http://www.imagemagick.org/Usage/resize/#distort_resize and http://www.imagemagick.org/Usage/resize/#robidoux for details.

This being said, the best Clamped EWA method is the filter known in recent ImageMagick as lanczossharp (IMHO).
That is, "convert -filter lanczossharp -distort resize..." with a very recent version of ImageMagick.

IMHO Clamped EWA lanczossharp is actually a fantastic resizing and resampling filter. Better than anything on your list.

This does not mean that the robidoux filter will "break things" if used like the other bicubic filters. It is just that, the way you are using it, it is not supposed to be very good. Indeed, it is quite blurry.

Last edited by NicolasRobidoux; 3rd June 2011 at 21:40.
NicolasRobidoux is offline   Reply With Quote
Old 3rd June 2011, 22:22   #97  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Hi Nicolas,

nice to see you here, welcome to the forum!

One thing I don't understand is how "Elliptical" has anything to do with simple image up-/downscaling. I mean if there's no perspective transformation, how can there be ellipses? How can it matter whether you use EWA or conventional distance weighting if all ellipses are actually circles?

BTW, how do you like this idea:

http://forum.doom9.org/showthread.php?t=145358
madshi is offline   Reply With Quote
Old 4th June 2011, 00:49   #98  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Copenhagen Denmark
Posts: 269
Quote:
Originally Posted by Archimedes View Post
Thanks for the update. Hermite and Robidoux do not working (unsupported kernels).
Note: Robidoux is a recent addition to ImageMagick.
NicolasRobidoux is offline   Reply With Quote
Old 4th June 2011, 01:04   #99  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Copenhagen Denmark
Posts: 269
Clamped Elliptical Weighted Averaging filters

Quote:
Originally Posted by madshi View Post
Hi Nicolas,

nice to see you here, welcome to the forum!
Hello Madshi.

(I won't be too good of a poster for a bit: I'm reading the threads a bit too fast to make sure all my comments are on target.)

I actually joined Doom9 in March to push some my goods unto unsuspecting passerbys. And lo and behold, some relevant threads just sprouted!
Quote:
One thing I don't understand is how "Elliptical" has anything to do with simple image up-/downscaling. I mean if there's no perspective transformation, how can there be ellipses? How can it matter whether you use EWA or conventional distance weighting if all ellipses are actually circles?...
I could go into a longwinded explanation, but won't.

Let me just say that if you are preserving aspect ratios exactly, then you won't have ellipses: only disks.

If you don't reduce in any of the two directions (for example, if you are enlarging in both directions, or keeping one dimension the same and enlarging in the other), you will get disks, not ellipses.

But if your resize ratio is slightly different horizontally and vertically, and you are downsampling in at least one direction, then you'll get ellipses aligned with the axes instead of disks.

More wishy washy: Your image may have sampled the world on a uniform grid, but the world is not laid out on a uniform grid. Some of the artifacts one gets with common samplers are a consequence of being enslaved to Descartes. Using rotationally invariant samplers takes off these shackles.

But really, the proof is in the pudding:

Install a recent version of ImageMagick and try any resizing task (up/down/mix and match) with "convert -filter lanczossharp -distort resize".

Documentation: http://www.imagemagick.org/Usage/distorts/#resize and http://www.imagemagick.org/Usage/resize/#distort_resize.

If you find something that works, overall, better with natural images, let me know.

(Warning: The Jinc EWA code is going to see some major optimizations this Summer. So will the (regular) tensor Lanczos code.)

Last edited by NicolasRobidoux; 4th June 2011 at 02:12.
NicolasRobidoux is offline   Reply With Quote
Old 4th June 2011, 04:58   #100  |  Link
Mini-Me
Registered User
 
Join Date: Jan 2011
Posts: 121
Quote:
Originally Posted by NicolasRobidoux View Post
Hello Madshi.

(I won't be too good of a poster for a bit: I'm reading the threads a bit too fast to make sure all my comments are on target.)

I actually joined Doom9 in March to push some my goods unto unsuspecting passerbys. And lo and behold, some relevant threads just sprouted!

I could go into a longwinded explanation, but won't.

Let me just say that if you are preserving aspect ratios exactly, then you won't have ellipses: only disks.

If you don't reduce in any of the two directions (for example, if you are enlarging in both directions, or keeping one dimension the same and enlarging in the other), you will get disks, not ellipses.

But if your resize ratio is slightly different horizontally and vertically, and you are downsampling in at least one direction, then you'll get ellipses aligned with the axes instead of disks.

More wishy washy: Your image may have sampled the world on a uniform grid, but the world is not laid out on a uniform grid. Some of the artifacts one gets with common samplers are a consequence of being enslaved to Descartes. Using rotationally invariant samplers takes off these shackles.

But really, the proof is in the pudding:

Install a recent version of ImageMagick and try any resizing task (up/down/mix and match) with "convert -filter lanczossharp -distort resize".

Documentation: http://www.imagemagick.org/Usage/distorts/#resize and http://www.imagemagick.org/Usage/resize/#distort_resize.

If you find something that works, overall, better with natural images, let me know.

(Warning: The Jinc EWA code is going to see some major optimizations this Summer. So will the (regular) tensor Lanczos code.)
Whoa...
A few years ago I was thinking about texture magnification for 3D graphics, and I idly wondered if using the radial distance from source samples might be better for rotational invariance than using traditional resizing kernels...but trying to figure out things like zero crossings made my brain hurt. I'm sooooo happy that someone else actually went forward with the legwork! It's probably still a long way from being put into GPU's, and it isn't used in Avisynth yet either, but it's really cool to see that it exists.

Last edited by Mini-Me; 4th June 2011 at 05:15.
Mini-Me is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:23.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.