[distudio]

dstudio: I have a feeling you're seeing my out-of-camera sRGB files as over-saturated since you have a wide-gamut monitor and Firefox is set to display in Adobe RGB. The screenshots you showed earlier tend to support that. That would mean that your carefully-controlled color managed system is in fact being defeated by Pentax's "defective" JPG files.

I will have to investigate, in the interim and at the risk of drawing out further what is already quite a lengthy thread I have put together an example of ProPhoto vs sRGB image gamut.

The following image was shot RAW and converted to a 16bit ProPhoto colour space image in ACR (in order to display the ProPhotoRGB image accurately it was converted to sRGB colour space using Perceptual rendering intent).



I used the application "Colour Space" to plot the colour space histogram of the ProPhotoRGB image then I converted the file to sRGB using Absolute rendering intent which effectively clips all out of gamut colours. The images below represent those plots, left ProPhotoRGB, right sRGB (clipped). It's easy to see that the original image contained far more colour information.



I just hope this thread has helped other photographers better understand colour management.

[distudio]

The following were made using the camera's RAW file in Photoshop CS2. The left one was assigned sRGB right away. The right one was assigned Adobe RGB, then converted to sRGB afterwards using relative colorimetric intent with black point compensation and dithering enabled.



The two images are completely identical. There is no perceivable difference at all.

To me, all this proves is that the camera assigns colors differently than Photoshop does. Maybe the "intent" is different in the camera (absolute colorimetric, perceptual, etc.) Or maybe the color engines just give different results. But assuming that an Adobe RGB image converted to sRGB will become more saturated isn't necessarily true. In this particular case, it changed nothing at all.

I suspect this could be part of the problem, anything is possible in camera I guess, a poor approximation of the AdobeRGB colour space or incorrect camera device colour space, different rendering intent or different response of the colour management engine?

[GoremanX]

dstudio: I have a feeling you're seeing my out-of-camera sRGB files as over-saturated since you have a wide-gamut monitor and Firefox is set to display in Adobe RGB. The screenshots you showed earlier tend to support that. That would mean that your carefully-controlled color managed system is in fact being defeated by Pentax's "defective" JPG files.

oops, no. My tired mind was leaping to conclusions. You mentioned you have Firefox set to only color-manage images that have an embedded ICC profile. That means it would assume all JPG files from a Pentax camera do not have any profile, and thus would render those in sRGB regardless of your working space or monitor profile.

But the conclusion stands so far: Pentax embeds color profile in a non-standard way in JPG (and TIF) files straight from the camera.

[GoremanX]

I suspect this could be part of the problem, anything is possible in camera I guess, a poor approximation of the AdobeRGB colour space or incorrect camera device colour space, different rendering intent or different response of the colour management engine?

I wonder if maybe brofkand is using "Assign Profile" instead of "Convert to Profile". That would explain the over-saturation.

I can't believe anyone would call color management "easily doable" for a layman. I already learned most of this stuff 12 years ago, and I'm STILL getting hung up with modern applications. Granted, most of my current troubles stem from the way Pentax embeds color profiles. But it seems to me there's a heck of a lot to learn for someone who's never done color management before. I totally understand why the color management nay-sayers warn of the traps involved, any mis-step could ruin the colors without the user even realizing it.

On the other hand, I'm all for maximizing the quality of my pictures, which is why I'm making the effort to get this working in the first place

---

Last edited by GoremanX; 01-16-2010 at 04:19 AM.

[distudio]

oops, no. My tired mind was leaping to conclusions. You mentioned you have Firefox set to only color-manage images that have an embedded ICC profile. That means it would assume all JPG files from a Pentax camera do not have any profile, and thus would render those in sRGB regardless of your working space or monitor profile.

But the conclusion stands so far: Pentax embeds color profile in a non-standard way in JPG (and TIF) files straight from the camera.

That is how I have my Firefox set and I'm pointing it to the monitor profile. Working space isn't relevant in the context of a Browser but what's a little ambiguous is if untagged images are rendered to the selected screen profile (which would be a bit useless frankly) or are assumed to be and rendered as sRGB?

https://developer.mozilla.org/En/ICC_color_correction_in_Firefox

color correction for images in Firefox 3.5 ✩ hacks.mozilla.org

Interesting comment pasted from the link directly above:

"Jao wrote on July 10th, 2009 at 2:41 pm:

This is a major disaster that 3.5 no longer supports v4 profiles. Most current display calibrators generate v4 profiles and so color management will NOT correctly work in 3.5 whatever you set. Useless! Again, 3.0 did this just fine. Why break this? Very disappointing. This needs to be fixed ASAP."

Cheers,

[GoremanX]

That is how I have my Firefox set and I'm pointing it to the monitor profile. Working space isn't relevant in the context of a Browser but what's a little ambiguous is if untagged images are rendered to the selected screen profile (which would be a bit useless frankly) or are assumed to be and rendered as sRGB?

That's a good point. I don't know if "unmanaged" means "assume sRGB". That's how some applications define it, but not necessarily how Firefox sees it.

"Jao wrote on July 10th, 2009 at 2:41 pm:

This is a major disaster that 3.5 no longer supports v4 profiles. Most current display calibrators generate v4 profiles and so color management will NOT correctly work in 3.5 whatever you set. Useless! Again, 3.0 did this just fine. Why break this? Very disappointing. This needs to be fixed ASAP."

Oh wow, you just sent my head spinning on that one. I had NO IDEA there were 2 different series of the ICC specification. This opens up a whole new avenue of investigation, namely when each version became a standard. Maybe all these issues stem from an application's level of support for ICC profiles...

The way I'm reading it on the ICC web site, there are 2 concurrent versions of the ICC specification. The 2.x series and 4.x series. Each one has been around since long before the *ist D came out, so it's likely that Pentax is using the 4.x specification while many applications only support the 2.x.

I woke up in the middle of the night to type this... more research can happen in the morning!

[distudio]

I wonder if maybe brofkand is using "Assign Profile" instead of "Convert to Profile". That would explain the over-saturation.

I can't believe anyone would call color management "easily doable" for a layman. I already learned most of this stuff 12 years ago, and I'm STILL getting hung up with modern applications. Granted, most of my current troubles stem from the way Pentax embeds color profiles. But it seems to me there's a heck of a lot to learn for someone who's never done color management before. I totally understand why the color management nay-sayers warn of the traps involved, any mis-step could ruin the colors without the user even realizing it.

On the other hand, I'm all for maximizing the quality of my pictures, which is why I'm making the effort to get this working in the first place

Well I intend to check just how my system deals with native in camera generated sRGB and AdobeRGB files tomorrow. Most of the other issues are Browsers based and frankly given the state of colour management in Browsers I wouldn't suggest placing anything but sRGB images on the web.

[GoremanX]

I should've realized it; the vast majority of open source applications implement color management through the LittleCMS libraries. As is typical of all open source projects, they reuse existing projects for commonly-used functions. This is why all my applications do not detect any embedded color profile in Pentax cameras, they all use the same underlying library for that detection. So my hunt for answers in regard to Pentax file formats must move up the chain to the LittleCMS project...

[distudio]

As an aside, a Noritsu tech told me one time that wet process colour paper fits very nicely into the sRGB colour space, and that this was why Noritsu didn't bother with custom profiles.

Hi Bill,

I couldn't find any Noritsu profiles (maybe didn't look hard enough) but I did find some for the Agfa Dlab2 (Gen_Sensatis_dlab_V1.icc), bellow I've compared the DLab icc (wire-frame) with sRGB (solid left) and AdobeRGB (solid right) colour spaces (as viewed from the black point). It appears that neither of these working colour spaces fully utilise the gamut of the Dlab printer, I suspect that it would be the same for the Noritsu, fits nicely if you discount the clipping ;-)



Cheers,

[GoremanX]

So here's some stuff I learned from the Gimp mailing list and LittleCMS web site.

LittleCMS was used for color management in Firefox up until version 3.0, After that, they changed to another color management system that I'm not familiar with (don't know its name). LittleCMS is also used in Gimp, Inkscape, Digikam, and a slew of other applications, both open source and commercial. Anything that uses LittleCMS detects color profiles exactly the same way across all platforms.

The current version of LittleCMS is 1.18a. It natively supports v2 ICC profiles, and can handle "some" v4 ICC profiles. ICC v4 has been around since at least 2001, so it's very likely that Pentax embeds an ICC profile in their JPG and TIF images that LittleCMS does not detect properly. How applications react to this differs. Gimp and Krita just assume the colorspace should be interpreted as whatever working space is currently set. There are currently no settings to change this behavior. Digikam can be set to ask which profile should be used when none is detected, but only when editing pictures. The picture viewer just assumes they should be interpreted in the currently set working colorspace.

Currently, LittleCMS 2.0 is being developed. The direct quote from the developer blog is:

"Little CMS 2.0 is a full v4 CMM, which can accept v2 profiles. Little CMS 1.xx was a v2 CMM which can deal with (some) V4 profiles. The difference is important, as 2.0 handling of PCS is different, definitively better and far more accurate."

The developer blog can be found here and describes all the new features which will be included. It's very exciting stuff if you're into color management at all. When all is said and done, it looks like it will be ahead of Adobe's current ICC library.

I couldn't find a definitive date for when 2.0 will be released, and then it will be a while before applications start switching over since it's not directly backwards-compatible with LittleCMS 1.x.

So for now, if using an application that depends on LittleCMS for color management, JPG and TIF files straight from the camera need special attention for accurate colors. It's important to confirm that the right color profile has been assigned to the picture. If you never touch Adobe RGB and you don't color manage, or if you don't use any application that depends on LittleCMS, this is a non-issue. However it turns out a lot of applications use LittleCMS for color management without explicitly stating so (ie. Firefox).

I've asked for information regarding this on the LittleCMS mailing list and submitted some files for reference. I'm still waiting for a response, I suppose it's possible support for our cameras could be added to an upcoming update to LittleCMS, which would be awesome. I'd at least like to confirm whether Pentax embeds the color profile in a non-standard way, or if the color profile is in a version that LittleCMS can't read yet.

I find it telling that Pentax cameras render Adobe RGB pictures wrong on the built-in monitor. Does this mean Pentax uses LittleCMS (or some derivative) for color management in the camera's firmware? It's a very small and efficient software library that seems like it would be ideal for such a use. Its license allows it to be used in commercial applications, it's not nearly as restrictive as GPL'd projects.

[distudio]

I've asked for information regarding this on the LittleCMS mailing list and submitted some files for reference. I'm still waiting for a response, I suppose it's possible support for our cameras could be added to an upcoming update to LittleCMS, which would be awesome. I'd at least like to confirm whether Pentax embeds the color profile in a non-standard way, or if the color profile is in a version that LittleCMS can't read yet.

Looking into the EXIF data of a native k-x sRGB JPRG file using PhotoME the only clue as to colour space seems to be the following tag:

[Interoperability]
Interoperability Identification: R98: DCF basic file (sRGB)
Interoperability Version: 1.0

Looking into the EXIF data of a sRGB JPRG generated out of PS SC file using PhotoME yields a new section labelled "ICC Profile" which contains the embedded sRGB profile information.

I find it telling that Pentax cameras render Adobe RGB pictures wrong on the built-in monitor. Does this mean Pentax uses LittleCMS (or some derivative) for color management in the camera's firmware?

I would be surprised if they simply didn't colour manage the screen or at most they may alter the response to approximate a colour managed aRGB rendering (and not too accurately obviously).

[GoremanX]

Looking into the EXIF data of a native k-x sRGB JPRG file using PhotoME the only clue as to colour space seems to be the following tag:

[Interoperability]
Interoperability Identification: R98: DCF basic file (sRGB)
Interoperability Version: 1.0

Looking into the EXIF data of a sRGB JPRG generated out of PS SC file using PhotoME yields a new section labelled "ICC Profile" which contains the embedded sRGB profile information.

That's where I was misled initially and where a Gimp developer corrected me. Color management libraries care absolutely nothing about the EXIF data. They don't use that to determine the embedded color profile at all. In fact, the EXIF specification does not technically support having "Adobe RGB" specified in the ColorSpace tag. Color management libraries detect the embedded color profile itself, assuming they're able to understand it (and that's where versions come in). They look in a completely different part of the file. I'm not very familiar with the format of JPG files though, that's why I asked the LittleCMS devs to have a look at the ones from my camera.

I would be surprised if they simply didn't colour manage the screen or at the very most they may alter the response to approximate an colour managed aRGB rendering (and not too accurately obviously).

It seems like an odd oversight... obviously there's a color management library in the camera's firmware, otherwise it wouldn't be able to generate Adobe RGB files at all. That same library should easily be able to display an Adobe RGB file for an sRGB monitor, unless the playback application ignores the color management library.

[distudio]

I'm not very familiar with the format of JPG files though, that's why I asked the LittleCMS devs to have a look at the ones from my camera.

Neither am I but PS definitely reads the out of camera jpeg tags as an embedded profile.

It seems like an odd oversight... obviously there's a color management library in the camera's firmware, otherwise it wouldn't be able to generate Adobe RGB files at all. That same library should easily be able to display an Adobe RGB file for an sRGB monitor, unless the playback application ignores the color management library.

There is obviously a colour management system built in to process and map the RAW files to JPG in the required colour space but I would assume that the screen mapping would be independent and would require it's own profile and mapping hardware. It does appear to have some sort of LUT though hence the ability for it to be visually calibrated but that sub-system doesn't appear to have been extended to provide screen colour management.

[GoremanX]

There is obviously a colour management system built in to process and map the RAW files to JPG in the required colour space but I would assume that the screen mapping would be independent and would require it's own profile and mapping hardware. It does appear to have some sort of LUT though hence the ability for it to be visually calibrated but that sub-system doesn't appear to have been extended to provide screen colour management.

Well if they don't use LittleCMS, maybe they SHOULD The beauty of that library is that it doesn't just detect color profiles, it performs all color transformations and related functions. That's why I thought the upcoming version 2.0 was fascinating; it uses 32bit color processing internally and allows specifying colors as floating point, among many, many other things.

[Wheatfield]

Hi Bill,

I couldn't find any Noritsu profiles (maybe didn't look hard enough) but I did find some for the Agfa Dlab2 (Gen_Sensatis_dlab_V1.icc), bellow I've compared the DLab icc (wire-frame) with sRGB (solid left) and AdobeRGB (solid right) colour spaces (as viewed from the black point). It appears that neither of these working colour spaces fully utilise the gamut of the Dlab printer, I suspect that it would be the same for the Noritsu, fits nicely if you discount the clipping ;-)



Cheers,

They may not fully utilize the available gamut of the printer, but is that the same thing as the gamut of photographic paper?