Negative color space coordinates after resize

[ATell-SoundTheory]

ImageMagick version

7.1.1-21

Operating system

MacOS

Operating system, version and so on

13.6 Darwin Kernel Version 22.6.0

Description

An operation like magick input.exr -resize 50% output.exr results in negative color coordinates in the output, likely caused by a band limiting convolution kernel with negative coefficients. The problem is probably present in other sorts of combinations of band limiting and floating point image formats.

Applications having to deal with negative color coordinates might not be prepared for it and may even crash or at least produce undesirable output.

Bounding the color space coordinates by zero from below would solve the problem and is the generally accepted way to handle the issue in image processing.

Steps to Reproduce

Take any floating point encoded image like openEXR with enough contrast and resize it to a smaller size. Inspect the output.

Images

No response

[snibgo]

If your IM has HDRI, many operations can result in negative pixel values (or values larger than 100%). For example, "-blur", "-evaluate subtract 50%", and many others. In many cases, this is valid and useful.

You can use "-clamp". See https://imagemagick.org/script/command-line-options.php#clamp

[ATell-SoundTheory]

I agree that for HDR imaging it certainly makes sense to leave the color coordinates unbounded from the top. However, in terms of negative coefficients, the story is different. It may not be desired that you leave the color space that is spanned by the primaries. But if you enforce clamping to stay in your color space, my understanding is that you also clamp to the upper bound of the color space range, which is not what you want for (floating point) HDR.
In addition to this, it is never desirable to leave the XYZ or LMS space in which the output color space is embedded. The particular example I had produced negative tristimulus and CIE color coordinates. That's where you should prevent negative values in all cases.

[snibgo]

Yes, -clamp also clamps the top. If you want to clamp just the negative values, use "-evaluate Max 0".

[ATell-SoundTheory]

And what if I just want to assert that the XYZ or LMS coordinates are non-negative and otherwise tolerate values escaping the spanned color space? (Honestly, I think that should be the default. Things like negative luminance make no sense in any scenario.)

[snibgo]

IM is a fairly low-level system. It does what we tell it to, whether the colorspace is sRGB or XYZ or whatever. If you want different processing according to the colorspace, you need to build that into your scripts or programs.