best downsampling method for DSLR photographs

[NicolasRobidoux]

...
BTW, Nicolas, I seem to have missed some of the discussions. What are the objectives behind JincJinc2Radius2 and JincJinc4Radius4?

To make a long story short, when upsampling (or not downsampling), JincNRadiusN scales the Jinc kernel so that the radius of the disk which defines its support is exactly equal to the number of lobes, just like Sinc (for which the support is a square, that is, a disk in max abs norm). So, (de)blur = N / location of the Nth Bessel Jinc zero. There is a wishy washy argument that says that this is good when upsampling. In any case, it sits between the unsharpened Jinc Lanczos and the maximally sharpened one. And, somewhat (un?)surprisingly, it produces an EWA scheme which is close in flavor to the corresponding tensor Sinc Lanczos. (And preliminary quantitative results of my Masters student Adam Turcotte suggest that it is a very good "reconstructor".)
Basically, un-deblurred Jinc Lanczos are considered by most to be too blurry, and the "maximally sharpened" ones (which I call "Sharpest" in the above tests) are arguably too sharp. (The "Sharpening" ones, with blur=sqrt(2)/2, are way too aliased IMHO and are out of the running.) JincNRadiusN are a way of settting a value roughly halfway (for N=3, at least, which is the number of lobes I care most about) between probably too soft and probably too sharp, without being completely arbitrary in the (de)blur choice.
---
Makes some sort of sense?

[NicolasRobidoux]

I mean that the brickwall image from Wikipedia is too blurry and not challenging at all for ImageMagick. Actually, any software failed on that image should be eliminated from Earth.

Anybody cares to create same size downsamples with Photoshop?

[NicolasRobidoux]

I mean that the brickwall image from Wikipedia is too blurry and not challenging at all for ImageMagick.

The brick wall does show mild but noticeable moire with the tested IM schemes.

[NicolasRobidoux]

The photo "Moire_pattern_of_bricks.jpg" is too blurry...

I do agree that we are starting to drift away from what comes straight out of a DSLR.
P.S. ... and the funny thing is that the "full size original" itself appears to have very very mild moire!

[NicolasRobidoux]

Waiting for feedback, and noticing that the Robidoux* schemes give results that I consider pretty good, that every method shows some moire (although someone could argue that this is because I did not pre-filter), and also that some people like the look of (EWA) Catrom (eek!), at least some of the time, I had a

Possibly very good idea

Question: What do -distort Resize Robidoux, RobidouxSharp, Mitchell and Catrom (and actually Cubic as well) have in common?

Answer: They are Keys cubic splines http://www.imagemagick.org/Usage/resize/#mitchell used as EWA (Elliptical Weighted Averagin) filter kernels. Cubic (at the top left of the graph http://www.imagemagick.org/Usage/img_di ... survey.gif) is Cubic B-spline smoothing, which is a pretty good approximation of a pretty strong Gaussian blur, and corresponds to alpha=0. Catmull-Rom (at the bottom) has alpha = 1/2.


In IM, the Keys alpha value is set through the C parameter of the BC-spline generator. Basically, the smaller the C value, the more blurry the result (and the least aliasy); the larger, the sharper (hello moire!).
So, a systematic procedure for downsampling the image and getting something which is just about as sharp as can be but with bearable moire could go as follows:

Start with, say, EWA Catrom (I am assuming you are an Artificial Acutance Addict; if not, start with the default EWA, namely Robidoux, which approximately corresponds to c=.3109, and which you get if you don't specify a filter when using -distort Resize; RobidouxSharp is another good choice by virtue of also carrying my name):

Code: Select all

magick INPUT.IMG -colorspace RGB -filter Catrom -distort Resize WIDTHxHEIGHT -colorspace sRGB OUTPUT.IMG

If you are happy with what you see, pat yourself on the back and return to channel surfing.

Otherwise, search for a better alpha = c value. If you want to be systematic about it, you could use the classic Bisection Method http://en.wikipedia.org/wiki/Bisection_method for finding the c value for which moire+halo = blur (first thing, you must rewrite the equation as moire+halo-blur=0, or blur-(moire+halo)=0 to turn the moire+halo=blur equation into a root finding problem), as follows (you could also just try values, lowering c when there is too much moire, and raising it when you want more sharpness):

Cubic B-Spline, which is just about as blurry as tolerable, is c=0. Catrom, which is just about as halo-y as tolerable, is c=1/2.
Let's try the average, namely 1/4:

Code: Select all

magick INPUT.IMG -colorspace RGB -filter Cubic -define filter:c=.25 -distort Resize WIDTHxHEIGHT -colorspace sRGB OUTPUT.IMG

If there is still too much moire, take the average of 0 and .25:

Code: Select all

magick INPUT.IMG -colorspace RGB -filter Cubic -define filter:c=.125 -distort Resize WIDTHxHEIGHT -colorspace sRGB OUTPUT.IMG

If moire is minimal, and you want to push the sharpness back up, take the average of .25 and .5:

Code: Select all

magick INPUT.IMG -colorspace RGB -filter Cubic -define filter:c=.375 -distort Resize WIDTHxHEIGHT -colorspace sRGB OUTPUT.IMG

Repeat until you're happy or the commercial break is over (this is not an exclusive "or").

[NicolasRobidoux]

To illustrate the process, I've put
http://web.cs.laurentian.ca/nrobidoux/m ... bic.25.png
http://web.cs.laurentian.ca/nrobidoux/m ... ic.125.png
http://web.cs.laurentian.ca/nrobidoux/m ... ic.375.png
along with the other fly downsizes.

P.S. I am renaming the results in terms of the B parameter (see below) of BC-splines instead of the C (=Keys alpha) parameter. They are now
http://web.cs.laurentian.ca/nrobidoux/m ... ubic.5.png
http://web.cs.laurentian.ca/nrobidoux/m ... bic.75.png
http://web.cs.laurentian.ca/nrobidoux/m ... bic.25.png

[NicolasRobidoux]

RE: Probably very good idea
It's actually easier to use the b parameter instead of the c parameter, because b can be understood as the amount of blurring and its usable range is [0,1]: b=1 is maximal reasonable blurring (Cubic B-spline), b=0 is pretty much the minimal reasonable blurring (Catmull-Rom). And then, you get into the high power of 2 denominators at half the speed, and bisection becomes "binary search": the above three tries, rewritten instead of b instead of c, are

Code: Select all

magick INPUT.IMG -colorspace RGB -filter Cubic -define filter:b=.5 -distort Resize WIDTHxHEIGHT -colorspace sRGB OUTPUT.IMG
magick INPUT.IMG -colorspace RGB -filter Cubic -define filter:b=.75 -distort Resize WIDTHxHEIGHT -colorspace sRGB OUTPUT.IMG
magick INPUT.IMG -colorspace RGB -filter Cubic -define filter:b=.25 -distort Resize WIDTHxHEIGHT -colorspace sRGB OUTPUT.IMG

The last one gives a scheme which is not very far from RobidouxSharp (in case you'd want to start your search from something less brutally sharp than Catrom, but still sharp, and you like fractions with power of 2 denominators).

[NicolasRobidoux]

One could argue that the "slider" could have to do with the (de)blur parameter, using, for example Jinc (EWA) Lanczos, but I am pretty sure that the effect of changing the b (or c) value with EWA Cubic is more predictable: Push b up, get more blur/smoothness; Push b down, get more sharpness/halo/moire. In addition, it is my impression that "bad halos" are more unusual with the Keys cubics (which have only 2 lobes) than with methods with a larger number of lobes. My feeling is that with (Keys) Cubic filters, all values of b between 0 and 1 (and probably slightly beyond, either way) give useful and attractive results.
So: It's not about a change in quality, it's about personal preferences, one downsample at a time:
Blur or moire? Choose your poison mix.
(Who says the Wizard wears a white hat?)
It is very possible that another scheme (EWA Jinc Lanczos, in some (de)blurred form) may give a better scheme, but controlling the blur/moire balance through Keys cubics is likely to be much easier than through windowed Sincs or Jincs.

[henrywho]

I remember that cubic calculation are quite a bit faster than, e.g. Jinc, for EWA, right? The time needed for such search should be acceptable.

Indeed, the sharper the source, the less sharp the downsizer should be. If we have some algorithm to evaluate the sharpness, can we have some automatic calculation for "b" like f(source_sharpness, user_preferred_sharpness)?

[NicolasRobidoux]

I remember that cubic calculation are quite a bit faster than, e.g. Jinc, for EWA, right? ...

Because IM uses look up tables, what determines the EWA (-distort Resize) speed is the radius of the disk over which the large image is averaged, which is approximately equal to blur x ( number of lobes ). Very roughly, the runtime is proportional to the square of this radius.
This means that with my proposed "Keys spline slider", the runtime is proportional to 2^2=4.
For Jinc-windowed Jinc methods, it depends on the chosen blur and the number of lobes. Jinc2Radius2 would run in pretty much the same time as an EWA with a Keys spline. Jinc3Radius3 would run in roughly 3^2/2^2 = 9/4 that is about twice more slowly. Jinc3 even more slowly, because it's blur is 1, which is larger than the Jinc3Radius3 blur, but not by a huge amount.
When I have a minute, I'll implement this as an operation in NIP2, with a slider (as mentioned elsewhere, the GUI NIP2 already has direct interfaces to some ImageMagick operations). Then, you can do it interactively, seeing the results show up in the viewer window as you change blur values.
I'll also write the commands that use the "display" option of ImageMagick.

Indeed, the sharper the source, the less sharp the downsizer should be. If we have some algorithm to evaluate the sharpness, can we have some automatic calculation for "b" like f(source_sharpness, user_preferred_sharpness)?

Although a user is likely to fairly quickly figure out what b they like in a given context, figuring out a good algorithm for automatic "b" setting in terms of the input image and downsampling ratio is not something I could do quickly, if at all.
Feel free...

P.S. EWA (-distort Resize) is pretty much always slower than tensor resizing (-resize). It's because -resize exploits "shortcuts" that resizing with a tensor (a.k.a. orthogonal) method affords when transforming a rectangle into a rectangle, shortcuts which are not generally available when using EWA (E=elliptical, not a particularly rectangle friendly shape) methods.

[Pictus]

Indeed, the sharper the source, the less sharp the downsizer should be. If we have some algorithm to evaluate the sharpness, can we have some automatic calculation for "b" like f(source_sharpness, user_preferred_sharpness)?

Although a user is likely to fairly quickly figure out what b they like in a given context, figuring out a good algorithm for automatic "b" setting in terms of the input image and downsampling ratio is not something I could do quickly, if at all.
Feel free...

Use some type of Focus Peaking mode
http://forums.dpreview.com/forums/readf ... 442&page=1
to auto select a small area in focus, create some versions with different values and use some
contrast detect algorithm to choose the good one...

[NicolasRobidoux]

...
BTW, orthogonal box (odd integer ratio) downsizing of real life photos like http://www.dcfever.com/cameras/enlarge.php?id=6967 is generating moire patterns.
...

What ratio did you use that showed moire?

The reason I'm asking is because when I use box filtering to downsample an image, I always pre-crop so that the whole image is an exact multiple of the box.
In other words, my final width always divides the original width exactly, and the final height always divides the original height exactly.
I do this to minimize artifacts, moire included.
So, if you saw (lots of) moire because you used a ratio that does not divide exactly the original dimensions in both directions, I am not surprised at all.

P.S. I just checked: Indeed box filtering by 3 of a crop to multiples of 3 in both directions shows moire.
I'm really happy now that none of the images in the test image bank I prepared is moire prone.

P.S. 2 Henry, I am truly very thankful for all your feedback and help.

P.S. 4 Ah! It has nothing to do with odd/even: Box down by an exact ratio of 4 in both directions shows significantly more moire than with 3. Basically, box filtering, even with exact ratios, is not a good low pass filter, period. I was concerned that my judgement call that I could ignore the 2x2 structure of most Bayer arrays could be ignored. It appears that it can. How badly box filtering filters, can't.

P.S. 5 What box filtering is good at is not introducing too many "artificial colours" without being too blurry.

[Pictus]

I prefer the backpack texture with orthogonal, at least when resizing to 1200...
convert INPUT -filter Lanczos -define filter:lobes=4 -define filter:blur=0.88451002338585141 -resize 1200x1200 OUTPUT
or
convert INPUT -filter Lanczos -define filter:blur=0.88549061701764 -resize 1200x1200 OUTPUT

[henrywho]

P.S. I just checked: Indeed box filtering by 3 of a crop to multiples of 3 in both directions shows moire. I'm really happy now that none of the images in the test image bank I prepared is moire prone.

But apartment.tif is alias-prone.

P.S. 2 Henry, I am truly very thankful for all your feedback and help.

Hey, we can't live without your great ideas and works, as well as IM team's implementation.

P.S. 4 I was concerned that my judgement call that I could ignore the 2x2 structure of most Bayer arrays could be ignored. It appears that it can. How badly box filtering filters, can't.

Perhaps it's because that backpack sample is produced by a full-frame-sized sensor that doesn't have any AA-filter .
http://www.dpreview.com/products/nikon/slrs/nikon_d800e

[NicolasRobidoux]

... But apartment.tif is alias-prone.

Do you see problems with the downsample of the apartments image I put in the test image bank? If you do (please explain), I may redo it. http://web.cs.laurentian.ca/nrobidoux/m ... tments.tif
P.S. Flooded with TODOs from all directions (including Spring Cleaning). Nonetheless, please let me know if you see problems with any of the test images. Note that I have my own criterions for "most problematic artifact" and the proper mix of defects; I'll listen, but I may not "obey".