Legacy ImageMagick Discussions Archive

The compound eyes of http://upload.wikimedia.org/wikipedia/c ... rtrait.jpg seems really a tough case. Down-sampling it to 480x720 and under different algorithms there may be:

a) moire patterns on the compound eyes
b) increase in overall brightness (probably due to haloing)
c) lose of rainbow-shine
d) aliasing on the hairs or, in contrast, blurriness of the hairs

henrywho wrote:The compound eyes of http://upload.wikimedia.org/wikipedia/c ... rtrait.jpg seems really a tough case...

I love this test image. I have contacted the author (we can't live with jpeg compression).

NicolasRobidoux wrote:(we can't live with jpeg compression)

But you cannot avoid JPEG compression in the real world. As the JPEG engines of digital cameras (dSLR, NEX, m43, compacts or even mobiles) improve, fewer and fewer peoples want to bother with RAW files.

henrywho wrote:

NicolasRobidoux wrote:(we can't live with jpeg compression)

But you cannot avoid JPEG compression in the real world. As the JPEG engines of digital cameras (dSLR, NEX, m43, compacts or even mobiles) improve, fewer and fewer peoples want to bother with RAW files.

I believe that Nicolas is doing testing for the purpose of developing and comparing upscaling and/or downscaling algorithms, looking for the best techniques quality-wise. So he does not want to confuse the issue with jpg quality losses.

I have added RobidouxSharp to both IMv6 and IMv7, and updated IM Examples with a short summary, and plotted it on the 'Mitchell-Netravali Survey' diagram.
(better late than never )

If 'RobidouxSharp' appears in the above image, then the examples have updated

NicolasRobidoux wrote:(Totally unrelated: 10 cm of fresh snow in my backyard and it's still snowing hard. Can I move to Brisbane? It's "Spring", here.)

I don't know about that. It is autumn here, and the weather is cycling between continuous rain and sunny periods, as the seasons change. Once things settle our winters are bone dry with clear 'icy-blue' skys, but then in summer we get very sever thunder storms in the evening, with an occasional cyclone (hurricane for you northerners) thrown our way for good measure.

This morning was very heavy fog, which only happens maybe once a year!

NicolasRobidoux wrote:

henrywho wrote:The compound eyes of http://upload.wikimedia.org/wikipedia/c ... rtrait.jpg seems really a tough case...

I love this test image. I have contacted the author (we can't live with jpeg compression).

If you can get a PNG image please let me know. It is a good picture for testing Resize Filters.

NicolasRobidoux wrote:Suggestion: Unless you fall in love with RobidouxSharp, why don't you switch the EWA default back to Mitchell?

Actually I am quite happy with Robidoux filter as a default for Distort. Remember Distort often enlarges as well as shrinks. I also find it more comforting that it was 'designed' rather that 'guesstimated' using a survey as "Mitchell-Netravaili" filter was. Though I still thing it amazed that the survey produced a filter that was not only good for orthogonal (tensor) resizing but also Cylindrical EWA distortions!

henrywho wrote:But you cannot avoid JPEG compression in the real world.

What the test suite does is pretty simple minded (but lots of people do it): Reduce a "gold standard" image, re-enlarge it, and compare. Although many scholarly articles treat such reconstruction tests as being conclusive, they are not. However, they are informative. The rotation tests are also not really conclusive, but they are also informative. (We did not implement those.)
Although the suite (which will be called EXQUIRES: Evaluative eXtensible QUantitative Re-Enlargement Suite) will be fully configurable (you can plug in metrics, test images, upsamplers, downsamplers), I had to make judgement calls as to what "plain vanilla" should be, as well as which questions we'd try to answer in Adam Turcotte's thesis. One important judgement call is that I decided to only use the image geometry convention that ImageMagick uses: align corners.
I decided against JPEG "gold standard" images because I do not want upsamplers to be rewarded for reproducing JPEG artifacts. Of course this could be said of demosaicing artifacts and whatever noise is left in the gold standard, as well as the artifacts that come from mild box downsampling, but again, I had to make reasonable judgement calls to get things moving. (The clock is ticking...)
What would be interesting would be to downsample "gold standard" images (not JPEG), compress them with JPEG, re-enlarge to uncompressed TIFF (or PNG), and compare. What this would measure is the ability of the upsampler to "correct" JPEG artifacts, or at least robustly handle them. Alternatively, downsample a JPEG compressed version of the gold standard, re-enlarge the result, and compare to the gold standard. This would, to an extent, mimick re-enlarging an image downsized from that comes out of common digital camera toolchains.
Similarly, one could add noise to the downsampled images.
Manana.
But not necessarily by us: The PyPi suite will (hopefully soon) be packaged as a DEB, so it should install and configure painlessly on Debian, Ubuntu, and Mint.
By popular demand, Adam may add other OSes. Our hope is that it's going to become the standard software whenever a scholar decides to do re-enlargement tests.
If someone would like to be an alpha tester, contact me.

anthony wrote:...I also find it more comforting that it was 'designed' rather that 'guesstimated' using a survey as "Mitchell-Netravaili" filter was...

I forget what it was because it's something I figured out and never saw published anywhere, but I believe that in the tensor (orthogonal) world there is something special about Mitchell-Netravali. I'll add to my to do list to re-figure it out. It's something like the result of averaging (straight averaging) the cubic B-spline and Catmull-Rom, or something like that. Catmull-Rom itself is obtained by box filtering the most natural local quadratic histospline (if I remember right: I try a lot of stuff, and move on if I don't think it's particularly useful, and if I don't use it I forget). Of course it's also the only interpolatory Keys cubic, and Keys cubics are the BC-splines that exactly reproduce affine gradients (when used in the tensor way), a pretty clean and attractive definition.
Hopefully I'm not making up forgotten non-recollections... (Maybe I should go into politics?)

This being said, it is true that Robidoux and RobidouxSharp are produced directly from EWA considerations: First, figure that the Keys cubics are the BC-splines which reproduce affine gradients the most accurately when used as EWA filers, and then among them choose the ones that minimize the maximum possible change in vertical or horizontal straight lines (Robidoux) or any image (RobidouxSharp) under no-op.

anthony wrote:If 'RobidouxSharp' appears in the above image, then the examples have updated

It seems the RobidouxSharp filter is not available in 6.7.6-7 (win32 dynamic).

anthony wrote:If 'RobidouxSharp' appears in the above image, then the examples have updated

What Anthony meant is that the ImageMagick Examples documentation was updated.
RobidouxSharp has only been available in the svn repo since late Sunday, and in the alpha source releases (for IM 7.0.0, which is still a work in progress) since Monday (or so). To get RobidouxSharp without hardwiring the C value with -define, you need the bleeding edge of the bleeding edge. Otherwise, usewhich itself requires IM recent enough to understand -distort Resize.
Warning: Because IM7 is a major rewrite, the bleeding edge of the bleeding edge is a bit more bloody than usual.

IM v6.7.6-8 should have been released.

Yesterday I used the ANZAC public holiday (tribute day to Australian and New Zealand war veterans) to trace the bug in Variable Blurring. This discovered that the 'Gaussian' Filter was using a Sigma of about 0.25 (not exact) instead of 0.5.

The cause was some stupid programming faults (the code reads okay, but two if statements always comes out as true!). This stuffed up the 'sigma expert setting', and resulted in a incorrect default value for sigma being used. This was compounded by the verbose filter report summary not showing the fault!

As such Gaussian Filters were not blurry enough, and acted more like a 'hermite', ever since user sigma control was added (Feburary Last year, IM v6.6.7-6)

This will be release with the next IM release.

Fix is as always both IMv6 (bleading) and IMv7 (bloody bleeding)

Now if I can just prevent filter expert settings effecting variable blurs, AND allow it to NOT use a 0.5 blur on image area that should have 'No Blur' according to the variable blur mapping! The later is causes by EWA 'minimal radius' handling, which is needed for resampling but not for blurring. It is what I get for 'abusing' EWA resampling to do per-pixel blurring.

@Anthony:

Because it was too aliased when downsampling, I had Adam increase the sigma in his thesis code (based on bleeding bleeding edge) to sigma=1/sqrt(2), the other value recommended by Turkowski for upsampling or downsampling, I don't remember. We're using "orthogonal" Gaussian blur resizing (-resize, not -distort Resize).

Should I have him revert to plain vanilla IM Gaussian blur now because otherwise it's going to be too blurry?

NicolasRobidoux wrote:@Anthony:

Because it was too aliased when downsampling, I had Adam increase the sigma in his thesis code (based on bleeding bleeding edge) to sigma=1/sqrt(2), the other values recommended by Turkowski for upsampling or downsampling, I don't remember. We're using "orthogonal" Gaussian blur resizing (-resize, not -distort Resize).

Should I have him revert to plain vanilla IM Gaussian blur now because otherwise it's going to be too blurry?

This fix applies to the Gaussian filter, irrespective of if it is used in -resize or -distort, or even variable blurs.

So YES you should inform him! The 'fix' you suggested was also wrong, though quite close!

Using -define filter:sigma would have been ignored before this fix.
But the gaussian sigma was still adjustable using -define filter:blur

What was happening was that the value of the pre-calculated constant 1.0/(2.0*sigma*sigma)
which for sigma = 0.5 should come out to a value of 2.0
was being overridden by the default for the Kaiser filter alpha value (6.5)
Thus due to the bug Gaussian was using a value of sigma = sqrt(1.0/(2.0*alpha)) => 0.27735
Approximately half what it should have been (roughly)

As such with your fix (multiply by 2.0/sqrt(2) to convert 0.5 to 1/sqrt(2) ) he has been using a gaussian sigma of .39223 still too sharp but a little more blurry than what I call a Gaussian Interpolator (sigma=0.375)
http://www.imagemagick.org/Usage/resize ... terpolator

Hmm my examples do not seem to be updating very timely at this time! So look at
http://www.imagemagick.org/Usage/resize/#filter_blur



The Gaussian Interpolator, is my idea, based in my own experience. and not on any mathematical attempt to find a non-burry gaussian filter. I also like using sigma = 0.75 (actually quite close to a sigma = 1/sqrt(2) value) for blurring bitmaps to give them some (very rough) anti-aliasing, and in my mind they were the same thing, but obviously isn't.

Do you have any more logical suggestion for a 'Gaussian Interpolator' that isn't as blurry as the default sigma=0.5?

@Anthony:

Summary: No, I don't have anything better to suggest than sigma=1/2 as default.

-----

Adam is using -filter Gaussian -define filter:sigma=.7071067811865475 -resize, which I would gather is now (today's svn) doing what it's supposed to. It's even more blurry than 1/2.

I'll have him return Gaussian blur to plain vanilla (=1/2).

-----

The bug explains henriwho's surprise RE: overly aliased result of downsampling with Gaussian blur. I want to thank him for raising a red flag for me.

-----

Given what I understand you want a sigma for, I don't really have a good suggestion RE: what blur to use when resizing/distorting with Gaussian blur, except to say: Isn't it supposed to be blurry?

So, I'd pick one of 1/2 and 1/sqrt(2), and suggest to people who want something less blurry that they resize or distort with another filter.

viewtopic.php?f=1&t=19245#p75126

However, Craig DeForest is quite clear that the "optimal" sigma is 1/2 for EWA resampling, and I don't see why it would be any different for tensor resizing. He knows what he's doing. (Although pretty much all he cares about is antialiasing in the Fourier domain.) Given that 1/2 is the smaller of the two recommended by Turkowki for resizing, so go for 1/2.

Really: Use the same default sigma that you use for "in place" Gaussian blur/filtering. And, my guess is that it should be 1/2 as well.

If I run across a solid recommendations, or take the time to dig, I'll let you know.

But at this point I think the best thing to do is to accept that Gaussian blur is blurry.