XYZ -> sRGB issues after update

[xr4y]

Hi, I have been using this script to convert XYZ -> sRGB. This script was working satisfactory until recently. After the latest update the images comes out greyish and off. I'm using Arch Linux and ImageMagick 6.7.7-5.

Here is the code:

Code: Select all

#!/bin/bash

xyz2srgb() {
    convert -verbose "$1" \
    -type TrueColor \
    -alpha Off \
    -gamma 0.384615 \
    -color-matrix "3.2404542 -1.5371385 -0.4985314 \
                  -0.9692660  1.8760108  0.0415560 \
                   0.0556434 -0.2040259  1.0572252" \
    -gamma 2.2 \
    -depth 8 \
    $(basename "$1" ".j2c").tif
}

export -f xyz2srgb
j2c="$(readlink -f "$1")"
tif="$(readlink -f "$2")"

cd "$tif"; find "$j2c" -name "*.j2c" | sort | parallel xyz2srgb {}

[anthony]

From what version did you upgrade?

IM of late has been making the switch to the use of sRGB colorspace for images being read in.
That is making it smarter about the default use of sRGB in image file formats.

[xr4y]

Hi Anthony, thanks for the reply. Here are the latest updates from pacman.log:

[2012-05-02 11:11] upgraded imagemagick (6.7.6.5-1 -> 6.7.6.8-1)
[2012-05-02 11:11] upgraded imagemagick-doc (6.7.6.5-1 -> 6.7.6.8-1)
[2012-06-02 13:10] upgraded imagemagick (6.7.6.8-1 -> 6.7.7.5-1)
[2012-06-02 13:10] upgraded imagemagick-doc (6.7.6.8-1 -> 6.7.7.5-1)

[anthony]

You do know that your gamma factors are not equivelent!
The inverse of gamma 2.2 is .4545

Now the input image is XYZ colorspace? How was it generated?

What is the identify'd colorspace of that input image? (see below)


Note that from what I can see the command given should not change (or transform) the images
colorspace for the processes requested. It should not take any part, unless some type of
automatic colorpspace change is happening on the save.


For example... currently in the latest IM...

Code: Select all

convert -size 100x100 gradient: png:- | display -

results in a rather dark gradient, as the 'linear gradient' was displayed unchanged on my non-linear monitor. (Display should display the image values AS IS regardless if image input colorspace.)

I can see that gradient generated the image in an 'assumed' sRGB using..

Code: Select all

convert -size 100x100 gradient: -print '%[colorspace]' null:
sRGB

BUT if I tell IM that the gradient is actually linear-RGB, and not sRGB...

Code: Select all

convert -size 100x100 gradient: -set colorspace RGB png:- | display -

Results in the display of a much lighter, more linear looking image. The save to PNG automatically converted the image to sRGB colorspace during the save to PNG (and subsequent display).


In your case I would assume IM would leave the colorspace as sRGB on both read and write, and so should not change the image. But adding some of the 'prints' will let you verify this.

[xr4y]

Anthony, input is a stream of JPEG 2000 images, in 12bit, CIE XYZ colorspace with gamma 2.6. The inverse of gamma 2.6 is 1/2.6=0.384615.

http://en.wikipedia.org/wiki/Digital_Cinema_Initiatives

I use Bruce Lindblooms calculations to go from XYZ -> sRGB: http://www.brucelindbloom.com/index.htm ... atrix.html

The desired output is a 8bit, sRGB tif sequence with gamma 2.2, suitable for DVD, Blu-ray or web output. These images looked satisfactory before the 6.7.6.8-1 -> 6.7.7.5-1 update whereas now they look greyish and off.

[anthony]

Okay, what was the results of printing the %[colorspace] setting after reading in the image!
If IM understands it is XYZ, then it may be doing its own conversion to sRGB (repeating your code - causing wired output)

Also not that sRGB is NOT the same as gamma 2.2, they are close but nor exact. Either you convert to sRGB or you use linear RGB with a gamma 2.2 and pretend it is sRGB. Also '-type' is typically set before reading or writing an image. In this case I doubt it is needed.

Assuming the input XYZ image is actually read in memory as is try this...
First line removes XYZ gamma, and tells IM it is now linear XYZ
Second line converts that to sRGB (which includes the not-quite 2.2 gamma) and saves at tiff...

Code: Select all

  convert image.j2c -alpha Off -gamma 0.384615 -set colorspace XYZ \
    -colorspace sRGB -depth 8  image.tif

In summery first line reads image and ensures IM understands it is linear XYZ at the end
second line converts to the format you are after.


NOTE: none of this takes into account any 'color profile' that may be attached. You may need to remove or replace such profiles, and converting images using color profiles is actually more preferable method of doing color conversions.


I think we may need an example image if we are to help further. As it is I need to make educated guesses about the input image.

See Profiles
http://www.imagemagick.org/Usage/formats/#profiles


Also rather than using shell to do basename handling you can get IM to do it

Code: Select all

   mogrify -format tif \
            -alpha Off -gamma 0.384615 -set colorspace XYZ \
            -colorspace sRGB -depth 8 \
            *.j2c

Mogrify read in image files one at a time, applies the options, then writes out the result.
The -format tells mogrify to change output image file format (and its suffix), which prevents it overwriting the original image.
http://www.imagemagick.org/Usage/basics/#mogrify

[anthony]

IM thinks the "frm_1883.j2c" image is in linear colorspace RGB, though it is really XYZ in this case.
I am not certain if that is a 'correct' assumption or not, as my understanding is that IM should think of a image without a profile as being sRGB.

The image also contains a color ICC profile "IEC 61966-2.1 Default RGB colour space - sRGB"
which is obviously WRONG, and means you can not use profiles to do the color conversion (the best way).

Setting the right colorspace at the end of what you had works. (leaving the profile, on the assumption it will then be correct)

Code: Select all

    convert frm_1883.j2c \
    -alpha Off -gamma 0.384615 \
    -color-matrix "3.2404542 -1.5371385 -0.4985314 \
                  -0.9692660  1.8760108  0.0415560 \
                   0.0556434 -0.2040259  1.0572252" \
    -gamma 2.2 \
    -set colorspace sRGB \
    -depth 8 \
    t1.tif

gives exactly the same as the example TIF output you provided "frm_1883.tif"

Doing a correct RGB -> sRGB conversion is very slightly different, especially in the darker colors. (with the -strip this time)

Code: Select all

 convert frm_1883.j2c \
    -strip -alpha Off  -gamma 0.384615 \
    -color-matrix "3.2404542 -1.5371385 -0.4985314 \
                  -0.9692660  1.8760108  0.0415560 \
                   0.0556434 -0.2040259  1.0572252" \
    -set colorspace RGB -colorspace sRGB \
    -depth 8 \
    t2.tif

However it looks like XYZ conversion built into IM is NOT the same as the above color matrix for XYZ to RGB conversion.

Code: Select all

convert frm_1883.j2c \
    -strip -alpha Off  -gamma 0.384615 \
    -set colorspace XYZ -colorspace sRGB \
    t3.tif

Either your matrix is not XYZ conversion, or IM XYZ is not right. I think it may be IM as it looks too dark, and doing a extra conversion to correct works.

Code: Select all

convert frm_1883.j2c \
   -strip -alpha Off  -gamma 0.384615 \
   -set colorspace XYZ -colorspace sRGB \
   -set colorspace RGB -colorspace sRGB \
   t4.tif

NOTE: The test of sRGB->XYZ->sRGB round trip does come out correct, but that only means it is symmetric... It does not mean the XYZ conversion is correct! -- reporting.

Hopefully the XYZ conversions will be fixed soon.

[xr4y]

Thank you very much Anthony. Let me know if you there is anything I can do or if you need additional frames.

[magick]

Investigating this problem is next our next priority. We'll need a few days (or a few weeks). Stand by...

[xr4y]

May I ask how the correct command looks like with the updated IM?

Ps. Thanks alot for the update!

[anthony]

As per the original problem...

Code: Select all

convert frm_1883.j2c \
    -strip -alpha Off  -gamma 0.384615 \
    -set colorspace XYZ -colorspace sRGB \
    t3.tif

Unless the source image has changed.

[mboufleur]

This topic is quite old and it has remained unanswered, so I thought I would try to provide some updated info.

I just wrote about some findings in XYZ to sRGB conversion for JP2K images in this post, which, I believe may correct some os the issues people may be having with the imagemagick encodes.

As for the changes using the "colorspace" option, it may or may not have to do with the RGB to XYZ Matrix currently being used by imagemagick (and you may check this here).

Code: Select all

X  =  0.4124240*R  +  0.3575790*G  +  0.1804640*B
Y  =  0.212656 *R  +  0.715158 *G  +  0.0721856*B
Z  =  0.0193324*R  +  0.1191930*G  +  0.9504440*B

It is quite different from the matrix from the first post in this topic, which seems to bee using the Matrix from Bruce Lindbloom's page

Code: Select all

X  =  0.4124564*R  +  0.3575761*G  +  0.1804375*B
Y  =  0.2126729*R  +  0.7151522*G  +  0.0721750*B
Z  =  0.0193339*R  +  0.1191920*G  +  0.9503041*B

The later Matrix seems to be working better for my conversions using imagemagick, so I prefer to keep using the -color-matrix option rather than the colorspace.

The final code would be the following

Code: Select all

#!/bin/bash

xyz2srgb() {
    convert -verbose "$1" \
    -type TrueColor \
    -alpha Off \
    -gamma 0.384615 \
    -evaluate multiply 1.09104167 \ 
    -color-matrix "3.2404542 -1.5371385 -0.4985314 \
                  -0.9692660  1.8760108  0.0415560 \
                   0.0556434 -0.2040259  1.0572252" \
    -gamma 2.2 \
    -set colorspace sRGB \
    -depth 8 \
    $(basename "$1" ".j2c").tif

You may notice the "-evaluate multiply" option above, which is derived from the calculation of the Normalization Factor for White Point in DCinema.