Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
As a result in ImageMagick-6.9.0-4 any composite operation on floating-point TIFF clamps all channels to 1.0.
Composite operations in ImageMagick-6.9.0-2 doesn't clamp floating-point image.
We're following the SVG compositing specification. The conundrum is "should" rather than "must" in this statement:
In addition to the base set of 12 Porter-Duff operations, a number of blending operations are supported. These blending operations are extensions of the base Porter-Duff set and provide enhanced compositing behavior. The extended operations may result in color and opacity values outside the range zero to one. The opacity value should be clamped between zero and one inclusive, and the pre-multiplied color value should be clamped between zero and the opacity value inclusive.
Well. Standard is standard. But clamping makes HDRI processing difficult. May be worth to add "-define compose:clamping=(true|false)" (or something else) to control this behavior?
When compositing using Porter-Duff extended blending operations color and opacity values may fall outside the range zero to one.
A User Agent MUST clamp color and opacity values between zero and one inclusive.
A User Agent MUST clamp premultiplied color values between zero and one inclusive.
Seems definitive, clamping is required. That will be the default behavior. However, we'll add an option as you suggested to prevent clamping.
Has this been added to 6.9.1.2 or is/will it be in 6.9.1.3 and is it in the IM 7 beta, yet? I have the same issue. There are times when clamping mathematical compose methods causes issues in my scripts.