proper scaling of the Jinc filter for EWA use

[NicolasRobidoux]

As indirectly stated in http://www.ipol.im/pub/algo/g_roussos_d ... erpolation and I'd bet anything it's figured out by many people, maybe the "proper scaling" should match the level of blurriness in the source image: more blur -> smaller radius.
Idea: One could automatically estimate the blur in the ROI and select the EWA (de)blur to match...

[fmw42]

As indirectly stated in http://www.ipol.im/pub/algo/g_roussos_d ... erpolation and I'd bet anything it's figured out by many people, maybe the "proper scaling" should match the level of blurriness in the source image: more blur -> smaller radius.
Idea: One could automatically estimate the blur in the ROI and select the EWA (de)blur to match...

How do you estimate or measure the amount of blur in an image with no reference to a sharp image?

[NicolasRobidoux]

Fred: I don't really know about this, but Pictus (Luiz) does: viewtopic.php?f=1&t=20992&p=85114#p85114.
Also, maybe something kind of like Data Dependent Lanczos: http://www.general-cathexis.com/.
We could use spectral analysis of the image? http://www.normankoren.com/Tutorials/MTF.html

[fmw42]

Fred: I don't really know about this, but Pictus (Luiz) does: viewtopic.php?f=1&t=20992&p=85114#p85114.

Thanks, the first one looks interesting.

[NicolasRobidoux]

Just discovered that windowing Jinc with Hann gives very similar results than with Jinc (by way of LanczosSharp).
With a bit less halo.
How close? Better? Worse? Tuneable?
Don't know yet.
I did not expect LanczosSharp to be improved upon. Now, maybe.

[NicolasRobidoux]

I just discovered that the Bessel functions on my install of the computer algebra system Axiom are not particularly precise.
At some point, I'm going to have to redo everything with the Boost C++ library.

[NicolasRobidoux]

Anthony:
I think that "RadiusN", that is, the option to specify that the radius of a windowed JInc is exactly the number of lobes, should be added to ImageMagick for EWA methods.
I do not think that I will find a "better overall method" (besides the two ways of defining LanczosNSharp, which, except for Lanczos2Sharp, give deblurs close to 1, hence a bit too soft for some people) of choosing a deblur.
The main reason why "RadiusN" is a good choice can be explained as follows: If you enlarge an image only in one direction, the number of scanlines needed to compute an output scanline is constant across the entire scanline. It does not "include two extra ones, then drop them, include two extra ones, then drop them, ..." which having a radius just a touch larger than "RadiusN" will do. Of course, the coefficients of the pixels in the "two extra scalines that are intermittently included" are basically zero. But I'd rather have them be exactly zero.
The other reason is that Lanczos Radius 3 is actually a decent clone of, for example, tensor Ginseng.
So, if you believe that tensor Sinc methods are a good thing, this should extend to the "Radius N" EWA windowed Jinc methods.
-----
I realize you're busy. I'm busy too.
I'm not making a forceful, or impatient, request.
I am just expressing a fairly solid opinion, which I now see unlikely to change.

[anthony]

Can you give me the exact settings (formulas) you would use to define a "LanczosRadius" filter for EWA usage.

I'd like it to include support for the lobes setting (default is 3) which is why I did not include '3' in the above. I mean it is not a very specifically calculated filter, as it is for the 'Sharp' filters, but can just use the table of lobes to support values that IM has built into it (for the first 20 lobes), and as such can be made more 'adjustable'.

I know for tensor (resize) this would be equivalent to the default Lanczos as lobes = support when the Sinc function is used, so for non-EWA use it is equivalent to straight Lanczos.

[NicolasRobidoux]

Formula is the same for all windowed Jincs, irregardless of the chosen window function (which of course is Jinc by default): (de)blur = N / Nth rooth where N is the number of lobes (default 3).
So, for a 2-lobe Jinc, blur = 2 / 2.2331305943815286 = 0.89560368974027928171
For a 3-lobe Jinc, blur = 3 / 3.2383154841662362 = 0.9264075766146068, which is a value you've seen a lot in my posts.
For a 4-lobe Jinc, blur = 4 / 4.2410628637960699 = 0.94315979943284770707
etc.
As N increases, the deblur approaches 1.
These numbers are stored in the jinc_zeros array. You just divide them by the index within the array, adding 1 (because of C indexing convention, which starts at 0, which gives the first root).
So, the recipe is: If filter:filter=Sinc, do nothing. If filter:filter=Jinc, set the blur to lobes/jinc_zeros[lobes+1].
Clear?

[NicolasRobidoux]

Indeed, for tensor windowed Sincs, (de)blur=1 across the board, because Nth root = number of lobes, so their ratio is exactly 1.

[NicolasRobidoux]

Really, the desired behavior does not depend on whether you EWA or tensor.
It depends on the filter.
If filter:filter=Jinc, deblur so that the radius of the disc matches the number of lobes.
If filter:filter=anything else (including Sinc), do nothing.
Of course, if you call this LanczosRadius, it may be somehow tied to EWA/not EWA or what not.
But it would be maximally useful if it was tied to Jinc being the multi-lobe low pass filter. (Which I suppose can happen by choosing LanczosRadius and then changing the window function.)

[anthony]

Formula is the same for all windowed Jincs, irregardless of the chosen window function (which of course is Jinc by default): (de)blur = N / Nth rooth where N is the number of lobes (default 3).

Okay added filter LanczosRadius.
Which is just a normal Lanczos, but after the support has been set, from either 'support' or 'lobes' (typically the latter), adjusts the blur factor (for EWA, jinc case) so that blur *= floor(support)/support.

In otherwords, the filter is always blurred so as to have a integer support.
That means if 'lobes' is used that many lobes will fit into an integer support of that size.

Other than adding the filter the code was just one if (the filter) and one blur adjustment.

Note blur is multiplied, so you can blur it further from that point

Code: Select all

convert xc: -define filter:verbose=1 -filter LanczosRadius -define filter:lobes=2 -distort Resize 200% null: | grep '^#'
# Resize Filter (for graphing)
#
# filter = Jinc
# window = Jinc
# support = 2.23313
# window-support = 2.23313
# scale-blur = 0.895604
# practical-support = 2

convert xc: -define filter:verbose=1 -filter LanczosRadius -distort Resize 200% null: | grep '^#'
# Resize Filter (for graphing)
#
# filter = Jinc
# window = Jinc
# support = 3.23832
# window-support = 3.23832
# scale-blur = 0.926408
# practical-support = 3


convert xc: -define filter:verbose=1 -filter LanczosRadius -define filter:lobes=4 -distort Resize 200% null: | grep '^#'
# Resize Filter (for graphing)
#
# filter = Jinc
# window = Jinc
# support = 4.24106
# window-support = 4.24106
# scale-blur = 0.94316
# practical-support = 4

[NicolasRobidoux]

Thank you.
I suppose I could have explained it that way: Set the "practical support" equal to the number of lobes.

[anthony]

Thank you.
I suppose I could have explained it that way: Set the "practical support" equal to the number of lobes.

That is just implementation mechanics. IM needs to know as it has to do the reverse. Use the blur factor on the given 'distance' from the sample point and feed that to the mathematical functions.

practical support is not actually used, just calculated for the verbose output as a guide for range when graphing the filter function results.

[NicolasRobidoux]

...
In otherwords, the filter is always blurred so as to have a integer support.
That means if 'lobes' is used that many lobes will fit into an integer support of that size...

Yet another way to explain indeed: (de)blur to make the Jinc function have integer support.