Crop/Rotate with Mitchell-Netravali distorts stars

[ruediger]

While using DynamicCrop to crop and rotate a 11172x8736 pixel image with Interpolation set to "auto", the chosen algorithm defaults to "Mitchell-Netravali". The log states:

Bicubic interpolation, Mitchell-Netravali cubic filter (3x9): 11294x3619 pixels, 3 channels, rotate -28.484 deg: done

In parts of the image the stars get distorted. This does not happen when explicitly selecting Lanczos-3 as interpolation algorithm.

The sad thing is, that I noticed the distorted stars much later during processing and then thought, the stacking and alignment process went wrong... which I unnecessarily repeated. But I'm happy now that I nailed the problem down to the interpolation algorithm.

Attached are two screenshots. First one showing part of the original file (left), the Mitchel-Netravali result (middle) and the Lanczos-3 result (right).
Second screenshot shows the dynamic crop settings with "auto" leading to the wrong/distorted stars result.

Rüdiger

[Juan Conejero]

Hi Rüdiger,

This has happened because you have (1) scaled down the cropped image, and (2) applied different scaling ratios to the horizontal and vertical axes. I know (1) because in Auto interpolation mode, Mitchell-Netravali cubic filter interpolation can only be selected if the image is to be scaled down (downsampled). I know (2) because the interpolation filter dimensions are 3x9 pixels. This means that the Y-axis has been scaled down more (filter size = 9 pixels) than the X-axis (filter size = 3 pixels). Obviously this leads to distortion.

Have you changed the Scale parameters of DynamicCrop?

[ruediger]

This has happened because you have (1) scaled down the cropped image, and (2) applied different scaling ratios to the horizontal and vertical axes.

Juan, thanks for fast response.

I repeated the task again and double-checked if I accidentally changed scaling ratios. Attached is a full screenshot of what I do and the console log:

Bicubic interpolation, Mitchell-Netravali cubic filter (3x9): 11294x3619 pixels, 1 channels, rotate -28.480 deg: done


If I only change the "auto" to "Lanczos-3", all other settings identical (by double clicking the history entry), everything is ok.

Rüdiger

[Juan Conejero]

OK, bug confirmed. This is a very easy to fix regression (just a stupid "improvement" I did in the automatic interpolation selection routine).

Since I'm going to publish a new RC6 version (build 1013), I'll include a fixed Geometry module there, instead of releasing an update for 1012. Thank you for discovering this error, and sorry for the trouble.

[ruediger]

I'll include a fixed Geometry module there, instead of releasing an update for 1012

Sounds good, thanks very much!

Rüdiger

[georg.viehoever]

Juan,
do yourself a favor and dont overload version numbers. Its bad enough that we now have 6 release candidates (all with new features - in my opinion, any release candidate should be feature complete). But now you are starting to have pre-releases, releases and second releases of RC6.... Its gets more and more difficult to identify which version people actually are talking about.
Georg

[Juan Conejero]

I was trying to avoid an RC7, since in this case we only have a few minor corrections in the PI Core application (basically, the JavaScript engine initialization problem on 32-bit Windows and a couple glitches).

Anyway, we'll have the number of release candidates necessary to achieve a fully stable 1.8.0 platform, no matter if we need RC7 or RC99. We have actually reached that goal on Linux and Windows. The real problem now is with Mac OS X, which is fully stable on my machines (again, I am testing RC6 intensively the whole day without a *single* problem on Mac OS X), but a complete piece of trash on most of the rest of the world. I confess this is putting me to the test...

[pfile]

there are a lot of mac variants now, for instance, my PI temp directory is on an SSD and that thing can really sink and source data fast. that may lead to timing issues which you can't see on your machine.