-grayscale *luminance gives DARK result if global -intensity *luma or +intensity was EVER explicitly set earlier

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.
Post Reply
Dabrosny
Posts: 111
Joined: 2013-10-02T10:49:39-07:00
Authentication code: 6789
Location: New York, US

-grayscale *luminance gives DARK result if global -intensity *luma or +intensity was EVER explicitly set earlier

Post by Dabrosny » 2017-09-11T09:56:42-07:00

After setting -intensity rec709luma or rec601luma (or even after "-intensity Undefined" or "+intensity", strangely), any later -grayscale rec709luminance or rec601luminance calculates linear gray data as expected, but uses the method from the earlier -intensity setting as the intensity image attribute of the resulting image, mislabeling it as nonlinear (or as undefined which us ultimately treated as nonlinear) when in fact its data is linear. This causes the result to be too DARK when displayed, or when converted to any other (i.e. non-Gray) colorspace.

Code: Select all

$ magick rose: -grayscale rec709luminance -colorspace sRGB rose-grayscaleLuminance.png                                     
$ magick -intensity rec709luma rose: -grayscale rec709luminance -colorspace sRGB rose-intensityLuma-grayscaleLuminance.png 
$ magick +intensity rose: -grayscale rec709luminance -colorspace sRGB rose+intensity-grayscaleLuminance.png
Image rose-grayscaleLuminance.png (Normal result of -grayscale rec709luminance)

Image rose-intensityLuma-grayscaleLuminance.png (unnecessarily darkened)

Image rose+intensity-grayscaleLuminance.png (unnecessarily darkened)

(Notes:
- The darkening above is *not* similar to the normal effect of -grayscale rec709luma or the default -colorspace gray as these don't produce nearly such a dark result.
- The final "-colorspace sRGB" conversions before saving each png file above aren't important but they are just there to avoid linear png which would be displayed differently by various software, sometimes appearing dark but sometimes not, merely because some software ignores the gamma=1. The issue I'm submitting here is *not* related to transforming specifically to sRGB afterward.
- The issue I'm submitting here is also *not* specific to PNG output. I didn't want to use JPEG files simply because they also have a separate issue with linear grayscale images, which is being discussed in a separate bug topic: viewtopic.php?f=3&t=32666 )

(Of course once we understand the present issue, we can work around it, for example right after the -grayscale operation we can explicitly apply an appropriate -intensity rec709luminance or rec601luminance to the image, or -set colorspace RGB {as opposed to a different -colorspace operation, which generally wouldn't help})

(BTW the only reason the problem doesn't occur the other way around, with -intensity rec709luminance and -grayscale rec709luma for example leading to an overly LIGHT result, is that there is currently an asymmetry in the way IM treats linear and nonlinear intensities: a Gray image with a linear intensity is generally treated as nonlinear unless accompanied by an exact gamma=1, while a nonlinear or undefined intensity is treated as nonlinear irrespective of gamma.
I've tried to document this and other behavior of intensity in my proposed "-intensity" documentation update in another topic here: viewtopic.php?f=3&t=32548#p149319 -- please take a look!)
-Dabrosny [Using IM7.0.6 or higher, Q16 HDRI x64 native executable, command line, often invoked from cygwin bash/sh (as of Aug. 2017)]

Post Reply