ResizeImage: Odd behaviour with 6.9.7

[srd]

Hi,
I'm inheriting a code base at work from a project where the original developers have long since left. Since the code base has been languishing for over 2 years, one of the first things I want to do is update the ecosystem to take care of security issues, bug fixes etc - without changing the way anything behaves. So, the usual.

The original code base uses ImageMagick 6.7.7 from Ubuntu Trusty LTS, I'm trying to update to 6.9.7 (running on ArchLinux). The application in question in written in Ruby, so ImageMagick is accessed through the RMagick gem.

Now to the issue at hand: In the code base, image hashes are being created by resizing the image in question to an 8x8 geometry and then taking the hex values of the resulting pixels intensities. The version update of ImageMagick changes the output, starting at the result of the resize operation.

The image depth and channel depth in the resized image in both versions is 16, however the image type of the resized image for 6.7.7 was PaletteType, while for 6.9.7 it's TrueColorType. The really odd thing however is looking at the resulting RGB values of the pixels of the resized images: in the 6.9.7 version I'm getting channel values that are larger than 2^16 and sometimes even negative, which is not at all what I expect.

I had a look at the relevant sections of RMagick code, but it seems that nothing relevant changed here in the past few years which could cause these changes, so I'm guessing the changes originate within the ImageMagick implementation.

Is this new behaviour expected? If so, can someone point me to the rough version of the relevant changes, so that I can try and recreate the old behaviour with the new version? Any help would be greatly appreciated

[snibgo]

What variety of IM are you using? With Q16 integer (non-HDRI), pixel values are always in the range 0 to 2^16-1 inclusive.

With HDRI, resizing an image that has all pixels inside the usual range shouldn't, I think, ever create values that are outside the range.

Perhaps you can provide URLs of sample input and output.

If using intensities, you might experience an issue upgrading from 6.7.7, as that version thought grayscale images were linear RGB instead on non-linear sRGB.

[snibgo]

I said:

With HDRI, resizing an image that has all pixels inside the usual range shouldn't, I think, ever create values that are outide the range.

I suspected I might be wrong, and I was. "-resize" can create values that are outside the range of input values. Thus, input values between 0 and 100% can result in output values outside that range. For example, using HDRI:

Code: Select all

convert xc:Black xc:White +append -resize "10x10^!" -format "MIN = %[fx:minima*100]\nMAX = %[fx:maxima*100]" info:

MIN = -5.92538
MAX = 105.925

So, I suspect your old version of IM wasn't HDRI, but your new version is. I think that is the problem.

[srd]

Hi,
thanks for the reply. You are correct - the new version has the HDRi module installed, and the old version doesn't. I had meant to mention that in my original posting.

Would you happen to know of any documentation where I can read up on how IM processes HDRI images or rather how the color values are meant to be interpreted? I was a bit naive and assumed that all that would happen is that the bits per pixel would be increased, but that the per-channel extrema would still remain within the expected value domain indicated by the channel depth. If it's possible for me to normalize the values after the fact, I wouldn't have too much of a problem with that.

Thanks for the heads up with the intensity and linear grayscale images. I had read about that in the changelog, but I'm still hoping that it won't bite me too hard, as RMagick computes the intensity on the ruby side from the colors of a pixel on its own instead of calling the IM function.

[fmw42]

Only document I know is at http://www.imagemagick.org/script/high- ... -range.php

[snibgo]

HDRI and bits-per-pixel (ie the Q number) are independent. HDRI is available for Q8, Q16, Q32 and Q64.

HDRI versus non-HDRI has three main effects:

1. Arithmetic is done with floating point, rather than integers. This mostly increases accuracy, but can sometimes decrease it eg an operation that should result in 100% might instead give 99.999999% or 100.0000001%.

2. Results can be outside the "normal" range of 0 to 100%. You can generally "-clamp" the values to this range; see http://www.imagemagick.org/script/comma ... .php#clamp . "-composite" will automatically clamp unless you tell it not to.

3. It is a bit slower.

For consistency with your old non-HDRI version of IM, I suggest your new version should also be non-HDRI. Then, if you want, migrate to HDRI.

[srd]

Yes, I think compiling my own non-HDRI version would be consistent going forward. For now I'll just add a conditional to the unit tests so that developers using the standard distribution packages don't have to roll their own package.