-define filter:blur=value with lanczossharp/lanczos2sharp

[NicolasRobidoux]

I suppose we could see this as a "feature," but currently, setting the "blur" value with the filters lanczossharp and lanczos2sharp in the "usual way" implicitly replaces these filters with lanczos and lanczos2.

If you actually want to change the blur with the "sharp" versions of these two filters, you need to use
blur values equal to 0.9549963639785485*blur_you_want with lanczos2sharp, and 0.9812505644269356*blur_you_want for lanczossharp.

[anthony]

Checking...

Code: Select all

convert null: -define filter:verbose=1 -filter LanczosSharp -distort SRT 0 null: | grep '^#'
# Resize Filter (for graphing)
#
# filter = Jinc
# window = Jinc
# support = 3.23832
# win-support = 3.23832
# scale_blur = 0.981251
# practical_support = 3.1776

Code: Select all

convert null: -define filter:verbose=1 -filter LanczosSharp -define filter:blur=0.5 -distort SRT 0 null: | grep '^#'
# Resize Filter (for graphing)
#
# filter = Jinc
# window = Jinc
# support = 3.23832
# win-support = 3.23832
# scale_blur = 0.5
# practical_support = 1.61916

Yeap that is what it does!

That was actually part of the original definition for filter expert settings. ALL the expert settings are complete overrides of resulting settings. I could change it to be a multiplication factor however, but to me that provides less control.

The only time filter:blur define is of practical use to non-expert users is when used with Gaussian-like filters.

[fmw42]

pardon me putting my nose in here. is it practical to build in an internal blurscale that for most filters =1, but for these two have Nicolas's special numbers in them? then multiply the blur value from the define by the internal blurscale?

[NicolasRobidoux]

Anthony:

To me, it is more natural to have blur be a multiplication factor. For one thing, this leads to a uniform treatment of "make all filters smooth twice as much" (for example).

(When I produce smaller versions of the images (but not thumbnails), I am finding that linking the blur to the JPEG quality level works well when the quality level is low: less quality, more blur. And I like the results of using -distort resize with lanczos2sharp and lanczossharp A LOT.)

But I don't have the big picture. You're the boss!

nicolas

[anthony]

The point was these settings replace the existing values so you can design your own filter from scratch.
They were not really 'adjustment' settings.

[NicolasRobidoux]

The point was these settings replace the existing values so you can design your own filter from scratch.
They were not really 'adjustment' settings.

It turns out (and Fred appears to agree) that "stretching" the whole filter is an adjustment which makes a lot of sense in a fairly common situation:

If you have a bunch of lowpass or sharpening filters, you can then tune the "scale" at which smoothing/sharpening occurs "in a uniform way" if blur is a multiplicative factor.

The reason is that there is a clearly defined relationship between the blur value and the frequency response.

In other words: blur, really, is an adjustment setting at heart.

(Again: You have the big picture. I don't. But w.r.t. to blur, specifically, multiplicative factor makes more sense, IMHO, from a user perspective.

I know how to get what I want either way (use lanczos/lanczos2 and scale the blur I want by the values found in the source code to get "correctly" blurred lanczossharp/lanczos2sharp). It's more tricky, though, for half-expert users, and I get paid by one of those.)

[anthony]

If that is how you like it. I don't mind.

I'll make the change in the SVN for the next release.

DONE. IM v6.6.9-6

[NicolasRobidoux]

Thank you Anthony.

[NicolasRobidoux]

Comment:

I've always been suspicious of the current distort filter default, the robidoux filter, because of the identity of its creator.

It turns out that if sharpness is not the only thing you care about (in which case you should use lanczos2sharp or lanczossharp), -distort resize with robidoux = no filter specified produces thumbnails which are both smaller and have less JPEG artifacts (esp. at high compression/low quality) than the other two.

So: Thank you Anthony for not listening to me!

[anthony]

I basically chose Robidoux because it works reasonably well as a general filter, but more importantly it produces minimal color distortion at unity scaling. Unity scaled distortions is very important when using -distort with viewports, and a technique for tiling images (using Virtual Pixel settings), or as a programmable way of setting a viewport crop of an image.

The later technique may not matter as much in IMv7 (which I am working on a CLI "convert"-like replacement), but it is still important. However in such situations you can always switch to a -filter point and interpolated (unscaled) lookup, and bet perfect results. But that is an extra step, and it is important the default is reasonable in all situations. The Robidoux filter does that very well!

Actually any filter is hugely better that what we were seeing with Paul Herbert's HQ-EWA even with the stop gap cut over to interpolated for unity and enlargements. It seems there was even has a incorrect 'sign' in the implementatio that made things worse for some specific perspective views! I just couldn't spot the bug because the old method was so 'fuzzy'

[NicolasRobidoux]

Amazing: The LanczosSharp "sweet spot" is very very close (within .0003) of another sweet spot: The one which makes diagonal lines be preserved when doubling the image. I'll post more when I have time to figure exactly where this other sweet spot is. But this reinforces my feeling that Jinc Lanczos 3 should be used with a blur which is about .98 (this defines the distort LanczosSharp filter.

[NicolasRobidoux]

Amazing indeed:

0.98303932214489908 (the current value) is the blur which minimizes
the change in an image constant on rows (or columns) under no-op.

0.98325192971789548 is the blur which minimizes the oscillations along
the main diagonal when a 1 pixel wide diagonal line is enlarged by a
factor of 2 (when using the distort LanczosSharp filter as a face-split
method).

These values are almost the same (although, in my opinion, the second
one is actually more important than the first in general).

I'll keep checking sweet spots for other archetypes, and I may end up
changing the blur in resize.c.

Of course, the above two are so close that it certainly won't be an obvious
change.

[NicolasRobidoux]

For reference, here is the Axiom (high performance FLOSS computer algebra system) that found the optimal blur for the minimization (actually elimination) of oscillations along the main diagonal for a sharp diagonal line when doubling the density of the image (in both directions: this is "face splitting"):

Code: Select all

)cl a

)se fu ca 9

jinc x == besselJ(1,%pi*x)/x

digits 100

r1 := 3.831705970207512315614435886308160766564545274287801928762298989918839309519011470214112874757423127 / %pi

r3 := 10.17346813506272207718571177677584406981951250019168555611465006811578704378288387382891893264510929 / %pi

l x == if (x<r3) then ( jinc(x) * jinc(x*r1/r3) ) else 0.

c x == [ x, sqrt(2.)*x, 2*x, sqrt(5.)*x, sqrt(8.)*x, 3*x, sqrt(10.)*x, sqrt(13.)*x]

-- z := 2.4674

z := l .000000000000000000000001

g x == ( z + 2 * ( l((c(x)).2) + l((c(x)).5) ) )
  / _
  ( _
  z + _
  4 * _
  ( l((c(x)).1) _
  + l((c(x)).2) _
  + l((c(x)).3) _
  + l((c(x)).5) _
  + l((c(x)).6) _
  + 2 * _
  ( l((c(x)).4) _
  + l((c(x)).7) _
  + l((c(x)).8) ) ) )

d x == [ sqrt(.5^2+.5^2)*x, sqrt(.5^2+1.5^2)*x, sqrt(1.5^2+1.5^2)*x, _
  sqrt(.5^2+2.5^2)*x, sqrt(1.5^2+2.5^2)*x, sqrt(2.5^2+2.5^2)*x ]

h x == ( 2 * ( l((d(x)).1) + l((d(x)).3) + l((d(x)).6) ) ) _
  / _
  ( _
  4 * _
  ( l((d(x)).1) _
  + l((d(x)).3) _
  + l((d(x)).6) _
  + 2 * _
  ( l((d(x)).2) _
  + l((d(x)).4) _
  + l((d(x)).5) ) ) )

e x == g x - h x

oldoptim := 1/0.98303932214489908

[ e(oldoptim+-3*.0001+8*.00001+3*.00000001+9*.000000001+13*.0000000001+3*.00000000001 + 13*.000000000001 + 7*.0000000000001 + 8*.00000000000001 + i*.000000000000001) for i in 8..11 ]

(oldoptim+-3*.0001+8*.00001+3*.00000001+9*.000000001+13*.0000000001+3*.00000000001 + 13*.000000000001 + 7*.0000000000001 + 8*.00000000000001 + 9.5*.000000000000001) 

1/%

0.98303932214489908

%%(-2) - %

[NicolasRobidoux]

I'll leave these things alone for a while: Things are more complicated than they look at first, and basically both the plain distort Lanczos and LanczosSharp are pretty much as good as they can, just as they are.

[anthony]

Fair enough. My own view is that the no-op case having the most minimal filter effect is most important.