convert from Adobe RGB to some kind of linear RGB (and back)

[NicolasRobidoux]

How can this be done?
Looked at http://www.imagemagick.org/Usage/formats/#color_profile and am not 100% sure I got the full picture.
If the profile is embedded in InputImage, is

Code: Select all

convert InputImage -profile (stuff I want to do in linear RGB) OutputImage

enough?
I don't particulary care which linear RGB I'm getting (meaning I don't care what the primaries are; I'd actually be OK working in another linear light space, like XYZ) as long as I can do "stuff" in something that approximates linear light, and as long as I can start and return to Adobe RGB without losing too many bits. It's really important that if "(stuff I want to do in linear RGB)" is basically a no-op in disguise, then the input and output colors match in Adobe RGB.

[fmw42]

convert InputImage -profile (stuff I want to do in linear RGB) OutputImage

I tested and you need to assign the profile (or have it in the input image), but it then gets lost during processing (with the -colorspace RGB) and you have to reassign it at the end.

convert InputImage -profile path2/AdobeRGB1998.icc (stuff I want to do in linear RGB) -profile path2/AdobeRGB1998.icc OutputImage

Assigning a profile at the beginning is irrelevant if you are using -colorspace RGB to do linear processing. I do not think AdobeRGB is truly linear. It is too close in coloring to sRGB in comparison to convert image -set colorspace sRGB -colorspace RGB result.


For example I did this with a tiff image:

Code: Select all

onvert \( input_small.tif -profile /users/fred/images/profiles/AdobeRGB1998.icc \
-depth 16 -set colorspace sRGB -colorspace RGB \) \
\( -clone 0 -gamma 3 -filter LanczosRadius -distort Resize 800% -gamma 0.333333333333333 \) \
\( -clone 0 -negate -gamma 3 -filter LanczosRadius -distort Resize 800% -gamma 0.333333333333333 -negate \) \
\( -clone 1 -clone 2 -evaluate-sequence mean -colorspace gray -auto-level \) \
-delete 0 -compose over -composite \
-set colorspace RGB -colorspace sRGB \
-depth 8 -profile /users/fred/images/profiles/AdobeRGB1998.icc \
input_small2_LanczosRadius_dualblended_s800_g3_RGB.tif

Without the final -profile, the result has no profile assigned to it. The first -profile will be ignored, I think, since one converts to linear RGB.

If I am wrong about AdobeRGB not being truly linear RGB, then I suppose one could do the following and the result maintains the initially assigned profile.

Code: Select all

convert \( input_small.tif -profile /users/fred/images/profiles/AdobeRGB1998.icc -depth 16 \) \
\( -clone 0 -gamma 3 -filter LanczosRadius -distort Resize 800% -gamma 0.333333333333333 \) \
\( -clone 0 -negate -gamma 3 -filter LanczosRadius -distort Resize 800% -gamma 0.333333333333333 -negate \) \
\( -clone 1 -clone 2 -evaluate-sequence mean -colorspace gray -auto-level \) \
-delete 0 -compose over -composite \
-depth 8 \
test1.tif

[glennrp]

I do not think AdobeRGB is truly linear. It is too close in coloring to sRGB in comparison to convert image -set colorspace sRGB -colorspace RGB result.

Right, it is similar to sRGB but it can represent a somewhat larger gamut of colors. The gamma is about the same (1/2.19921875), without the linear part that sRGB has in the
low-intensity portion of the transfer curve.

[snibgo]

I probably misunderstand the question, because the obvious answer seems to be to use "-gamma" or "-evaluate Pow" with 2.19921875 and 0.4547069271758437. (http://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf says 2.19921875 comes from 2+51/256.)

[NicolasRobidoux]

Alan (snibgo):
Cool: Adobe RGB is a "straight" gamma space \o/

[NicolasRobidoux]

So, to go from Adobe RGB to linear RGB with Adobe RGB primaries

Code: Select all

... -gamma .4547069271758437 ...

(with possibly a -set colorspace RGB or two to avoid confusion) and to go back to Adobe RGB

Code: Select all

... -gamma 2.19921875 ...

[snibgo]

Short answer: yes.

Longer answer:

1. We need to remember that the resulting linear RGB values are not, of course, the same RGB values we would get by converting to sRGB with a profile, and from there to RGB with "-colorspace RGB". These are two different linear RGB colorspaces.

2. I would use "-evaluate Pow" instead of "-gamma" (reversing the two numbers, of course). The reason is that "-gamma" changes the gamma metadata, and a round-trip may not leave it exactly where it started. And "-set colorspace RGB" sets this metadata to 1.0, so this is a further complication. (Most software ignores gamma metadata, so perhaps I am being picky. IM does use this metadata, and "1.0" is a magic number, and I don't know what the tolerance is.)

3. If "-set colorspace RGB" is used after the first conversion, I strongly suggest that "-set colorspace sRGB" is used after the second. Otherwise the saved result could be marked as having a gamma of "1.0", confusing further processing.

4. A case could be made that AdobeRGB images should be labelled with "-set gamma 0.4547069271758437". I don't know if this would make any difference to anything.

[NicolasRobidoux]

Alan:
I'm totally fine with "different RGB colorspaces". Actually, I'd be fine with other primaries than RGB. So this works for >>me<<.
But indeed, without the "Longer answer", people may think that they are getting the same linear RGB as doing -set colorspace sRGB -colorspace RGB. And of course this is a bad surprise in the making.
All the other comments are useful as well.
Thank you!

[fmw42]

Please list an example code for this so we all understand exactly what is being suggested. I presume -evaluate pow replaces the -set colorspace sRGB -colorspace RGB, but I am unclear if -gamma 3 is being removed. Modify my code (below) as appropriate. I presume the input_small.tiff has an Adobe RGB profile to start.

Code: Select all

convert \( input_small.tif  \
-depth 16 -colorspace RGB \) \
\( -clone 0 -gamma 3 -filter LanczosRadius -distort Resize 800% -gamma 0.333333333333333 \) \
\( -clone 0 -negate -gamma 3 -filter LanczosRadius -distort Resize 800% -gamma 0.333333333333333 -negate \) \
\( -clone 1 -clone 2 -evaluate-sequence mean -colorspace gray -auto-level \) \
-delete 0 -compose over -composite \
-set colorspace RGB \
-depth 8 -profile /users/fred/images/profiles/AdobeRGB1998.icc \
input_small2_LanczosRadius_dualblended_s800_g3_AdobeRGB.tif

Also please comment why my code above is incorrect.

[snibgo]

For example, if in.tiff is an image defined in AdobeRGB1998 space and I want to resize it in linear space:

Code: Select all

convert in.tiff -evaluate Pow 2.19921875 -resize 500% -evaluate Pow 0.4547069271758437 -out.tiff

(I make no comment about the wisdom of this operation. Nicholas knows far more about the subject than I do.)

AdobeRGB1998 is defined, by Adobe, to have a simple relationship between pixel values and radiometrically linear values. It is a power law, where the constant is approximately 2.2. (It is exactly 563/256.) So my simple command converts to linear, and back, very easily.

The relationship between sRGB and linear is more complex. It is a power law but straightened out near the bottom. The exact definition seems to depend on which version of the "standard" is used. For most purposes I don't think any differences between standards matter. The curve approximates to a power curve with a constant of 2.2. So instead of the above we might:

Code: Select all

convert in.tiff -set colorspace sRGB -colorspace RGB -resize 500% -colorspace sRGB out.tiff

Ignoring the issue about the gamma metadata, this will give a very similar result. Very very similar, eg RMSE about 0.002, or 0.2%. The result is (slightly) wrong because the non-linearity of AdobeRGB1998 is (slightly) different to the non-linearity of sRGB.

I'm not clear what you are doing with "-gamma 3" and inverse.

[fmw42]

thanks snibgo

So I think for an AdobeRGB tiff file as input, this would be the change of the dual blending code (see viewtopic.php?f=22&t=25935)

Code: Select all

convert \( input_small.tif -depth 16 -evaluate Pow 2.19921875 \) \
\( -clone 0 -gamma 3 -filter LanczosRadius -distort Resize 800% -gamma 0.333333333333333 \) \
\( -clone 0 -negate -gamma 3 -filter LanczosRadius -distort Resize 800% -gamma 0.333333333333333 -negate \) \
\( -clone 1 -clone 2 -evaluate-sequence mean -colorspace gray -auto-level \) \
-delete 0 -compose over -composite \
-evaluate Pow 0.4547069271758437 \
-depth 8 input_small_LanczosRadius_dualblended_s800_g3_AdobeRGB.tif

The result seems to have maintained the AdobeRGB profile.

[NicolasRobidoux]

Fred: When I have a minute, I'll post a simplified version that exploits the fact that we may as well use gamma 2.19921875 intead of gamma 2 or 3.
(It's already tomorrow where I live.)

[NicolasRobidoux]

If I understand correctly how profiles etc are handled with IM, and assuming input_small.tif is Adobe RGB 8 bit (if already 16 bit, I imagine the first parentheses can be skipped) this would be the one in which linear is blended with a gamma version which here is neither 2 nor 3. This is different than what you gave code for because you showed the "black/white symmetric" scheme, which is not a front runner right now. But something similar could be done with it, again using the "Adobe given" gamma instead of 3.

Code: Select all

convert \( input_small.tif -depth 16 \) \
\( -clone 0 -filter LanczosRadius -distort Resize 800% -gamma 0.4547069271758437 \) \
\( -clone 0 -gamma 0.4547069271758437 -filter LanczosRadius -distort Resize 800% \) \
\( -clone 1 -clone 2 -evaluate-sequence mean -colorspace gray -auto-level \) \
-delete 0 -compose over -composite \
-gamma 2.19921875 \
-depth 8 input_small_LanczosRadius_blended_s800_gAdobeRGB_AdobeRGB.tif

I imagine using -evaluate Pow with the reciprocals of the gammas may be more accurate?

[fmw42]

convert \( input_small.tif -depth 16 \) \
\( -clone 0 -filter LanczosRadius -distort Resize 800% -gamma 0.4547069271758437 \) \
\( -clone 0 -gamma 0.4547069271758437 -filter LanczosRadius -distort Resize 800% \) \
\( -clone 1 -clone 2 -evaluate-sequence mean -colorspace gray -auto-level \) \
-delete 0 -compose over -composite \
-gamma 2.19921875 \
-depth 8 input_small_LanczosRadius_blended_s800_gamma_AdobeRGB.tif

But the above seems inconsistent with the following in that you do not appear to be doing the resize in linear RGB.

Code: Select all

convert \( input_small.png -depth 16 -set colorspace sRGB -colorspace RGB \) \
\( -clone 0 -gamma 2 -filter LanczosRadius -distort Resize 800% -gamma 0.5 \) \
\( -clone 0 -filter LanczosRadius -distort Resize 800% \) \
\( -clone 2 -colorspace gray -auto-level \) \
-delete 0 -compose over -composite \
-set colorspace RGB -colorspace sRGB \
-depth 8 input_small_LanczosRadius_blended_s800_g2_RGB.png

Your command would be equally the same for input in sRGB rather than AdobeRGB, by just changing the gamma a little.

Code: Select all

convert \( input_small.tif -depth 16 \) \
\( -clone 0 -filter LanczosRadius -distort Resize 800% -gamma 0.454545454545455 \) \
\( -clone 0 -gamma 0.4547069271758437 -filter LanczosRadius -distort Resize 800% \) \
\( -clone 1 -clone 2 -evaluate-sequence mean -colorspace gray -auto-level \) \
-delete 0 -compose over -composite \
-gamma 2.1 \
-depth 8 input_small_LanczosRadius_blended_s800_gamma_sRGB.tif

So I am still confused. Sorry. Reply when convenient. No urgency.

[NicolasRobidoux]

Fred:
This is what's going on:
Indeed, one could do a resize in sRGB then convert to linear RGB, convert to linear RGB then resize, compute the luminance from the latter, blend the two results, and convert the blend back to sRGB.
What I showed was actually exactly the same replacing sRGB by Adobe RGB.
Now: Why would I suggest that this is a good idea with Adobe RGB, but not sRGB? It's because sRGB is not >>really<< a gamma space: It's that "linear bit" near zero that disqualifies it. Given that I am really trying to produce something really really good, this "break in slope" in the color space in which I perform one of the two resampling operations is not something I want, because in some situations it will "resonate". Mathematically, it destroys the property that basically says that if in linear light the three channels are proportional in the input image, so will they be in the output, resized, result.
-----
It's been wrapped in all sort of code, but the basic idea of the scheme that is not black/white symmetrical (the scheme that has -negates) is very simple:

Resampling in linear light gives darker dark halos. Resampling in a "perceptual space" gives lighter light halos. So, pick a perceptual space which, in relation to linear light, is not "kinky", and blend the two results, using more perceptual where dark, and more linear where light. Blending is more accurate when both images are in the same color space. This is why everything is converted to linear light, if not already, just before blending. Linear light is a good friend of blending.

Gamma spaces are good friends of linear light. Better friends than sRGB and Lab. I actually see, for example in the Wizard, color drift artifacts that come from the "kinkiness" of Lab.

Once the main idea (in bold above) is decided on, everything else falls into place after thinking of which color space an operation is preferably done in.

And, lo and behold, Adobe RGB is a pure gamma space! Which makes sense: Adobe is in the business of modifying images, not only showing them and compressing them. So they chose a perceptual color space that is conducive to being a good friend to linear light.

This is quite terse but I hope it gives the main idea.