From embedded profile to LAB to sRGB

[tcrass]

Hi there,

back to color space -- the final frontier...

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.

As mentioned before, the input.tiff is available at http://www.tcrass.de/files/input.tiff. I tried to create a down-scaled version not containing the thumbnail, but I didn't succeed -- the resuting images always seemed to lack the profile embedded in the original image file. I tried something like

Code: Select all

convert input.tiff -delete 1 -resize 960x input-small.tiff

but when trying to extract the profile from input-small.tiff using

Code: Select all

convert input-small.tiff icc:input-small.icc

IM would always complain that "no color profile is available". In contrast, extracting the profile from the original image

Code: Select all

convert input.tiff -delete 1 icc:input.icc

worked flawlessly. (I also tried to re-apply the thus extracted profile during the minification process like

Code: Select all

convert input.tiff -delete 1 -resize 960x (-profile input.icc){0,3} input-small.tiff

but still no luck.)

To cut a long story short: Currently I can only offer the original 185 MB file!

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.

Neat! Firefox and my smartphone's Android browser mess it up, but Chromium does get it right!

You can extract the profile with either ...

Code: Select all

convert redBlue.png rb.icc

Confirmed, does work.

Code: Select all

convert redBlue.jpg rb2.icc

Does not work! Not only does convert give a warning (the usual "no color profile is available"), but the resulting icc file does have a size of 0 bytes!

It seems to me that convert (at least my 6.8.8 version) is unable to retain or embed profiles in TIFF and JPEG files...

This is one reason I do most of my processing in sRGB -- because IM (and most other software) knows how to process it.

But wouldn't it be rather pointless to create/scan images in, say: ProPhoto RGB, just to throw away the additional color/brightness information by converting it to sRGB prior to processing? I mean, I'm well aware that sRGB should be the final color space for many applications (e.g. Web galleries or customer-oriented print shops), but imagine I'd like to brighten up the darker parts of images. When immediately converting to sRGB, I would lose a lot of material (sensu discrete brightness steps) I could otherwise work with, wouldn't I?

After converting to sRGB, I can easily "-colorspace" to and from other colour models,

As mentioned in my initial posting, I'd like to do some processing in LAB (and possibly HCL). Shouldn't it be possible to apply an LAB profile, then strip the profile and *set* the colorspace to LAB using something like

Code: Select all

convert input.tiff  -delete 1 -profile LAB.icc -strip -set colorspace LAB <do some processing in LAB, e.g. -channel R -level 10%,90% +channel> <perhaps convert to HCL using -colorspace HCL> <do some processing in HCL> -colorspace sRGB output.jpg

However, when applying this line to my input image, the output looks terrible -- way too saturated and with a strong tint of blue. Maybe the problem is that -- just with sRGB -- there seem to be many different LAB color spaces. The only LAB profile I've currently got on my system is ITULab, which, I understand, uses different quantum ranges for representing L, a and b values, as compared to e.g. CIELab. (So which encoding does IM actually expect when working in LAB mode?) (BTW, does anyone know where to get from a CIELab icc file? Should be some sort of "identity" profile since, I understand, CIELab is one of the common PCSs, and color-management enabled software should be able to convert between CIELab and CIEXYZ as needed, right?)

Another questions that came to my mind: IM's -profile operator seems to have a somewhat unintuitive (at least to me) mode of operation since different occurances of this operator within the same command line have very different effects, which, in addition, depend on whether the input image does already have a profiel embedded or not. So I wonder if it would at all be possible to perform multiple profile-based colorspace conversions in a single command line? (Roghly like

Code: Select all

convert input.tiff -delete 1 <convert to LAB using -profile> <do some processing in LAB> <convert to LCH using -profile> <do some processing in LCH> <convert to sRGB using -profile> output.jpg

to stay with the previous example )

So much to learn, so little time...

Best regards --

Torsten

[snibgo]

Sorry, I missed the fact that you had uploaded input.tiff. For my computer, I have renamed it "inputCS.tiff". "identify -verbose" shows just the first image has a profile.

Instead of reading both images and deleting one, it is more efficient to just read one.

Both these commands create a tiff with embedded profile, which I can see with "identify verbose" or by converting to icc. "%IM%" just ensures I run my current IM, which is v6.8.9-0 on Windows 8.1.

Code: Select all

%IM%convert inputCS.tiff -delete 1 -resize 960x x1.tiff
%IM%convert inputCS.tiff[0] -resize 960x x2.tiff

%IM%convert x1.tiff x1.icc
%IM%convert x2.tiff x2.icc

The following works for me, with warnings on the first 2 commands:

Code: Select all

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

Neat! Firefox and my smartphone's Android browser mess it up, but Chromium does get it right!

You might find that upgrading Firefox cures that. I'm on v28.0. Or maybe it's an about:config parameter.

But wouldn't it be rather pointless to create/scan images in, say: ProPhoto RGB, just to throw away the additional color/brightness information by converting it to sRGB prior to processing?

Yes. You might want to do all your processing in ProPhoto, and finally convert to sRGB or whatever.

For my work, I have a choice with raw camera photos. I currently convert these to sRGB and process from there. Would a different colorspace give me better quality? Perhaps. I don't know. I would need to experiment.

The following two commands give nominally the same results:

Code: Select all

%IM%convert inputCS.tiff[0] -profile GenericLabProfile.icc -strip -set colorspace LAB -colorspace sRGB x3.tiff
%IM%convert inputCS.tiff[0] -profile GenericLabProfile.icc -profile sRGB.icc -strip x4.tiff

With Microsoft Photo Viewer, x3.tiff looks identical to inputCS.tiff[0].

In the foreground at the bottom, x4.tiff looks slightly more saturated (or perhaps shifted towards green) than x3.tiff. But converting to HSL and finding the saturation min/max/mean shows that x4 is less saturated than x3.

I can't remember where I got GenericLabProfile.icc from. I've uploaded it to https://www.dropbox.com/s/korzkwggvm8nd ... rofile.icc

Another questions that came to my mind: IM's -profile operator seems to have a somewhat unintuitive (at least to me) mode of operation ...

And to me!

There is also a "-set profile" command. It may be more intuitive, but I haven't played with it.

So I wonder if it would at all be possible to perform multiple profile-based colorspace conversions in a single command line?

Yes, it is possible.

[tcrass]

Hi,

Instead of reading both images and deleting one, it is more efficient to just read one.

cool, thanks for the hint! (I really don't understand why there are so many people out there who just don't appreciate the power of the command line...)

Both these commands create a tiff with embedded profile, which I can see with "identify verbose" or by converting to icc. "%IM%" just ensures I run my current IM, which is v6.8.9-0 on Windows 8.1.

Code: Select all

%IM%convert inputCS.tiff -delete 1 -resize 960x x1.tiff
%IM%convert inputCS.tiff[0] -resize 960x x2.tiff

%IM%convert x1.tiff x1.icc
%IM%convert x2.tiff x2.icc

Again, I *can't* confirm this. After applying any of the resize commands, the profile's gone. And this seems to be a general problem -- it's not specific for the resize operation. Even without applying any operation at all (like in

Code: Select all

convert input.tiff output.tiff

) the profile gets purged! Apparently, passing the TIFF through any of the IM tools, in whatever manner, seems to be sufficient for this to happen. Very annoying since I'm currently in the process of scanning some 3000 slides. Of course, it occasionally happened that I accidently scanned a batch of slides upside-down, and I just realized some 10 minutes ago that when correcting their orientation using

Code: Select all

mogrify -rotate 180 *.tiff

those scans are no longer aware of the fact that their pixel values are actually in ProPhoto RGB... :/)

You might find that upgrading Firefox cures that. I'm on v28.0. Or maybe it's an about:config parameter.

Yeah, I guess it's some about:config thing -- I dimly remember to once have played around with Firefox's (or, as we say on Debian, Iceweasel's) color management settings.

I can't remember where I got GenericLabProfile.icc from. I've uploaded it to https://www.dropbox.com/s/korzkwggvm8nd ... rofile.icc

Great, thanks! I'll play around with it once I can resolve the "profile not preserved/embedded in TIFF output" issue (which to me is even more pressing right now...)

There is also a "-set profile" command. It may be more intuitive, but I haven't played with it.

Ah, thanks! (It's so easy to overlook something in the huge pile of IM documentation...) And it seems to do exactly what one would expect: embed a given profile into an image! (I'd love if -profile didn't -set profile's job if there's no profile already embedded... It's one of these occasions where ImageMagick behaves a little bit too magick for my taste, just like this automatic conversion of grayscale PNGs to IM's internal grayscale representation, while one non-gray pixel is sufficient to convert it to sRGB...) On one of my rotated, bare TIFFs (which had lost their profile information during rotation, see above) I tried

Code: Select all

convert rotated.tiff -set profile ProPhotoRGB.icc output.png

and the resulting PNG did in deed have the profile embedded and looked perfect in some profile-aware viewers I tried (DigiKam, GwenView).

So now I can slowly begin to imagine how this...

So I wonder if it would at all be possible to perform multiple profile-based colorspace conversions in a single command line?

Yes, it is possible.

...could be done.

Again the bottom line is: IM 6.8.8 (6.8.8-9 in Debian Experimental, to be precise) screws up when it should preserve/embed an icc profile in (at least!) TIFF and JPEG output images.

I guess I'll have to wait until 6.8.9 finally shows up in the repositories...

Regards --

Torsten


P.S. @anthony, snibgo: In http://www.imagemagick.org/Usage/formats/#profiles, there are two dead links to snibgo's homepage -- might want to fix this some time?

[snibgo]

I happen to have v6.8.8-9 installed, and confirm that it drops profiles, as you say. Most versions don't have that bug. For example, v6.8.8-7 worked fine.

P.S. @anthony, snibgo: In http://www.imagemagick.org/Usage/formats/#profiles, there are two dead links to snibgo's homepage -- might want to fix this some time?

I had snibgo.com until it rusted away, had snibgo.org for a while, and recently took snibgo.com again. That page on profiles was available on http://archive-org.com/search?qq=snibgo.org for a while, but now seems to have gone. It was mostly a survey of how browsers treated profiles in 2010.

[tcrass]

Hi there,

I happen to have v6.8.8-9 installed, and confirm that it drops profiles, as you say. Most versions don't have that bug. For example, v6.8.8-7 worked fine.

just compiled 6.8.9 from source, and it seems to work fine w.r.t profiles in TIFF files.

Seems the 6.8.8 bug might have contributed quite a bit to my confusion regarding color space and profile operations...

Regards --

Torsten

[tcrass]

Hi there,

just found a file called "lab2lab.icm" on my hard disk (somewhere in argyll's folder structure). At a first glance (using iccdump) it seems to be similar to the GenericLabProfile.icc file courtesy by snibgo. One major difference is that it only contains an A2B0 tag, no B2A0 for the backward transform (which is actually identical to the forward transform) and a much smaller LUT -- containing only two rows, to be precise (which should be fine since the whole transform should be linear so that two points would be sufficient for defining it).

However, when trying to apply this profile to a TIFF (which already contains some other icc profile) like in

Code: Select all

convert input.tiff -profile lab2lab.icm output.tiff

I get an error:

Code: Select all

convert: unable to create color transform `icc' @ error/profile.c/ProfileImage/817.

The command works fine when using snibgo's GenericLabProfile.icc instead.

Any ideas? Does it have something to do with the missing B2A0 tag?

Regards --

Torsten

[snibgo]

What's the connection space? From your description, it seems that icm can only convert from lab to lab, and there's no connection space, so it couldn't be used for anything at all.

[tcrass]

Snibgo,

What's the connection space? From your description, it seems that icm can only convert from lab to lab, and there's no connection space, so it couldn't be used for anything at all.

in both cases the PCS is set to Lab -- at least that's how I interpret the header output by iccdump. Here's your GenericLabProfile', header:

Code: Select all

icc:
Header:
  size         = 2756 bytes
  CMM          = 'appl'
  Version      = 2.2.0
  Device Class = Color Space
  Color Space  = Lab
  Conn. Space  = Lab
  Date, Time   = 14 Feb 2000, 12:00:00
  Platform     = Macintosh
  Flags        = Not Embedded Profile, Use anywhere
  Dev. Mnfctr. = 'appl'
  Dev. Model   = 0x0
  Dev. Attrbts = Reflective, Glossy, Positive, Color
  Rndrng Intnt = Perceptual
  Illuminant   = 0.964203, 1.000000, 0.824905    [Lab 100.000000, 0.000498, -0.000436]
  Creator      = 'appl'

and here's lab2lab.icm's header:

Code: Select all

icc:
Header:
  size         = 500 bytes
  CMM          = 'argl'
  Version      = 2.2.0
  Device Class = Input
  Color Space  = Lab
  Conn. Space  = Lab
  Date, Time   = 1 Dec 2009, 23:24:13
  Platform     = Microsoft
  Flags        = Not Embedded Profile, Use anywhere
  Dev. Mnfctr. = 'argl'
  Dev. Model   = '    '
  Dev. Attrbts = Reflective, Glossy, Positive, Color
  Rndrng Intnt = Absolute Colorimetric
  Illuminant   = 0.964203, 1.000000, 0.824905    [Lab 100.000000, 0.000498, -0.000436]
  Creator      = 'argl'

I put the whole file at http://www.tcrass.de/files/lab2lab.icm -- in case someone wants to try it out without grabbing it without installing argyll.

Regards --

Torsten

[snibgo]

Hmm, I don't know, sorry.

I note that GenericLabProfile has DeviceClass="Color Space" where lab2lab has "Input". Maybe that is significant. A trawl through CMS source code, and the ICC specification at http://www.color.org/icc_specs2.xalter , might provide clues. The spec on p29 says "... a ColorSpace profile shall contain the following tags: BToA0Tag AToB0Tag", so maybe that's the problem.

[tcrass]

Hey,

I note that GenericLabProfile has DeviceClass="Color Space" where lab2lab has "Input". Maybe that is significant.

missed that one! Sounds like a reasonable explanation, thanks!

Best regards --

Torsten