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. |
|
|
Thread Tools | Search this Thread | Display Modes |
13th April 2011, 19:00 | #81 | Link |
Registered User
Join Date: Apr 2006
Posts: 299
|
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.
|
14th April 2011, 00:21 | #82 | Link | |
Registered User
Join Date: Sep 2009
Posts: 378
|
Quote:
http://www.yellowspace.webspace.virg...R_400xZoom.png |
|
14th April 2011, 04:03 | #83 | Link | ||
Grand Fruitioner
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
|
Quote:
http://svn.int64.org/viewvc/int64/re...c/kernels.html You'll need a browser that supports HTML5 canvas. Quote:
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. |
||
14th April 2011, 14:34 | #84 | Link |
Registered User
Join Date: Apr 2005
Posts: 213
|
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) >> |
14th April 2011, 18:29 | #85 | Link | |
Registered User
Join Date: Sep 2009
Posts: 378
|
Quote:
Good news, look forward to that all in good time. |
|
15th April 2011, 09:47 | #86 | Link | |
Registered User
Join Date: Apr 2005
Posts: 213
|
Quote:
Bicubic >> Blackman (2 lobes) >> CatmullRom >> Lanczos (2 lobes) >> Spline16 >> |
|
15th April 2011, 11:25 | #87 | Link |
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. |
19th April 2011, 22:10 | #88 | Link | |
Grand Fruitioner
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
|
Quote:
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. |
|
20th April 2011, 21:52 | #89 | Link |
Registered User
Join Date: Dec 2005
Location: Germany
Posts: 1,795
|
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 Last edited by ChaosKing; 20th April 2011 at 21:58. |
22nd April 2011, 02:35 | #90 | Link |
Grand Fruitioner
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
|
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. |
18th May 2011, 00:35 | #92 | Link | |
Registered User
Join Date: Apr 2006
Posts: 299
|
Quote:
Last edited by markanini; 18th May 2011 at 00:39. |
|
18th May 2011, 01:05 | #93 | Link | ||
Grand Fruitioner
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
|
Quote:
Quote:
__________________
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. |
||
20th May 2011, 07:26 | #94 | Link |
Unreasonable User
Join Date: Nov 2003
Posts: 216
|
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.
|
25th May 2011, 01:09 | #95 | Link | ||
Grand Fruitioner
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
|
Quote:
Quote:
__________________
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. |
||
3rd June 2011, 21:37 | #96 | Link | |
Nicolas Robidoux
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
|
the robidoux ImageMagick filter is not supposed to be used this way
Quote:
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. |
|
3rd June 2011, 22:22 | #97 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
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 |
4th June 2011, 01:04 | #99 | Link | |
Nicolas Robidoux
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
|
Clamped Elliptical Weighted Averaging filters
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:
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. |
|
4th June 2011, 04:58 | #100 | Link | |
Registered User
Join Date: Jan 2011
Posts: 121
|
Quote:
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. |
|
|
|