Legacy ImageMagick Discussions Archive

It seems some oddness might be present in the gamma to linear space on EXR conversions.

When using a sample image (http://www.belle-nuit.com/testchart.html) via

[img]convert%20testchart.tif%20testchart.exr[/img]

ImageMagick produces a lighter image it seems, suggesting the linear conversion wasn't correct.

The problem is that even when using
The results are closer for the curve, but the RGB values are subtly off.

Is there something I am doing incorrectly here?

ImageMagick assumes linear RGB. The -colorspace sRGB option tells ImageMagick to convert the linear RGB space to non-linear sRGB. If you just want to set the colorspace and not transform it, use the -set colorspace sRGB option.

Is there a low level constant bug somewhere?

The -colorspace option is a verb. It says to transform one colorspace to another. In your example, you ask it to convert from its original colorspace to sRGB. Since the colorspace defaults to linear RGB you are asking ImageMagick to convert from linear RGB to sRGB. If you specify the original colorspace as sRGB, the -colorspace option becomes a noop since it sees the original and the colorspace requested by the -colorspace option are the same. The -set option simply sets image metadata but does not act on the pixel data:

• convert testchart.tif -set colorspace sRGB -colorspace sRGB testchart.exr

Here -colorspace is a noop.

In ImageMagick, version 7, we may assume that an unmarked colorspace is sRGB. For version 6, we assume linear RGB. The lesson learned here is that all image data must have a declared colorspace. The most promising solution is to associate a proper color profile with each image file. If testchart.tif included a sRGB color profile with it we would not need to guess which colorspace is associated with the image pixels. Without a proper color profile, we provide the -set colorspace option to declare the colorspace.

What I am trying to explain (extremely poorly I'd add ) is that there is no way to get a perfect 1:1 conversion of that testchart.tif. Or if there is, I have yet to discover it.

Setting the input colorspace to sRGB and the output to sRGB is close, but it is not 1:1.

The sRGB transform is floating point and may not give a 1:1 roundtrip. We'll investigate. We could also skip the transform if the input and output colorspaces are both sRGB. Or you can use -set colorspace sRGB and not use the -colorspace option. We'll investigate and add a patch to ImageMagick 6.7.1-0 once we decide the best path forward.

Thank you very much.

Ok, we're getting a 1:1 roundtrip under certain circumstances. Try this:

• convert testchart.tif -set colorspace sRGB -colorspace sRGB -depth 8 testchart.miff
  compare -metric rmse testchart.miff testchart.tif null:
  0 (0)

When we write to EXR instead, we get minimal error which is expected since EXR pixels are stored as 16-bit floating point values:

• convert testchart.tif -set colorspace sRGB -colorspace sRGB -depth 8 testchart.exr
  compare -metric rmse testchart.exr testchart.tif null:
  6.54481 (9.98674e-05)

We added a patch to ImageMagick 6.7.1-0 Beta to make -colorspace sRGB a noop for other image formats such as PNG.

It seems entirely odd that one can't get a 1:1 going to a greater bit depth. Something seems wrong.

Several other packages manage it. I don't think everything is in order, but I cannot be certain. GM appears to do a transform perfectly, but perhaps it is off too. If it is however, it would seem to be a lesser degree.

We double checked the linear RGB to sRGB formula's and they appear to be correct. We added a patch to ImageMagick 6.7.1-0 to assume sRGB when the colorspace is undeclared as recommended in Wikipedia:

• If the color space of an image is unknown and it is an 8- to 16-bit image format, assuming it is in the sRGB color space is a safe choice.

Your command now returns a 1:1 roundtrip for lossless encoding. There is a small error for EXR because EXR has 16-bit floating point values.

Hmm.
Is still yielding an image that is too bright. What is the command you are using?

It looks now like it has done a double linearization as only applying a gamma of 2.2ish brings the look back into line with the source image?

see above where he has


convert testchart.tif -set colorspace sRGB -colorspace sRGB -depth 8 testchart.exr
freds-mac-mini:~ fred$ compare -metric rmse testchart.exr testchart.tif null:
6.54481 (9.98674e-05)


Visually they look the same to me.

I bet you are using display to display them however, yes?

The screenshots are from Nuke. Identical results in Blender as well, with the same process. It should be noted that both apply an inverse gamma correction on sRGB spaced images and nothing on linear EXR formats. All formats are corrected on out, which indicates that ImageMagick is doubling up the linearization it appears.

To confirm this, we can apply gamma nodes of approximately sRGB's 2.2 and see the proper result.

Original TIF (lower right) versus ImageMagick EXR (top left) output:

Did you apply the correct command line as per what I mentioned and Magick identified before?

If so and IM gives you a compare of 0, then the image data itself is identical. the only possible difference would be in the meta data and how applications display the image using the meta data.

I am not an expert on sRGB or other non-linear formats, so all I can say is that IM is converting the image data properly when converting it. The issue would be on what meta-data is transferred from input to output and how display devices (like Nuke) make use of it or make assumptions if it is missing or non-existent for any given image format.

At this point, you will have to explain what you believe is the issue as I am not expert enough on this topic and I will leave it between you and Magick.

The problem appears to be ImageMagick is converting the file incorrectly.

The EXR is fundamentally incorrect, as tested with Nuke, Blender, and Houdini.

So while it is possible that these three applications are displaying the EXR incorrectly, part of me doubts it. Doubly so considering that the conversion out of GraphicsMagic is not only a perfect 1:1 of the source file, but also displays the EXR result correctly and as expected.

I'm willing to do further tests, but I am stuck with wondering what to do.

Nuke PLE and Houdini Apprentice are both free downloads to test the EXRs against. Blender as well, although not quite an industry standard tool as the previous two.