From embedded profile to LAB to sRGB

[tcrass]

Hi everyone,

for about two years I've tried to understand color management in general and ImageMagick's way of handling color systems, color spaces and icc profiles in particular. It's a bit like fighting the Lernaean Hydra monster of ancient Greek mythology -- once you've successfuly solved one problen, two new questions pop up...

So here's my most recent one: I've got a bunch of TIFF images in 16 bit ProPhoto RGB color space (with a corresponding embedded icc profile; they're actually slides scanned using a magazine scanner). Now I'd like to convert those images into the LAB colorspace (in order to perform some level manipulation in the L channel) and finally save them as sRGB JPEGs.

Finally I came up with something like

Code: Select all

convert input.tiff +profile 'icc,icm' -set colorspace RGB -colorspace LAB <do semthing in LAB, like -channel R -level 10%,90% +channel> -colorspace sRGB -profile prophotorgb.icc -profile RGB output.jpg

with prophotorgb.icc being the profile embedded in the TIFFs, which I previously extracted using

Code: Select all

convert input.tiff icc:prophotorgb.icc

.

The results look reasonable -- when not performing any L manipulation, the output of this command looks visually identical to a direct conversion from input to output image by just calling

Code: Select all

convert input.tiff -profile sRGB output.jpg

So does the above tapeworm command look reasonable to you?
I wonder if it makes sense to assign plain RGB as colorspace to the profile-stripped input images since their initially embedded ProPhoto RGB profile has a gamma of 1.8.
I also wonder if there is a way to circumvent extraction and stripping of the input image's embedded color profile (if I don't, I get [coce]convert.im6: color profile operates on another colorspace `icc' @ error/profile.c/ProfileImage/792.[/code].)

Thanks for sharing your thoughts --

Torsten

P.S. I'm on Debian Sid, so I'm currently stuck with IM 6.7.7. Or maybe I should try to install 6.8.x from Experimental?

[fmw42]

LAB colorspace was not properly fixed until 6.7.8-2 according to the changelog at http://www.imagemagick.org/script/changelog.php. Perhaps you should upgrade as that version is over 100 versions old

[tcrass]

Fred,

LAB colorspace was not properly fixed until 6.7.8-2 according to the changelog at http://www.imagemagick.org/script/changelog.php. Perhaps you should upgrade as that version is over 100 versions old

did the upgrade, now I'm on 6.8.8, and can do stuff like

Code: Select all

convert input.tiff -colorspace LAB <do something> -colorspace sRGB output.jpg

without error messages. Alas, even a simple

Code: Select all

convert input.tiff -colorspace sRGB output.jpg

seems to have no visible effect on the image.

I just don't get it. What exactly does imagemagick do when converting to a different colorspace? It *should* alter pixel values according to the transformation rules that apply to the transition from the colorspace imagemagick thinks the image currently is in to the colorspace specified by the -colorspace argument, right? In my case, the input image has an embedded color profile -- does -colorspace take that into account? Does -colorspace in that case perform any pixel manipulation at all? It seems no. Identify says that the output image is sRGB (and has no profile embedded) -- but how come it looks identical to the ProPhoto RGB input image?

On the other hand, calling

Code: Select all

convert input.tiff -profile sRGB.icc output.jpg

does create an output that looks as it should and that identify claims to be in sRGB -- again without profile, though.

I really have difficulties to understand the connection between those two parallel universes of -colorspace and -profile and in how far they mutually affect each other. I'd be grateful for any clarifying words...

Torsten

[fmw42]

convert input.tiff -colorspace LAB <do something> -colorspace sRGB output.jpg
convert input.tiff -colorspace sRGB output.jpg

The former should work fine.

The latter is a noop if your input tif is sRGB. If not, it will still do nothing, unless you put some operation after -colorspace sRGB or separate channels, so I have found and been told.

Perhaps post a link to your input.tiff, so we can see what you are trying to do along with your command line for actually processing your file.

[snibgo]

I really have difficulties to understand the connection between those two parallel universes of -colorspace and -profile and in how far they mutually affect each other. I'd be grateful for any clarifying words...

A couple of points might help you.

1. An image that is converted to another colorspace, whether using "-colorspace" or "-profile", will look the same. Changing colorspace shouldn't change the appearance. This is because an image viewer should convert the image to sRGB before displaying it. (Some professional equipment uses other colorspaces, but conventional computers are sRGB.) Converting to another colorspace does two things: it changes pixel values, and writes metadata that says what the new colorspace is.

However, some software ignores the metadata and asumes the image is sRGB.

2. Profiles are mostly used for device-specific fine-tuning. A given model of printer, with particular inks and paper, will use a particular profile. There are also many generic profiles, such as for web offset printing on coated or uncoated paper. If you are preparing images for commercial printing, you might work in the relevant colorspace, with the correct profile. This is tricky as the computer screen can show colours that the printer can't print, and vice versa.

3. "-colorspace" is a different mathematical description of colours. Imagine 3 dimensions of a cube. Every colour is within the cube. The dimensions might be red green and blue, or hue saturation and value, or L* a* and b*. Each method of description has its own advantages and disadvantages.

[tcrass]

D'oh!

Yersterday I posted a long replay -- or, as I should rather say: I *thought* I posted a reply... However, it seems to have gone lost -- maybe I finally by accident hit "Preview" again instead of "Send". Anyway, since my brother-in-law and his family are currently visiting us, I won't find time to re-post until tomorrow night.

So long --

Torsten

[tcrass]

Hi,

and thanks for all your comments.

convert input.tiff -colorspace LAB <do something> -colorspace sRGB output.jpg
convert input.tiff -colorspace sRGB output.jpg

The former should work fine.

Unfortunately, it doesn't -- when calling something like

Code: Select all

convert input.tiff -colorspace LAB -level 1%,99% -colorspace sRGB output.jpg

the output image's colors dont' look right, they are way too pale. The same holds true for

Code: Select all

convert input.tiff -colorspace sRGB -level 1%,99% -colorspace sRGB output.jpg

(I know, the second application of -colorspace sRGB is unnecessary, but I just wanted the second command to have the same basic structure as the first one.)

I only get the colors right when explicitly applying an sRGB ICC file:

Code: Select all

convert input.tiff -level 1%,99% -profile sRGB.icc output.jpg

(works with and without further manipulaion like the -level operation)

By the way, even

convert input.tiff -colorspace sRGB output.jpg

The latter is a noop if your input tif is sRGB.

should -- in my case -- not be a no-op since the input TIFFs are in ProPhoto RGB (with the profile embedded, as mentioned in my initial posting). IM, however, seems to think that the input images are in sRGB already (16 bit, though) -- in spite of the embedded profile:

Code: Select all

identify input.tiff
=> input.tiff TIFF 6768x4416 6768x4416+0+0 16-bit sRGB 179.4MB 0.000u 0:00.019

Perhaps post a link to your input.tiff, so we can see what you are trying to do along with your command line for actually processing your file.

An example input TIFF will soon be available from http://www.tcrass.de/files/input.tiff (currently uploading 185 MB; beware, the TIFF does contain a thumbnail, which I couldn't get rid of without losing the profile embedded in the main image, so use -delete 1 when reproducing the above commands), and the combined (and down-scaled) results of the above three commands can be found at http://www.tcrass.de/files/combined.jpg

1. An image that is converted to another colorspace, whether using "-colorspace" or "-profile", will look the same. Changing colorspace shouldn't change the appearance. This is because an image viewer should convert the image to sRGB before displaying it. (Some professional equipment uses other colorspaces, but conventional computers are sRGB.)

Yeah, that seems to depend very much on the viewing application used -- DigiKam and Krita apparently get it right, while Dolphin and GwenView seem to ignore the ProPhoto RGB profile embedded in the TIFFs.

Converting to another colorspace does two things: it changes pixel values, and writes metadata that says what the new colorspace is. However, some software ignores the metadata and asumes the image is sRGB.

I really start to suspect that even IM sometimes does ignore the embedded profile information, at least when working with the -colorpace operator -- otherwise I don't know how to explain the observation that pixel values apparently don't get properly adjusted when trying to convert the ProPhoto RGB input.tiff into sRGB output.jpeg using -colorspace sRGB. (Well, they of course must be ajusted in the sence that they have to be converted from 16 to 8 bit, but it seems they get just linearly scaled down to fit into 8 bits, i.e. divided by 256.) And the above mentioned observation that the IM identify command outputs sRGB for the ProPhoto RGB TIFFs further supports this suspicion.

2. Profiles are mostly used for device-specific fine-tuning. A given model of printer, with particular inks and paper, will use a particular profile. There are also many generic profiles, such as for web offset printing on coated or uncoated paper. If you are preparing images for commercial printing, you might work in the relevant colorspace, with the correct profile. This is tricky as the computer screen can show colours that the printer can't print, and vice versa.

I guess you're right about what profiles are mostly used for, but in principle *any* color space conversion can be described as the application of profiles, can't they? I mean, it should make no difference if IM used one of its built-in conversion equations (as described e.g. at http://www.imagemagick.org/script/comma ... ptions.php, like so:

Code: Select all

pixel values in LAB color space ==[IM's internal LAB to sRGB conversion equations]==> pixel values in sRGB color space

) or two profiles describing the LAB and the sRGB color space, respectively:

Code: Select all

pixel values in LAB color space ==[LAB profile]==> pixel values in the PCS ==[sRGB profile]==> pixel values in sRGB color space

3. "-colorspace" is a different mathematical description of colours. Imagine 3 dimensions of a cube. Every colour is within the cube. The dimensions might be red green and blue, or hue saturation and value, or L* a* and b*. Each method of description has its own advantages and disadvantages.

Does this go down the same line as "RGB, CMY, HSL are color systems, not color spaces" (or similar), a senctence I read somewhere on the (btw: phantastic!) IM usage pages? To me it seems that describing colors by their red, green and blue (or cyan, magenta and yello) component or by their hue, saturation and light/brightness etc. is more about finding human-comprehensible terms -- in the end, all these systems describe colors as three-component vectors, and the exact mapping of such vectors to "real" colors requires the application of conversion functions as provided by color profiles.

Anyway, back to IM and the parallel existance of -colorspace and -profile: To me it seems that both identfy and convert's -colorspace operator ignore embedded profile information and only rely on IM-internal concepts of color spaces (or color systems) and corresponding conversion functions. On the other hand, -profile seems to work independently from -colorspace (although I haven't thoroughly tested this yet). So for colorspace conversion one should use either the one or the other, but not both, right? (Of course except you know exactly what you do

Regards --

Torsten

[snibgo]

I really start to suspect that even IM sometimes does ignore the embedded profile information, at least when working with the -colorpace operator -- otherwise I don't know how to explain the observation that pixel values apparently don't get properly adjusted when trying to convert the ProPhoto RGB input.tiff into sRGB output.jpeg using -colorspace sRGB. (Well, they of course must be ajusted in the sence that they have to be converted from 16 to 8 bit, but it seems they get just linearly scaled down to fit into 8 bits, i.e. divided by 256.) And the above mentioned observation that the IM identify command outputs sRGB for the ProPhoto RGB TIFFs further supports this suspicion.

When identify shows "sRGB", it means the image will be treated as sRGB unless you do any "-profile" processing. An embedded profile may mean the image isn't really sRGB, but most operations in IM don't depend on the colorspace anyway. If the output format takes profiles, it should be passed straight through.

Complications arise when processing involves more than one input (-composite, -clut, -remap etc) and the inputs have different colorspaces or profiles. It is best to standardise on one colorspace. Personally, I standardise on sRGB, but standardising on ProPhoto should be fine.

The "-colorspace" command ignores profiles. As a general rule, it shouldn't be used on images with embedded profiles. If you really want to use "-colorspace" on an image with a profile, you should first use "-profile" to convert it to a common colourspace (such as sRGB or CIELab), and probably remove the profile.

Another complication is that there is more than one sRGB colourspace! This is really awkward. Personally I standardise on "no profile" sRGB. But my processing is for artistic/aesthetic purposes. If I needed to retain colour fidelity through to a printed product, I would retain profiles.

I guess you're right about what profiles are mostly used for, but in principle *any* color space conversion can be described as the application of profiles, can't they?

Yes. And if your image has a profile, you should convert it with another profile, not with "-colorspace".

Does this go down the same line as "RGB, CMY, HSL are color systems, not color spaces" (or similar), a senctence I read somewhere on the (btw: phantastic!) IM usage pages?

Yes. The terminology isn't standardised, so is confusing. I find it easiest to think of an image as two things: a load of pixel values, and metadata that describes what those pixel values represent. The metadata might simply say, "There are 3 channels that represent CMY", or it might be far more complex that defines the relationship between the pixel values and some absolute colour defintion.

Anyway, back to IM and the parallel existance of -colorspace and -profile: To me it seems that both identfy and convert's -colorspace operator ignore embedded profile information and only rely on IM-internal concepts of color spaces (or color systems) and corresponding conversion functions.

Yes. "-colorspace" ignores profiles.

On the other hand, -profile seems to work independently from -colorspace (although I haven't thoroughly tested this yet).

No. "-profile" will change colorspace metadata. For example, we make an RGB image, declare it to be sRGB, and convert it to CoatedFOGRA39. The colorspace is now CMYK.

Code: Select all

> convert xc:red -profile sRGB.icc -profile CoatedFOGRA39.icc p.jpg
> identify -verbose p.jpg

  Colorspace: CMYK
  Depth: 8-bit
  Channel statistics:
    Cyan:
:
    Magenta:
:
    Yellow:
:
    Black:
:
:
  Properties:
    date:create: 2014-04-14T21:16:08+01:00
    date:modify: 2014-04-14T21:17:21+01:00
    icc:copyright: Copyright 2007 Adobe Systems, Inc.
    icc:description: Coated FOGRA39 (ISO 12647-2:2004)
    icc:manufacturer: Coated FOGRA39 (ISO 12647-2:2004)
    icc:model: Coated FOGRA39 (ISO 12647-2:2004)

EDIT: I should stress that "Colorspace: CMYK" says what the four channels represent, but nothing more. If we then used "-colorspace HSV" it would get the conversion approximately correct, using simple formulae for the conversion from CMYK to HSV. But it would ignore the profile that gives the fine-tuning of exactly what the CMYK values represents. So a more accurate conversion would be "-profile sRGB.icc -colorspace HSV".

So for colorspace conversion one should use either the one or the other, but not both, right?

In a nutshell: yes.

[tcrass]

Snibgo,

thanks a lot for your exhaustive reply. I see somewhat clearer now, in particular with regard to the interrelationship between -profile and -colorspace.

When identify shows "sRGB", it means the image will be treated as sRGB unless you do any "-profile" processing. An embedded profile may mean the image isn't really sRGB, but most operations in IM don't depend on the colorspace anyway. If the output format takes profiles, it should be passed straight through.

Well, when calling (remember: the -delete operation is required to get rid of the thumbnail image embedded in the input.tiff)

Code: Select all

convert input.tiff -delete 1 output.jpg
convert output.jpg output.icc

the second command tells me:

Code: Select all

convert: no color profile is available `output.icc' @ error/meta.c/WriteMETAImage/2384.

In contrast, when trying to extract a profile directly from the input image via

Code: Select all

convert input.tiff -delete 1 input.icc

I do get an output file, which, according to iccdump, is a ProPhoto RGB profile.

The "-colorspace" command ignores profiles. As a general rule, it shouldn't be used on images with embedded profiles. If you really want to use "-colorspace" on an image with a profile, you should first use "-profile" to convert it to a common colourspace (such as sRGB or CIELab), and probably remove the profile.

I tried creating a jpeg in ITULab (don't currently have a CIELab profile on my system) using

Code: Select all

convert input.tiff -delete 1 -profile ITULab.icc output.jpg

but again, when trying to recover the specified ITULab.icc profile from the output file via

Code: Select all

convert output.jpg output.icc

IM tells me that there is no profile available. Also, identify doesn't find so much as a trace of a reference to a profile and claims the image to be in sRGB.

On the other hand, -profile seems to work independently from -colorspace (although I haven't thoroughly tested this yet).

No. "-profile" will change colorspace metadata. For example, we make an RGB image, declare it to be sRGB, and convert it to CoatedFOGRA39. The colorspace is now CMYK.

Agreed. I could verify this using one of the CMYK profiles available on my system. Still wondering why no LAB profile gets embedded in the output.jpg from above.

EDIT: I should stress that "Colorspace: CMYK" says what the four channels represent, but nothing more. If we then used "-colorspace HSV" it would get the conversion approximately correct, using simple formulae for the conversion from CMYK to HSV. But it would ignore the profile that gives the fine-tuning of exactly what the CMYK values represents. So a more accurate conversion would be "-profile sRGB.icc -colorspace HSV".

So for colorspace conversion one should use either the one or the other, but not both, right?

In a nutshell: yes.

Wait a second -- the CMYK to HSV example conversion seems "outside the nutshell"! Since the first step is performed using a profile, while for the conversion from sRGB to HSV you rely on IM's built in direct conversion equations, right?

Anyway, it's past midnight already, I need to get some sleep...

Best regards --

Torsten

[snibgo]

I would need to see your input.tiff to comment. I don't know what happens if you try to store Lab pixels in jpeg.

You might gain some insight from a file I made:

If your browser respects profiles, "red" is in red, "blue" is in blue. If it ignores profiles, the colours are green and red. This is because I have converted it to a weird profile. This can be converted to JPG:

Code: Select all

convert redBlue.png redBlue.jpg
convert redBlue.png -strip redBlue2.jpg

Convert gives a warning, but writes the profile to redBlue.jpg. redBlue2.jpg doesn't contain the profile. You can extract the profile with either ...

Code: Select all

convert redBlue.png rb.icc
convert redBlue.jpg rb2.icc

... and then apply it to other files.

[snibgo]

So a more accurate conversion would be "-profile sRGB.icc -colorspace HSV".

Wait a second -- the CMYK to HSV example conversion seems "outside the nutshell"! Since the first step is performed using a profile, while for the conversion from sRGB to HSV you rely on IM's built in direct conversion equations, right?

Yes, I have converted so sRGB using a profile, then used IM's simple conversion equations. (Which are mostly given at http://www.imagemagick.org/script/comma ... colorspace , though for some reason HSV isn't.)

This is "within the nutshell" in the sense that the first conversion has translated the image into something that IM can process without bothering about profiles.

This is one reason I do most of my processing in sRGB -- because IM (and most other software) knows how to process it. After converting to sRGB, I can easily "-colorspace" to and from other colour models, and IM's other operations are predictable. If an image has an embedded profile, life isn't so simple.

For example, using my weird redBlue.png above:

Code: Select all

convert redBlue.png -fuzz 10% -fill purple -opaque lime r0.png

We might expect this to turn pixels that are close to "lime" (which is pure green) into purple. But the image has no colours near lime, so the command should do nothing. Right? Wrong, because of the profile. The effect of the command is to change red into a darkish green-blue that we might call "teal".

If I convert to sRGB first, I get the expected result, which is no colour change:

Code: Select all

convert redBlue.png -profile sRGB.icc -fuzz 10% -fill purple -opaque lime r1.png

[fmw42]

I believe that HSB and HSV are the same. (They seem to have different code implementations and I mentioned that they were the same to magick at one time). The options page for -colorspace is outdated for the second table and only gives a general idea of the transform, mostly, for the purpose of explaining the "intensity-like" channel. HSV is listed in the first table. I believe the code is in gem.c, if I recall.

Code: Select all

convert rose: -colorspace HSB -separate -combine rose_hsb.png

convert rose: -colorspace HSV -separate -combine rose_hsv.png

compare -metric rmse rose_hsb.png rose_hsv.png null:
0 (0)

Note that the processing using -separate -combine does change the data to HSB/HSV even though the image is labeled sRGB

[snibgo]

Ah, yes, HSB and HSV do seem to be synonyms. Thanks.

Code: Select all

convert ^
  hald:8 ^
  ( -clone 0 -colorspace HSB ) ^
  ( -clone 0 -colorspace HSV ) ^
  -delete 0 ^
  -metric RMSE -compare ^
  -format %%[distortion] ^
  info:

[fmw42]

This also demonstrates the equivalence (but using HALD is a better way):

Code: Select all

convert 2angular.png 2solid.png 2radial.png \
-set colorspace HSB -combine \
-colorspace sRGB colorwheel_HSB.png

convert 2angular.png 2solid.png 2radial.png \
-set colorspace HSV -combine \
-colorspace sRGB colorwheel_HSV.png

compare -metric rmse colorwheel_HSB.png colorwheel_HSV.png null:
0 (0)

[tcrass]

Hi there,

many thanks for this plethora of replies!

Currently I'm on a short Easter holiday trip, and I'm not sure when I'll find the time to do some experiments based on your replies. But be assured (to say it in Arnold Schwarzenegger's words): I'll be back!

Hoping you'll find plenty of colorful easter eggs (in whatever color space) --

Torsten