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 5th June 2011, 04:10   #121  |  Link
markanini
Registered User
 
Join Date: Apr 2006
Posts: 299
Quote:
Originally Posted by *.mp4 guy View Post
Browser interpolation is notoriously terrible. Anything anyone would normally consider using would be better.
I neglected to mention my browser induced artifacts we're similar to what I got using anything else inside or outside of Avisynth that didn't cause significant blurring. So in this case I found a exception to your resoning, which I agree with in general, in favor of EWA Robidoux. For the first time I can at least view this image at arms length from my screen and not be too annoyed. Not to kiss mr. Robidoux ass, I'd be glad to hear about anything else that might benfit this image, which AFAIK is unlikely unless a better NNEDI3 or better deconvolution sharpening becomes available which is nothing I'll hold my breath for. I'll leave it at that.

Last edited by markanini; 5th June 2011 at 04:15.
markanini is offline   Reply With Quote
Old 5th June 2011, 04:11   #122  |  Link
*.mp4 guy
Registered User
 
*.mp4 guy's Avatar
 
Join Date: Feb 2004
Posts: 1,348
Quote:
Originally Posted by NicolasRobidoux View Post
I should not make much difference.

Also:

EWA Robidoux only requires about 4pi/16 of the input values required by orthogonal bicubic or Lanczos 2 filtering (or interpolation if you are enlarging). Note that 4pi/16 < 1.

EWA Jinc Lanczos 3 and EWA Jinc Lanczos 3 "sharp" require a little more than 9pi/36 of the input values required by orthogonal Lanczos 3 filtering. Again, 9pi/36 < 1.

That is: Generally, EWA resizing methods use less input data than comparable orthogonal resize methods.

(The above estimates are for reducing. They are pretty rough for enlarging. When I have more time, I'll compute the exact ratios when enlarging. But the gist is correct.)
Presumably you are talking about orthogonal linear interpolation as if it was carried out on a two dimensional area, This is not the case, As I believe was mentioned in reference to the superiority of ewa filters.

A 2 lobe orthogonal linear interpolator would typically require 7.5 total input pixel operations per input pixel (IPOPIP's) for a 2:1 downscale, as implemented by a separable filter, whereas it would take 25 IPOPIP's if implemented as a 2 dimensional filter. I cannot see how a viable 2 lobed interpolation kernel could be implemented with less then 7.5 IPOPIP's, though 25 IPOPIP's is an easily bested number.

Its possible I have misunderstood you due to differing conventions, but that's how it hashes out after everything is broken down into convolution operations.

[edit}
Quote:
Originally Posted by markanini View Post
I neglected to mention my browser induced artifacts we're similar to what I got using anything else inside or outside of Avisynth that didn't cause significant blurring. For the first time I can at least view this image at arms length from my screen and not be too annoyed. Not to kiss mr. Robidoux ass, I'd be glad to hear about anything else that might benfit this image, which AFAIK is unlikely unless a better NNEDI3 or better deconvolution sharpening becomes available which is nothing I'll hold my breath for. I'll leave it at that.
What exactly is your desired use case for this image? are you trying to make it as large as the nnedi3/deconvolution image, or trying to make it as large as the Robidoux downscale? the whole thing doesn't make much sense to me.

Last edited by *.mp4 guy; 5th June 2011 at 04:17.
*.mp4 guy is offline   Reply With Quote
Old 5th June 2011, 14:10   #123  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
There indeed seems to be some misunderstanding going on here.

First, my "I(t) should not make much difference" (yes, there was a typo, a missing "t") was an answer to henryho_hk 's question "Since EWA distort involves much more pixels than normal resizers, may I presume that there is a greater need to "linearize" the image beforehand?", which I understood as concerning the use of linear light.

In this context, I was not counting flops---flop-wise, an EWA method is definitely more expensive than a comparable separable method implemented accordingly---I was counting the raw number of values that are combined to get a single output value.

Let's compare, say, the typical number of pixels "averaged" to get an orthogonal Lanczos 2-lobes or Bicubic (Keys filtering or cubic B-Spline smoothing, say) filtered output value when downsampling by a factor of 2 in both directions, to the number required by Clampled EWA Robidoux of Jinc Lanczos 2.

Note also that I am filtering, not interpolating. If you are doing a 2:1 downscale by interpolating, you are begging for moire and jaggies. Not as much if you filter. So, generally, I don't recommend using interpolation in and by itself when downsampling. (Of course, you could low pass the original with, for example, box filtering, and then interpolate, but this is not what I'm comparing. I'm looking at using exactly one filter to do the downsampling. Please clarify if I am missing something.)

For simplicity, I'll consider an output pixel value located at the average of four nearby input pixel locations ("interlaced," kind of). I could also consider other locations, to get a typical value.

With the orthogonal versions, you are grabbing everything that falls strictly within a (2*4)x(2*4)=8x8 square centered at the output location. This is 64 pixel values.

With the EWA versions, you are grabbing everything that falls within a disk of radius 2*2=4 (actually, EWA Jinc Lanczos 2 extends slightly past radius 2; I'll ignore this for now; I like Robidoux more anyway). A little programming establishes that there are 52 such pixel locations.

Compare this to my earlier estimate:

52/64 = .81

4pi/16 = .79

Pretty close.

(Yes, I understand that I should consider other possible locations for the output pixel and average the counts. I need coffee.)

-----

P.S. It finally dawned on me what IPOPIP count is. I'll do THAT count in a future post.

Quote:
Originally Posted by *.mp4 guy View Post
Presumably you are talking about orthogonal linear interpolation as if it was carried out on a two dimensional area, This is not the case, As I believe was mentioned in reference to the superiority of ewa filters.

A 2 lobe orthogonal linear interpolator would typically require 7.5 total input pixel operations per input pixel (IPOPIP's) for a 2:1 downscale, as implemented by a separable filter, whereas it would take 25 IPOPIP's if implemented as a 2 dimensional filter. I cannot see how a viable 2 lobed interpolation kernel could be implemented with less then 7.5 IPOPIP's, though 25 IPOPIP's is an easily bested number.

Its possible I have misunderstood you due to differing conventions, but that's how it hashes out after everything is broken down into convolution operations.
...

Last edited by NicolasRobidoux; 5th June 2011 at 15:06.
NicolasRobidoux is offline   Reply With Quote
Old 5th June 2011, 14:18   #124  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
If the question is: "Will an EWA method run as fast for resizing as a comparable separable method?", the answer is "No."

As far as the method I'm promoting (Clamped EWA Jinc lanczossharp, which is not the same as Clamped EWA Robidoux) goes, the filter kernel's support is a disk with radius slightly larger than 3. We are certainly not talking about greased lightning.

Last edited by NicolasRobidoux; 5th June 2011 at 15:10.
NicolasRobidoux is offline   Reply With Quote
Old 5th June 2011, 16:14   #125  |  Link
*.mp4 guy
Registered User
 
*.mp4 guy's Avatar
 
Join Date: Feb 2004
Posts: 1,348
Quote:
Originally Posted by NicolasRobidoux View Post
Note also that I am filtering, not interpolating. If you are doing a 2:1 downscale by interpolating, you are begging for moire and jaggies. Not as much if you filter. So, generally, I don't recommend using interpolation in and by itself when downsampling. (Of course, you could low pass the original with, for example, box filtering, and then interpolate, but this is not what I'm comparing. I'm looking at using exactly one filter to do the downsampling. Please clarify if I am missing something.)
(lowpass) Filtering and interpolation are functionally the same in this case, they both are carried with the same operation.
*.mp4 guy is offline   Reply With Quote
Old 6th June 2011, 04:25   #126  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
Assuming I understand correctly what IPOPIP is, with the geometry I described in my earlier post, an orthogonal two-lobe filter will require 4 IPOPIP to downsample by a factor of 2 in a data driven implementation exploiting separability, and an EWA two-lobe filter will require 13 in the same context. (A bit shaky on the computation but I think I got the drift.)

Last edited by NicolasRobidoux; 6th June 2011 at 15:29.
NicolasRobidoux is offline   Reply With Quote
Old 6th June 2011, 05:27   #127  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
I love EWA when processing still photos.... though it may be too luxurious for video processing.
henryho_hk is offline   Reply With Quote
Old 23rd June 2011, 02:03   #128  |  Link
PhrostByte
Grand Fruitioner
 
PhrostByte's Avatar
 
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
Here's version 7. Mostly optimizations -- significantly faster on my Core 2 Quad, I'm curious to see how it performs versus v6 on a >4 core CPU, and ones with AVX capability. Also includes kernel visualizations.

http://sourceforge.net/projects/int6...7.zip/download

Changelog:
  • Multi-core optimizations.
  • SSE/AVX vertical resampler.
  • AVX implementations of all conversions.
  • Optimizations to SSE RGB conversions.
  • Significant memory use reduction and minor optimizations to dithered RGB output.
  • Better compatibility with Avisynth built-in resizers.
  • Add kernel visualization docs.
  • Remove 64-bit version temporarily.

Going to look at EWA for next version, as well as figure out why 64-bit is crashing Avisynth.
__________________
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 23rd June 2011, 17:12   #129  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
Gamma-aware EWA? Woh!
henryho_hk is offline   Reply With Quote
Old 23rd June 2011, 17:22   #130  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
Quote:
Originally Posted by PhrostByte View Post
...
Going to look at EWA for next version, as well as figure out why 64-bit is crashing Avisynth.
FYI

1) The ImageMagick code implementing the best (IMHO) upsampling EWA filter, namely lanczossharp, uses a somewhat slow method of computing the weights. My student Chantal Racette and I will be putting together a faster way of doing this this Summer.

2) There is a very simple EWA implementation (using the teepee, that is, cone filter, which is not very good for upsampling) currently being built into a GEGL method. Its code is sufficiently advanced to be poached. The source code is found here: http://git.gnome.org/browse/gegl/tre...mpler-lohalo.c

Further developments are found in the samplers branch.

You may also contact me directly (or post here) if you have questions.

Last edited by NicolasRobidoux; 24th June 2011 at 11:48.
NicolasRobidoux is offline   Reply With Quote
Old 24th June 2011, 01:02   #131  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
PhrostByte, I have a suggestion on the kernel visualiization html.

The kernel names are now taking too much vertical space. Can they be arranged in columns like a table?
henryho_hk is offline   Reply With Quote
Old 24th June 2011, 11:56   #132  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
PhrostByte:

Suggestion if you are going to implement EWA in a "scanline friendly" environment for resizing:

Resize to a nearby or larger resolution which is a power of two (so that the EWA coefficients can be recycled every so many scanlines) and finish with an other scheme (bilinear, even).
NicolasRobidoux is offline   Reply With Quote
Old 24th June 2011, 19:31   #133  |  Link
PhrostByte
Grand Fruitioner
 
PhrostByte's Avatar
 
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
Quote:
Originally Posted by NicolasRobidoux View Post
FYI

1) The ImageMagick code implementing the best (IMHO) upsampling EWA filter, namely lanczossharp, uses a somewhat slow method of computing the weights. My student Chantal Racette and I will be putting together a faster way of doing this this Summer.

2) There is a very simple EWA implementation (using the teepee, that is, cone filter, which is not very good for upsampling) currently being built into a GEGL method. Its code is sufficiently advanced to be poached. The source code is found here: http://git.gnome.org/browse/gegl/tre...mpler-lohalo.c

Further developments are found in the samplers branch.

You may also contact me directly (or post here) if you have questions.
EWA looks pretty much how I imagined it, just using the basic distance formula to find the sample distance passed to the kernel.

All the Jinc function stuff is completely greek to me, though

Quote:
Originally Posted by NicolasRobidoux View Post
PhrostByte:

Suggestion if you are going to implement EWA in a "scanline friendly" environment for resizing:

Resize to a nearby or larger resolution which is a power of two (so that the EWA coefficients can be recycled every so many scanlines) and finish with an other scheme (bilinear, even).
I think a significant portion of EWA can be implemented with SIMD, so I should be able to get it pretty fast without sacrificing any quality.

Quote:
Originally Posted by henryho_hk View Post
PhrostByte, I have a suggestion on the kernel visualiization html.

The kernel names are now taking too much vertical space. Can they be arranged in columns like a table?
I've been trying to find a better place to put them for a while, to no avail. They should arrange into columns already on Firefox/WebKit.
__________________
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 24th June 2011, 19:37   #134  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
Clarification RE: something I wrote earlier: ImageMagick does use efficient formulas for the computation of the jinc 1 function. However, current research will lead to even faster approximations of the best radial kernels, most likely within two months or so.
NicolasRobidoux is offline   Reply With Quote
Old 24th June 2011, 19:40   #135  |  Link
NicolasRobidoux
Nicolas Robidoux
 
NicolasRobidoux's Avatar
 
Join Date: Mar 2011
Location: Montreal Canada
Posts: 269
Quote:
Originally Posted by NicolasRobidoux View Post
Clarification RE: something I wrote earlier: ImageMagick does use efficient formulas for the computation of the jinc 1 function. However, current research will lead to even faster approximations of the best radial kernels, most likely within two months or so.
... in particular, there will be no need for square roots of the distances: short polynomial expansions will use x^2+y^2 (x is horizontal distance between data point and sampling point, y is vertical distance) directly, and there will be no need to compute jinc1 twice (once for the filter, once for the windowing function).
NicolasRobidoux is offline   Reply With Quote
Old 25th August 2011, 05:08   #136  |  Link
PhrostByte
Grand Fruitioner
 
PhrostByte's Avatar
 
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
Version 8. Again, mostly optimizations—overall 2–3x as fast as v7, and in particular resizing RGB is actually slightly faster than Avisynth's gamma-ignorant resizers.

http://sourceforge.net/projects/int6...8.zip/download

Changelog:
  • RGB8-specialized gamma corrections—15% faster color conversions.
  • New gamma correction approximations—200% faster color conversions.
  • SSE horizontal resampler—25% faster resizing.
  • Cache optimizations to vertical resampler—10% faster resizing.
  • Experimental (untested) FMA4 color conversions for AMD Bulldozer.
  • Reduced memory usage.
  • Remove automatic multithreading in favor of SetMtMode.
  • Bug fix: handle very tiny row widths.

64-bit is still not working. I am very puzzled by this—the error "Evaluate: Unrecognized exception!" is happening outside of my code: after AvisynthPluginInit2 finishes successfully and before GetFrame is called. Any devs with 64-bit plugins have some advice?
__________________
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.

Last edited by PhrostByte; 25th August 2011 at 22:25.
PhrostByte is offline   Reply With Quote
Old 25th August 2011, 05:59   #137  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
New version! Woh!
henryho_hk is offline   Reply With Quote
Old 27th August 2011, 01:17   #138  |  Link
SubJunk
Registered User
 
Join Date: Jun 2010
Posts: 443
Thanks a lot for the update
SubJunk is offline   Reply With Quote
Old 13th September 2011, 07:12   #139  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
V8 is giving black screen my computer upsizing 720x480 YV12 source to 1280x720. XP 64bit + Avisynth x86 DLL 2.6.0.2, dated 2011/05/25.

Now I am trying to isolate the test case.

Edit: No more problems with SEt's 2.6 MT 2011.09.13

Last edited by henryho_hk; 27th September 2011 at 03:01.
henryho_hk is offline   Reply With Quote
Old 2nd November 2011, 22:55   #140  |  Link
killazys
Registered User
 
Join Date: Sep 2011
Posts: 29
Question... is resizing/colorspace correction related to the bit depth? As in, Hi10P vs. 8bit? And.. if I'm going to be resizing from 1080p to 720p with no colorspace changes, what's the purpose of "gamma-awareness?" Am I missing something?
killazys 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 00:40.


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