16769 - (colorsync) Add cms (Color Management) support to Mozilla

Status: RESOLVED FIXED

(Core :: Graphics: Color Management, enhancement)

Description

[Svein Myhre]

As you probably know, your competitor, Microsoft, supports Apple ColorSync in
their browser. This makes it easy to get correct colors on the web. I'm a Color
Management specialist (at Agfa) and do a lot of presentations and road shows,
but since you're browsers don't support ColorSync, I have to use MS Explorer to
demonstrate the feature.

I haven't found any information that states if you are doing anything with this,
or not. I really hope you are writing ColorSync-support into the next version of
the browser..

Comment 1

[Matthew Tuck [:CodeMachine]]

I believe there was some ColourSync code around in "MozillaClassic" but the
current Mozilla has no ColourSync support (I think).  Mozilla.org would
appreciate the effort of anyone who would be willing to do this, if you know
anyone.

See http://www.mozilla.org/projects/colorsync/ for the old home page of the
project.

Comment 2

[Eli Goldberg]

[clarified bug title]

Comment 3

[Eli Goldberg]

Patrick,

	Do you know who this might go to? Guessing Compositor.

Comment 4

[Eli Goldberg]

*** Bug 18537 has been marked as a duplicate of this bug. ***

Comment 5

[Eli Goldberg]

[oops. that was a typo. the bug was marked as dupe of 16760.]

Comment 6

[Patrick C. Beard]

Reassigning all compositor bugs to kevin.

Comment 7

[Kevin McCluskey (gone)]

This bug is marked "future" because it is not critical for RTM (Release To 
Manufacturing). If anyone believes it is critical, please explain why in
this bug. 

Comment 8

[Jason Eager]

Added keyword "Help wanted" and cc'ed myself.

Comment 9

[Greg K.]

Does the new imagelib have any hooks for something like this?

Comment 10

[Kevin McCluskey (gone)]

CC'ing imagelib experts.

Comment 11

[Kevin McCluskey (gone)]

Build moving all existing future-P3 bugs to future-P4.

Comment 12

[Mike Pinkerton (not reading bugmail)]

*** Bug 186400 has been marked as a duplicate of this bug. ***

Comment 13

[Asaf Romano (gone)]

I'm 

Comment 14

[jhp (no longer active)]

Attachment: Colorsync branch diff

For reference, this is the code that was checked in on the
ColorSync_19980824_BRANCH tag a long time ago.	Might be useful.  Be aware
though that this code was checked in under the NPL license only (not
tri-licensed).

Comment 15

[eddy]

How about adding LittleCMS support as well (for non-proprietary OSs), with
profiles specified in preferences?

Comment 16

[Simon Fraser [no longer active]]

Is this easier now that we're using CGImage for images?

Comment 17

[Stuart Parmenter]

It might be easier for a month or two, but we're about to switch all of GFX to
cairo which is going to complicate things again...

Comment 18

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 338743 has been marked as a duplicate of this bug. ***

Comment 19

[Christian 'CeeJay' Jensen]

Some testcases and info:

http://stilllifewith.com/2006/05/11/chaos-and-colorspace/
http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html
http://www.color.org/version4html.html

Ofcourse firefox currently fails all the tests, but they nicely illustrate what improvement in color rendering Firefox could have if it supported color management using embedded ICC profiles.

As an (amateur) photographer this bug certainly has my vote.

BTW is the component correctly assigned ? .. It isn't just on Mac's that Firefox can't render colors correctly.

Comment 20

[John Edgar]

(In reply to comment #19)
> Some testcases and info:
> 
> http://stilllifewith.com/2006/05/11/chaos-and-colorspace/
> http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html
> http://www.color.org/version4html.html
> 
> Ofcourse firefox currently fails all the tests, but they nicely illustrate what
> improvement in color rendering Firefox could have if it supported color
> management using embedded ICC profiles.
> 
> As an (amateur) photographer this bug certainly has my vote.
> 
> BTW is the component correctly assigned ? .. It isn't just on Mac's that
> Firefox can't render colors correctly.
> 

I also agree that his might be an ICC profile issue, not necessarily just ColourSync, as I find I get this issue in windows too.

As a professional photographer I find this VERY annoying, and I run into issues with it daily. 

This is a severe bug and I think it should be reflected as such, I also believe it should be marked as P2.

Comment 21

[Ryan Flint [:rflint] (ping via IRC for reviews)]

*** Bug 335627 has been marked as a duplicate of this bug. ***

Comment 22

[Jo Hermans]

*** Bug 348583 has been marked as a duplicate of this bug. ***

Comment 23

[Håkan Waara]

Will our move to cairo-cocoa help here? Does cairo support colorsync, or will?

Comment 24

[tor]

Attachment: JPEG ICC proof of concept

Proof of concept using lcms to handle ICC profiles in JPEG files.  Links to system lcms.  iccjpeg.[ch] from lcms source, which is under the MIT public license.

Comment 25

[tor]

Attachment: JPEG ICC proof of concept

Try harder to match image and profile colorspace, don't abort if there's a mismatch, allow a monitor output profile to be used instead of sRGB, and some debug spew.

Comment 26

[tor]

Attachment: JPEG ICC proof of concept

Forgot new files.

Comment 27

[Ryan Flint [:rflint] (ping via IRC for reviews)]

*** Bug 355782 has been marked as a duplicate of this bug. ***

Comment 28

[Jeffrey Friedl]

The essense of color management is proper conversion from device-independent color data in an image file to the device-dependent data for a monitor, printer, etc. I don't know of any browser that gets this right, so I thought I'd record here the Right Way to do it (IMHO :-)

Unless the color data has been created for a specific monitor, it must be converted from the color space of the image to the local monitor's color space. The monitor color space can be retreived from the OS. Once the image color space has been identified, the conversion can be made on a Mac with colorsync, or platform independntly with LCMS as someone has already shown earlier in this bug.

In either case, the conversion is FROM a color space TO a color space, and a big quesiton is how to identify the FROM color space. I suggest the following to identify the FROM source color space:

   1) if there is an embedded color profile, use that directly.

   2) if the exif field 'InteroperabilityIndex' has the value 'R98', use the sRGB color space (using a locally cached copy of the sRGB color profile).

   3) if the exif field 'InteroperabilityIndex' has the value 'R03', use the AdobeRGB color space (using a locally cached copy of the Adobe RGB color profile).

   4) if the exif field 'ColorSpace' has the value '1', use the sRGB color space as with step 2

   5) use an application-specific default color space, which should default so sRGB unless the user overrides it.

On page 2 of this writeup:
    http://regex.info/blog/photo-tech/color-spaces-page1/
are many example images showing the problems of wrong color interpretation.

It would be wonderful if Firefox could be the First Browser with a Colormetric Clue.

Jeffrey
-------------------
http://regex.info/blog

Comment 29

[eddy]

Not to be pedantic or anything, but aren't all images device dependent as long as they are associated with a devices profile (camera, scanner, etc.) attached to them.  They only become device independent if they are in the CIE xyY color space already, right?  Also, what point should we go beyond just plain embedded Color Profile support, with a default (sRGB input profile)?  You mentioned looking at the exif 'InteroperabilityIndex' and 'ColorSpace' fields.  Another step in this direction would be if we do like what they are saying here in this excerpt from the LittleCMS tutorial:
  Another usage would be to build colorimetric descriptors for
  file images that does not include any embedded profile, but
  does include fields for identifying original colorspace.

  One example is TIFF files. The TIFF 6.0 spec talks about
  "RGB Image Colorimetry" (See section 20) a "colorimetric" TIFF
  image has all needed parameters (WhitePointTag=318,
  PrimaryChromacitiesTag=318, TransferFunction=301,TransferRange=342)

  Obtain a emulated profile from such files is easy since the contents
  of these tags does match the cmsCreateRGBProfile() parameters.

  Also PNG can come with information for build a virtual profile,
  See the gAMA and cHRM chunks.

Comment 30

[Jeffrey Friedl]

|> Not to be pedantic or anything, but aren't all images device dependent
|> as long as they are associated with a devices profile (camera, scanner,
|> etc.) attached to them.

No. RGB color spaces are defined in terms of CIE xy colors, so they're all
device independent in that sense. There are some device dependencies built
into the range of colors that a color space can describe -- the color space
I built for my monitor when I calibrated it can describe only the colors my
monitor can actually produce -- but this is sort of tangential.

In any case, it's sort of a moot point because the common color spaces
(sRGB, AdobeRGB, ProPhoto RGB, Wide Gamut RGB) are all purely device
independent (although yes, sRGB was designed to mimic the circa 1996
Average Joe's PC CRT).

What's important is to be able to convert that source-space data to
monitor-space data, and that means the ability to identify both the source
and destination space, and to be able to convert. LCMS provides the
conversion, the OS provides the monitor's space via its profile, so the
last step is to properly identify the source image color space. That's what
the bulk of my comment talked about.

|> Also, what point should we go beyond just plain embedded
|> Color Profile support, with a default (sRGB input profile)?  You mentioned
|> looking at the exif 'InteroperabilityIndex' and 'ColorSpace' fields.

My suggestions are borne out of being pragmatic, although nothing in my
post would have let you know that. Sorry. I should have been more verbose.

The original Exif standard allowed for "is sRGB" and "not sRGB". If the "is
sRGB" flag is on ("ColorSpace" has the value "1"), the color data is sRGB.
(One can have long discussions as to why the Exif standard was written this
way, and whether it was wise or not, but that's all not really relevant to
the topic at hand.)

The DCF (digital-camera file system) standard augmented this with the
"InteroperabilityIndex" thing. "R98" means "Revision 1998", I believe.

The DCF standard was updated in 2003 to allow for Adobe RGB. Simply by
using "R03" (Revision 2003) in the InteroperabilityIndex field, you've
indicated that your color data was written using the Adobe RGB space. (To
be clean, you should also set the ColorSpace field to 0xFFFF, meaning
"not sRGB".)

To be clear, I think this is all horribly kludgey, but this is how the
standards were written, and how the vast majority of cameras produce
images. I tested dozens of semi-pro to pro dSLRs, and not one of them
includes an sRGB color profile when it creates an sRGB-encoded image.

And one last thing about the five-step space-identification method detailed
in my previous comment: it's how Adobe Photoshop determines an image's
color space. I certainly should have mentioned that before.

    Jeffrey

Comment 31

[eddy]

Yeah, I was just saying that the data from a camera/scanner, if it has a device specific profile associated with it, is actually as device dependant as the one going out to the screen.  Because can't monitor profiles be inverted to also convert back to CIE?  I wasn't really thinking in terms of the standard intermediary profiles like Adobe RGB, sRGB, etc....  But on an on topic note ;-).  I do completely agree with how it should determine input profile.  Sounds pretty reasonable.  In the proof of concept code, it looks like it only has one rendering intent shouldn't that be customizable too?

Comment 32

[Jeffrey Friedl]

|> Yeah, I was just saying that the data from a camera/scanner, if it has a
|> device specific profile associated with it, is actually as device
|> dependant as the one going out to the screen.

Well, perhaps we're talking about slightly different things. If there's a
profile associated with the image, it describes how to turn the image data
(whatever it may be) into absolute, device-independent color.

In common practice, though, JPG images straight from a camera or scanner
have been converted within the camera/scanner to a generic profile like
sRGB or AdobeRGB. RAW image files, of course, are as device-dependent as
you can get(!)

    Jeffrey

Comment 33

[Richard Brackin]

Attachment: File attached showing another example of incorrect color.

I would also like to voice my concern over the relative lack of attention to Color Management in the SeaMonkey mail reader.

I am an art director for a large pritning corporation and I am also trained in color management. We sometimes email JPEGs for soft proofs to customers, and they sometimes send them to me. Proper color rendering is important to anyone involved in the printing, photography, advertising, and graphic arts professions.

I have a question as to how Sea Monkey handles display profiles when the mail reader window is dragged across to a second or third monitor? 

Long story short, I've attached this screenshot showing a differential in color rendering from a correctly rendered file in Photoshop vs. an incorrectly rendered file in SeaMonkey.  The images are labelled accordingly. I have converted them to sRGB prior to saving this jpeg.

Comment 34

[david sanger]

This is very important to professional photographers. Firefox distinguishes iteslef on the Mac by NOT having COlorsync support which is too bad.

For sRGB pix there is less difference but for all other image color spaces we really need to be able to see proper color as per ICC profiles.


Please up the priority

Comment 35

[david sanger]

Apple's new (11/1/6) tech note on Image Color management is at

http://developer.apple.com/technotes/tn2006/tn2115.html#TNTAG4

interesting test profiles are at

http://developer.apple.com/technotes/tn2006/downloads/tn2115_Images.zip

Comment 36

[Chris Casciano]

Attachment: Sample JPG with embedded profile

This JPG is pulled form the apple download and has a test RGB profile that  accentuates the effect of no color management. In applications that read the profile the type is green and reads "The embedded test profile is used". In applications that don't it is blue and reads "The embedded test profile not is used" [not in red]. The overall effect is that without the profile data parts of the image that are intended to be green appear instead in blue and what is intended to be black is displayed in red.

Comment 37

[Stuart Parmenter]

I'd really like to get this in for 1.9 -- more and more photos on the web, etc.  We need them to look right.

Comment 38

[froodian (Ian Leue)]

*** Bug 361951 has been marked as a duplicate of this bug. ***

Comment 39

[tor]

Attachment: add lcms.h to system-headers to make SELinux happy

Comment 40

[tor]

Attachment: fix grayscale images with profile information

Comment 41

[tor]

Attachment: let's try that again...

Comment 42

[tor]

Attachment: color correct PNGs as well

Comment 43

[Stuart Parmenter]

Attachment: windows profile snippet

here is a snippet of code to the the main monitor's profile on windows (based on the previous patch)

Comment 44

[Glenn Randers-Pehrson]

Re: color correcting PNGs as well

There should also be a check for the sRGB chunk, just prior to the check
for gAMA/cHRM chunks.  If one is found, then instead of doing png_get_gAMA()
and png_get_cHRM(), simply fill in the proper gamma, whitepoint, and primary
values from the PNG/sRGB chunk spec.

Comment 45

[tor]

Attachment: handle sRGB and include win32 profile code

Respect sRGB chunk (though this doesn't have gamma/whitepoint/primary information - just says that the data is sRGB and gives a rendering intent we ignore for now).  Also includes pav's win32 profile code.

Comment 46

[Glenn Randers-Pehrson]

That's better, but there should be some "else {}" so that if iCCP is present,
sRGB, gAMA, and cHRM are not checked, and if sRGB is present gAMA and cHRM
are not checked.  When sRGB and gAMA are both present, the gAMA provides a
lower-quality backup in case sRGB isn't recognized.  Same when iCCP and gAMA
(and maybe cHRM) are present, the iCCP is considered to be the highest quality.

Comment 47

[tor]

Attachment: handle sRGB rendering intent

Comment 48

[tor]

(In reply to comment #46)
> That's better, but there should be some "else {}" so that if iCCP is present,
> sRGB, gAMA, and cHRM are not checked, and if sRGB is present gAMA and cHRM
> are not checked.  When sRGB and gAMA are both present, the gAMA provides a
> lower-quality backup in case sRGB isn't recognized.  Same when iCCP and gAMA
> (and maybe cHRM) are present, the iCCP is considered to be the highest quality.

We go through iCCP, sRGB, gAMA/cHRM in steps - if the previous chunk doesn't exist or the profile setup fails for some reason (the "!profile" part of the check), we try the next lower version of colorimetry information.

Comment 49

[Glenn Randers-Pehrson]

>in steps

Ah, OK.  I wasn't paying attention to the effect of "!profile" which is
exactly what I wanted.

Also, the patch should delete iCCP and cHRM from the list of unused chunks in nsPNGDecoder.cpp around line 102, in case the system libpng is being used.

Comment 50

[tor]

Attachment: remove iCCP and cHRM from unused chunk list

Comment 51

[tor]

*** Bug 338277 has been marked as a duplicate of this bug. ***

Comment 52

[tor]

Attachment: color correct everything

Corrects GIF/PNG/JPEG/CSS - untagged images or css colors treated as sRGB/perceptual.  Won't build with non-cairo gfx without some ifdef love.

Comment 53

[tor]

Attachment: update to tip

Comment 54

[tor]

Attachment: try to obtain output profile information from _ICC_PROFILE and XFree86_DDC_EDID1_RAWDATA on gtk

Comment 55

[tor]

Attachment: typo

Comment 56

[tor]

Attachment: missed a file

Comment 58

[Glenn Randers-Pehrson]

(In reply to comment #57)
> *** Bug 368794 has been marked as a duplicate of this bug. ***

It's not a dupe.  It merely has an incorrect gamma value which Firefox is handling properly.

Comment 59

[tor]

Attachment: update to tip

Comment 60

[tor]

Attachment: update to tip

Comment 62

[Loreno Heer]

According to http://en.wikipedia.org/wiki/ColorSync the windows version of ColorSync was discontinued. Does this mean Colour Management in Firefox won't work on a Windows platform?

Comment 63

[WulfTheSaxon [:Wulf]]

(In reply to comment #62)
> According to http://en.wikipedia.org/wiki/ColorSync the windows version of
> ColorSync was discontinued. Does this mean Colour Management in Firefox won't
> work on a Windows platform?

No, as ColorSync is not the only form of color management. The attachments here currently support ICC color management.

Comment 64

[WulfTheSaxon [:Wulf]]

Why is there no Priority or Target Milestone for this bug?

Comment 65

[Andy Piper]

Is there any support that users can give in order to get this bug fixed? It's annoying that I have to switch to Safari in order to see the true colours of my photos on Flickr.

Comment 66

[Ryan VanderMeulen [:RyanVM]]

This bug is wanted for Gecko 1.9 (Firefox 3.0). There was a patch attached to it less than a month ago. So if you want to help, keep the spam out of this bug and let the developers do their thing uninterrupted.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 67

[Stuart Parmenter]

We're working on it and expect that this will land sometime during this next alpha (a4) period.

Comment 68

[Simon Fraser [no longer active]]

Sorry, I kept reading "cms" as "content management system".

Comment 69

[Håkan Waara]

(In reply to comment #68)
> Sorry, I kept reading "cms" as "content management system".
> 

Me too. I've never even heard the acronym "cms" used before..

Comment 70

[John Edgar]

(In reply to comment #69)
> (In reply to comment #68)
> > Sorry, I kept reading "cms" as "content management system".
> > 
> 
> Me too. I've never even heard the acronym "cms" used before..
> 

That's because "cms" isn't a real acronym for anything in the colour management world. Someone just made it up. The title currently reads Add Colour Management Support (Colour Management) Support to Mozilla.. I think..  :|

Nice to see some people working on this by the way.., I'm pretty sick of dealing with clients using FF seeing desaturated colours in my work. (srgb)

Comment 71

[David Forthoffer]

"CMS" means "Color Management System". Contrast with "CMM" or "Color Management Module".
Although the latest International Color Consortium (http://www.color.org) color profile specification does not mention "CMS", spec ICC.1:1998-09 (http://www.color.org/ICC-1_1998-09.PDF) does mention it.

Comment 72

[Craig Ringer]

Since there are reasons to use both relative colorimetric+blackpoint compensation and the perceptual rendering intent, the ability to control which of these is chosen in about:config would be handy.

On a side note: Some of the people here appear to be under the impression that adding colour managemnet support to Moz and respecting embedded profiles will result in *accurate* colour. This is probably not the case. As one person explained very clearly above, ICC colour management involves a transformation from a source colour space to a destination colour space (via the device-independent L*A*B space). If your monitor is not accurately profiled, your colour will not be accurate.

Improved results should still be seen on source images that're in colour spaces significantly different from the default (probably sRGB) space. They'll look better, but they won't be accurate, and will be useless for soft proofing.

I work for a newspaper and am yet to see a single non-agency customer who knows what a colour profile or monitor calibration are, let alone has a correct colour setup. Soft proofing still isn't viable with these people (and if it was, we'd be using PDF and Adobe Reader since it already has decent colour support).

Comment 73

[Loreno Heer]

One could buy a "Gretag MacBeth Eye-One Display 2" for the calibration. They are not that expensive. But even on a callibrated monitor a picture will not allways result in *accurate* colour, if the monitor is not capable of displaying all the colours of the profile. The only monitor I know of that currently supports the full Adobe RGB space is the Eizo CG221.

But nevertheless implementing this, will allow one too see adobe rgb etc.. pictures more than they should be. Currently they look very different from how they look like in a colour managed software. (Like xnview or photoshop)

Comment 74

[Chris Murphy]

The issue of rendering intent is maybe a little tricky, but I think considering the current state of the affair (i.e. no color management in the browser, and even when there is, the vast majority of displays will not be calibrated & profiled), the rendering intent is trivial.

In an ICC v2 context, which is the current paradigm, to get parity with images displayed in Photoshop necessitates Relative Colorimetric + Black Point Compensation rendering to the display profile. I have been told BPC is supported in ColorSync since 10.4, so this is something that could be deferred to the OS. However, for cross platform reasons, it might be better/easier/consistent to just use Relative Colorimetric.

Moving forward with ICC v4, perceptual is a more appropriate rendering intent to use by default because gamut and dynamic range mapping is handled in a much more logical way than in v2. As we currently do not yet have publicly distributed ICC v4 profiles for intermediate color spaces such as sRGB, ProPhoto RGB, or Adobe RGB (1998), I suggest Relative Colorimetric for the rendering intent to display rather than Perceptual.

Comment 75

[Chris Murphy]

Regarding non-image data. What about HTML colors? These colors are essentially always untagged, and should also be treated with sRGB as the assumed source, and display compensation used in the same manner as with images. Otherwise, images and their neighboring colors (such as a background, or text) will not match, if a match was intended by using the same numeric values in an image and in non-image areas.

The closest reference I see for what should be done is the W3C CSS2 specification.
http://www.w3.org/TR/CSS21/
14.3 Gamma correction

For a document that has a draft date of November 2006, it's using archaic terminology. QuickDraw on the Mac? CRTs? Ahem, moving on.

The idea that gamma (1) correction, given the state of affairs with display technology, is the minimum handling is just bad advice. There is no GPU acceleration available for gamma only correction, whereas using Image I/O on Mac OS will cause color space conversions to occur on the GPU on any Macintosh sold in the last few years (what, maybe 4 years now?). And I believe the same is now possible for Windows Vista. So really the minimum handling, should also be practical which gamma only correction is not.

The tone reproduction curve of displays is variable, not merely between platforms but between displays. The primaries used are also variable between displays. Compensating for TRC, or the RGB primaries, but not both, is half-assed. Thus all of the "minimum handling" suggestions in this spec are flat out incorrect. Display compensation is needed across the board on all platforms for any attached display, there is no free lunch for Windows or X11 as this spec indicates.


(1) I note that the correct term is "tone reproduction curve" or "tone response curve" for a display, which is defined with a gamma function. Gamma itself is not the same thing as TRC, it's an variable. So none of the terminology is being used correctly.

Comment 76

[Jeffrey Friedl]

|> to get parity with images displayed in Photoshop necessitates Relative 
|> Colorimetric + Black Point Compensation rendering to the display profile

Could you explain this a bit more, Chris? What does "parity with images displayed in Photoshop" mean?  What kind of images are you talking about... photos? Logos? Art?  Every discussion of rendering intents I've ever seen recommends perceptual rendering for photographic images.

In a web context, there are three types of images I can think of:

  * Photos
  * Logos / mastheads / etc.
  * "drawing" (buttons, tabs, etc.)

If one could distinguish among these perfectly, you'd generally want to do the same color management for them as done for HTML/CSS/Flash colors, since they're intended to mesh with them. The same might be said for logos, mastheads, and such.

Safari has approached this issue by effectively doing no color management for images that have no profile, but they have gotten a lot of heat for it because that means that images right from the camera (which have no embedded profile, at least for the vast majority of cameras) render incorrectly.

A better approach, I think, would be to recognize not only *embedded* color profiles, but color profiles indicated by reference (via the "ColorSpace" and "InteroperabilityIndex" metadata tags). All modern digital cameras produce these tags, so images right from the camera would be rendered correctly. (How well they are *displayed* is still up to the quality of the user's monitor and its calibration, of course, but that's out of our hands.)

A few more details are here:
http://regex.info/blog/photo-tech/color-spaces-page7/#Suggestions4

Comment 77

[Chris Murphy]

>What does "parity with images displayed in Photoshop" mean?

If you want images to look the same in a web browser as they do in Photoshop.

However...

Most display profiles currently do not correctly describe the dynamic range of the display, because they contain bogus black point information such that RGB 0,0,0 = L* 0, which of course isn't possible. Since this tells the CMS the dynamic range of the source and destination are the same, there's no difference between RelCol and RelCol+BPC to the display, if the source profile is one of the common intermediate color spaces (i.e. sRGB, ProPhoto, Adobe RGB (1998)).

For those who care, RelCol + BPC is the way to go today, since that's how Photoshop displays their images.


>What kind of images are you talking about...photos? Logos? Art?

Photos.


>Every discussion of rendering intents I've ever seen recommends perceptual
>rendering for photographic images.

Yeah but gamut mapping in an ICC context is not dynamic. That means you will not get MORE gamut compression with a ProPhoto RGB (huge gamut) image, and less gamut compression with an sRGB image. Nor would you necessarily want this because the image itself may be rather achromatic yet be a ProPhoto RGB image, it merely contains few saturated colors in that space. Because we don't have intelligent rendering in an ICC context, we have to make the choice on an image by image basis.

The idea behind ICC v4 is to deal with this limitation in a much better way, which is why I'd suggest that perceptual rendering is a good/safe intent to use if both source and destination profiles are v4. However there are no v4 intermediate spaces (sRGB,  ProPhoto RGB, etc.) available publicly right now.

So that means, today, we're in a v2 paradigm, and so a smarter gamut/dynamic range mapping is only available through RelCol + BPC (in effect that is a fifth rendering intent). We largely get the same rendering as v4 perceptual with v2 RelCol + BPC. And in fact, that is the most commonly used rendering intent not only for display purposes, but also for output. When printing, ultimately I tell people that they should use the intent that they prefer, with merely general rules of thumb for what to look for. But the practical "rule" for intent when it comes to outut (printing) a photograph is the intent that renders the image the way you want it rendered.

>If one could distinguish among these perfectly, you'd generally want to do the
>same color management for them as done for HTML/CSS/Flash colors, since they're
>intended to mesh with them. The same might be said for logos, mastheads, and
>such.

Yeah. You could use RelCol + BPC for JPGs, and use RelCol only for everything else, assuming sRGB as the source profile for all.

>Safari has approached this issue by effectively doing no color management for
>images that have no profile, but they have gotten a lot of heat for it because
>that means that images right from the camera (which have no embedded profile,
>at least for the vast majority of cameras) render incorrectly

Yeah but as you point out, the vast majority of cameras have an EXIF tag that explicitly states the source space is sRGB and that too is being ignored. Ignoring that metadata and assuming something else (Monitor RGB, thus null transform) is as bad as ignoring an embedded ICC profile.

But it's equally inappropriate handling to treat untagged content as Monitor RGB in this day and age on any platform, including Mac OS. There's no reason for Apple to not be doing this correctly and at least complying with the minimum handling requirements for CSS per the W3C spec. And there's no compelling case for saying, as the W3C does, that Windows and X11 get a free pass for display compensation. It's just without merit. Of course displays don't have sRGB behavior on those platforms, either in terms of primaries or their TRC.

Comment 78

[tor]

Attachment: update to tip

Comment 79

[tor]

Performance before/after color profile patch on Fedora Core 6, P4 3.4GHz, optimized -Os, system lcms-1.15, Tp2, repeatable result:

  Before: 207.7 ms
  After:  221.7 ms 

Slowdown of approximately 6.7%.

Comment 80

[Chris Murphy]

At least on Mac OS, if the app uses Quartz, everything is color managed even in the event of untagged data so there is a transform in any event. Thus there is no penalty in performance for doing it correctly, i.e. assuming sRGB for untagged data, and informing the OS as such. It does the transform  using the current display profile, so really it's just a matter of passing an appropriate source to the OS for each image/object.

But FWIW, this should also be done on Windows. The idea that today's displays have sRGB behavior just by virtue of being attached to Windows is bogus. They need display compensation occurring in the web browser as well, and assuming sRGB as source for all untagged data.

Comment 81

[tor]

Alfred, could you look over the patch and see if there's any extra buffer copies that might be removeable?  You seem to be pretty good at finding those in the rest of the image code.

Comment 82

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(just fyi, before you go for final review on this, there's a few loose fprintf's that aren't #ifdef DEBUG_tor -- you may just want to use pr logging or something instead, if you don't want to take them out or ifdef them out)

Comment 83

[Alfred Kayser]

Tor, I don't easy targets for buffer copy optimizations (yet).

I think the only things to look for are:
* Could it be that the transform pointer is not null, but the actual transform is a null operation?
* Can in some case the doCmsTransform and the convertion to Cairo pixels be combined into one operation? Specifically for PNG, there may be cases where this is possible.

Probably best to go ahead with this patch and have the above two things be defined as followup bugs for further investigation.

Comment 84

[tor]

Attachment: add prefs to control, silence debug messages

Now controlled by two hidden preferences:

  gfx.color_management.enabled - what the name says, defaults to true
  gfx.color_management.display_profile - ICM profile filename to replace detected

Comment 85

[Chris Murphy]

1. Are these preferences found in about:config?
2. Is this functionality something that can be activated in the current daily builds?

Comment 86

[Chris Lawson (gone)]

(In reply to comment #85)
> 1. Are these preferences found in about:config?
> 2. Is this functionality something that can be activated in the current daily
> builds?

The answer to both questions is "Not yet."

Once the patch has been reviewed and super-reviewed, it will (probably very soon after) be checked in to trunk. About 24 hours after that, you should be able to use this functionality in nightly builds.

cl

Comment 87

[tor]

Attachment: expose prefs to about:config

Comment 88

[tor]

Attachment: update to tip

Comment 89

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This should go in IMO, default pref'd off for now.

Comment 90

[John Edgar]

Had this made it into a nightly yet?

Comment 91

[tor]

(In reply to comment #90)
> Had this made it into a nightly yet?

No, we still need code to get the output device color profile from OS-X, and need to work out how best to integrate lcms into the mozilla source tree.

Comment 92

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

lcms -> modules/lcms

Just leave it disabled on the mac/have it return an error or initialization.  That can be done as a separate step.  It'll involve (I think) calling CMGetDeviceProfile, and then looking at the location of the device profile that's returned.  I think that it'll virtually always be a cmFileBasedProfile, from my glance at the ColorSync docs.

Comment 93

[tor]

Attachment: default to off, add os-x display profile fetch

Comment 94

[tor]

Attachment: incorporate lcms-1.17beta into mozilla tree

Builds fine on linux and os-x, fails on win32 due to .dll/.lib confusion in modules/lcms/src.  If anyone is familiar with the win32 peculiarities of the mozilla build system, please take a look.

Comment 95

[tor]

Attachment: version that will also build on win32

bsmedberg, could you look over the build parts of this and tell me what horrors I've done?

Comment 96

[Stuart Parmenter]

Comment on attachment 272518 [details] [diff] [review]
version that will also build on win32

rather than putting all the ifdefs in gfxPlatform.cpp can you move GetPlatformCMSOutputProfile in to each subclass?

aside from that, the rest of this looks good.

Comment 97

[Benjamin Smedberg]

Comment on attachment 272518 [details] [diff] [review]
version that will also build on win32

>Index: configure.in

>+    if test "$OS_ARCH" = "WINNT"; then
>+        LCMS_CFLAGS=-DLCMS_DLL

I don't think this is right in the case where we're building libxul or static: in those cases, lcms will be a static library.

>Index: modules/lcms/Makefile.in

>+# The Original Code is __________________________________________.
>+#
>+# The Initial Developer of the Original Code is
>+# ____________________________________________.
>+# Portions created by the Initial Developer are Copyright (C) 2___
>+# the Initial Developer. All Rights Reserved.
>+#
>+# Contributor(s):

You'll fix all this up before checkin, right? ditto for include/Makefile.in and src/Makefile.in

>Index: modules/lcms/src/Makefile.in

>+GRE_MODULE	= 1
>+LIBXUL_LIBRARY = 1
>+DIST_INSTALL = 1

You'll need to include LCMS_LIBS in static-config.mk, in order to link this in properly in a static build.

>+ifndef MOZ_ENABLE_LIBXUL

This should probably be
ifneq (,$(MOZ_ENABLE_LIBXUL)$(BUILD_STATIC_LIBS))

>+ifeq (,$(filter-out WINNT WINCE,$(OS_ARCH)))
>+ifndef GNU_CC
>+MAPFILE	= $(LIBRARY_NAME).map
>+DEFFILE	= $(win_srcdir)/lcms.def
>+endif
>+endif
>+endif
>+
>+ifeq (,$(filter-out WINNT WINCE OS2,$(OS_ARCH)))
>+DEFINES	+= -DLCMS_DLL=1 -DLCMS_DLL_BUILD=1
>+else
>+VISIBILITY_FLAGS =
>+endif

I think you want this block to be wrapped in the MOZ_ENABLE_LIBXUL check above.

>Index: modules/libpr0n/decoders/png/Makefile.in

>            $(ZLIB_REQUIRES) \
>+	   $(LCMS_REQUIRES) \
>            $(NULL)

spacing nit

And of course I only reviewed the build-config changes, not the actual code.

Comment 98

[tor]

Attachment: patch incorporating pavlov and bsmedberg comments

Comment 99

[Stuart Parmenter]

Comment on attachment 273012 [details] [diff] [review]
patch incorporating pavlov and bsmedberg comments

sr=on the gfx/imagelib changes. look good.

Comment 100

[Stuart Parmenter]

checked in.

Comment 101

[Takanori MATSUURA]

I suppose icc34.h should also be added to config/system-headers.

This seems be required i building firefox-trunk on x86_64 Fedora 7.

Comment 102

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That depends when lcms is supposed to be linked to across shared libraries.  Right now modules/lcms/src/Makefile.in sets VISIBILITY_FLAGS to the empty string.  Whether that's the right thing to do depends on who is linking to it.

If it is intended to be used from various parts of the code, perhaps a good in-tree analogy is cairo.  We wrap the cairo headers if we're doing a non-libxul build.

Comment 103

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Matsuura-san:  were you seeing problems when using --enable-system-lcms or no?

Comment 104

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: possible fix for wrapping system headers

Possible fix for wrapping headers.  I think this patch is what we should be doing for now, since we seem to be linking the in-tree lcms statically into every library that uses it (which doesn't seem like the best of ideas).

In the future, I think we should probably:
 * hook into lcms's export defines and remove the VISIBILITY_FLAGS=
 * make lcms a shared library in a non-libxul build so we don't put it in twice

Comment 105

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ah, without it, I see:

/usr/bin/ld: gfxContext.o: relocation R_X86_64_PC32 against `cmsDoTransform' can
 not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
gmake[6]: *** [libthebes.so] Error 1


And now that I've done a build, I see libmozlcms is a shared library, and I also see that my patch doesn't work (without --enable-system-lcms).

Comment 106

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: possible fix for wrapping system headers (landed pending review)

Comment 107

[Prasad Sunkari [:prasad]]

Thunderbird build fails when compiling libthebes.so on GNU/Linux with the following errors:

gfxContext.o: In function `gfxContext::SetColor(gfxRGBA const&)':
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxContext.cpp:617: undefined reference to `cmsDoTransform'
gfxPlatform.o: In function `gfxPlatform::GetCMSOutputProfile()':
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatform.cpp:339: undefined reference to `cmsErrorAction'
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatform.cpp:349: undefined reference to `cmsOpenProfileFromFile'
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatform.cpp:365: undefined reference to `cmsCreate_sRGBProfile'
gfxPlatform.o: In function `gfxPlatform::GetCMSRGBATransform()':
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatform.cpp:397: undefined reference to `cmsCreate_sRGBProfile'
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatform.cpp:404: undefined reference to `cmsCreateTransform'
gfxPlatform.o: In function `gfxPlatform::GetCMSRGBTransform()':
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatform.cpp:378: undefined reference to `cmsCreate_sRGBProfile'
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatform.cpp:385: undefined reference to `cmsCreateTransform'
gfxPlatformGtk.o: In function `gfxPlatformGtk::GetPlatformCMSOutputProfile()':
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatformGtk.cpp:401: undefined reference to `cmsOpenProfileFromMem'
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatformGtk.cpp:474: undefined reference to `cmsBuildGamma'
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatformGtk.cpp:480: undefined reference to `cmsCreateRGBProfile'
/home/tux/mozilla/mozilla/gfx/thebes/src/gfxPlatformGtk.cpp:482: undefined reference to `cmsFreeGamma'

Did not go through the patch, but it could be due to this

Comment 108

[Martijn Wargers (dead)]

I'm also getting a build error in my mingw firefox build now:
g++.exe: ../../../dist/lib/mozlcms.lib: No such file or directory
I've filed bug 389392 for it.

Comment 109

[Jesse Ruderman]

This increased code size by almost 1% :(

(The other 8% increase on the day this landed was from NSS, see bug 389343.)

Comment 110

[Glenn Randers-Pehrson]

The latest available nightly for Windows (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007080305 Minefield/3.0a7pre) does not accomplish color management according to http://www.libpng.com/pub/png/png-colortest.html

Comment 111

[Benjamin Smedberg]

Glenn, because color management is off by default, you would have to turn gfx.color_management.enabled on in about:config and restart the browser to enable. That page looks correct on Minefield trunk to me with correction enabled.

Comment 112

[Glenn Randers-Pehrson]

Thanks.  WFM on Windows with gfx.color_management.enabled == true.  Is there a plan to make this the default setting eventually?

Comment 113

[Chris Murphy]

Is the plan to have color management apply only to images that are explicitly tagged, or if the implementation will assume sRGB for *all* untagged content (flash, SVG, gif, JPEG, movies, literally everything) and put it through a fast lookup to the currently set system profile?

Comment 114

[Stuart Parmenter]

The current implementation assumes sRGB on everything (excluding plugins -- which we don't touch) that isn't tagged and transforms those colors to the monitor profile.

Comment 115

[Jeffrey Friedl]

(In reply to comment #114)
> The current implementation assumes sRGB on everything that isn't tagged
> and transforms those colors to the monitor profile.

I'm not sure exactly what "tagged" means in this case... does the code recognize the InteroperabilityIndex EXIF field (if it's present and there's no embedded color profile)? I would recommend so, because that's how modern digital cameras indicate the color space for AdobeRGB images directly out of the camera. (See here: http://regex.info/blog/photo-tech/color-spaces-page7/#Suggestions4 ).

Safari does color management only for images with a color profile actually embedded. They didn't want to do management for unprofiled images because they don't do management for CSS and flash colors, and during a beta when they did do management for non-profiled images, web designers complained loudly that their CSS/flash colors didn't match their image colors (such as images used to create the look and feel of a page, like buttons, mastheads, etc).

That's a real concern that must be considered, but a much better approach, I think, that balances all these issues is to provide color management for images that have a color space indicated in any way (either with a profile, or via reference in the metadata). What Safari missed is to provide color management for images whose EXIF data indicates "I'm sRGB" or "I'm AdobeRGB" (the only two color spaces that the standards allow to be indicated this way). This "by reference" indication of the color space is how digital cameras indicate the color space. Most are sRGB, but some can be set to AdobeRGB. I don't know of any modern digital camera that actually embeds a color profile into the JPGs it produces.

This suggestion allows for images right out of the camera to be properly color managed, as one would generally want for a photographic image. It also allows web designers to get their CSS-matching colors simply by not including a color-space indication in the image, which they generally don't do anyway (since they strip out any metadata that might have been there to make the image smaller).

Not only does this scheme allow the web designer to explicitly control whether color management is done on an image, it just magically works for the vast bulk of what's already out there now, both in terms of photographic images that one wants to be color managed, and the web-designer stuff that shouldn't be.

One addition to this scheme that I'd offer for consideration is to let the user decide what should be done to images that have no color space indicated at all. Allow them to leave them unmanaged (and have that be the default), or interpreted in the color space of their choice. (Only sRGB would make any sense for the general population, but it seems reasonable to let the user pick from among any color space installed on their system.)

Comment 116

[Chris Murphy]

Question on plug-ins. To what degree do plugins (in general, and Flash/Shockwave specifically) have "direct" screen access (sends the result directly to the OS? Or do the plugins render and return the result to the application which then forwards that to the OS?

If the application receives the result from the plugin, then the application should be able to tag that data before it goes to the OS. If not, then this is arguably something that requires the plugin developers to know they need to explicitly set a source space when handing off color to the OS, or as another poster mentions there will be a disconnect between some content, preventing matching. And yes designers will give birth to a baby bovine if that happens.

Comment 117

[Chris Murphy]

I agree that EXIF data should be honored. But even Adobe and Apple do this poorly. Adobe does it inconsistently (I can think of only Photoshop that honors this metadata), and Apple's image capture API not only ignores it when importing images but it explicitly embeds an ICC profile defined with Generic RGB primaries with a tone response curve defined with gamma 2.2. Extremely inappropriate.

As for designers and end users, there should be no option for them to opt-in or opt-out of color management. This is the year 2007, not 1997 when IE for Mac had the option of using ColorSync, which was doing most all of this correctly back then including assuming sRGB for untagged images. (Shocking really, seeing as even the latest version of IE in Vista still does not even have this as an option). 

The idea of having a check box is a bad idea because you then would have to create an architecture that passes this setting onto all plugins that are responsible for rendering any kind of onscreen result so they can either color manage or not color manage their content. The situation is already confusing enough for most developers and end users, I think it's asking for astronomically more complex coding and documentation for this to be an option.

Comment 118

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

To summarize, and assuming that the color management pref is enabled:

- every image is converted to the monitor profile
  - if an image has a profile embedded, it is used
  - if it does not, sRGB is assumed
  - I'm not sure what we do if there's no profile but InteroperabilityIndex is present (tor?) -- I don't think we recognize that; it shouldn't be a hard patch to add.
- every CSS color (that is, anything that's rendered via HTML/XML/etc.) is assumed to be sRGB and converted to the monitor profile
- anything rendered by plugins is NOT converted; plugins do their own rendering direct to the OS, and we have no control over what colors they use.  The plugin API does not provide any way for color profile information to be passed, so this isn't something that's fixable in the near future.

I don't think there is (right now) a way for the user to control what profile is applied to untagged images.

With color management on, the only times you might have color mismatches would be:

1. trying to match CSS colors or any images with plugin content
2. trying to match CSS colors with images that are tagged as anything other than sRGB

#2 is something that might affect the web today, but is something that authors can control (without breaking compatability with other browsers).

#1 is the only thing that authors cannot control -- however, I've yet to see cases where CSS colors need to match directly with plugin colors.  Usually there is some border, or a gradient, or something at the border of the plugin; or the plugin is drawn windowless and is drawn with alpha transparency on top of other content.  So I don't think this will be that big of a deal in practice (and indeed, hopefully it will encourage authors to avoid plugins unless absolutely necessary!)

Comment 119

[Chris Murphy]

Adding a preference for color management vastly increases the complexity to end-users, and inherently will cause disconnects between the experiences people have from work station to work station. This is a huge reason why color management has the negative connotation it has had over the past decade. Things should simply work correctly. Why have a "wrong color" option and turn it on by default?

Also, there is currently one logical source to assume for untagged images and that's sRGB. That may one day change, but there are simply no naturally occurring images in other spaces like Adobe RGB 1998. So why allow the end user to create an even bigger disconnect by choosing such a space? If the content creator doesn't like sRGB, then the content needs to be tagged with something other than sRGB.

Comment 120

[Jeffrey Friedl]

> 1. trying to match CSS colors or any images with plugin content
> than sRGB
-  
> #1 is the only thing that authors cannot control -- however, I've yet to see
> cases where CSS colors need to match directly with plugin colors. 

The case that Safari engineers cited was flash, where the web designer wanted the flash background to match the surrounding CSS background. Personally, I eschew flash, but one can't deny its popularity among web designers (who often tend to have more artistic sense than technical sense, although the web is filled with the work of those who have nither :-)

About the option for the default colorspace, I'll retract the recommendation. For reasons that I can't seem to come up with now, it seemed like a good idea at the time. /-:

About recognizing "tagged" images (images with the color space noted only by reference in the Exif data), Adobe Lightroom does it properly. I'd really expect any serious image-processing software built in the last few years to do it as well, since the standards were amended to allow more than just sRGB in 2003. One of the big problems is that the OS makers apparently don't consider their OS and browsers "serious image-processing software."  At least Apple tries, unlike our friends in Redmond.

Comment 121

[Simon Fraser [no longer active]]

Have you considered using a <meta> tag, or new CSS property to control whether color correction is enabled for images and/or CSS? I think turning color matching on for CSS by default is going to lead to lots of unhappy web developers.

Comment 122

[tor]

(In reply to comment #118)
>   - I'm not sure what we do if there's no profile but InteroperabilityIndex is
> present (tor?) -- I don't think we recognize that; it shouldn't be a hard patch
> to add.

Adding support for JPEG EXIF tagging of colorspace should be fairly straightforward, though we need Mozilla legal to look over the license for bundling the AdobeRGB profile with mozilla:

  http://www.adobe.com/digitalimag/adobergb.html

Comment 123

[Jeffrey Friedl]

(In reply to comment #121)
> I think turning color matching on for CSS by default is going to
> lead to lots of unhappy web developers. 

This is generally an issue only for images with no indication of the color space (that is, without an embedded profile, without an EXIF ColorSpace field indicating sRGB, and without an EXIF InteroperabilityIndex field indicating either sRGB or AdobeRGB). I would think that if an image indicates a specific color space, it should always be honored.

On the other hand, an option to enable/disable sRGB interpretation for images of unknown color space makes a lot of sense. If there's a way to do it on a per-page or per-image basis (via css/html) that's all the better.

(In reply to comment #122)
> though we need Mozilla legal to look over the license for
> bundling the AdobeRGB profile with mozilla

Adobe has copyright on the actual bundle of bytes that they supply as a profile. They'll let you use it as referenced in the link, but one can always build their own profile using the same data. (As the last sentence on the page says, you just can't refer to it as "Adobe RGB (1998)"; using "AdobeRGB" should be fine.)

Of course, I'm not a lawyer blah blah blah, so do have one check....

Comment 124

[tor]

(In reply to comment #123)
> Adobe has copyright on the actual bundle of bytes that they supply as a
> profile. They'll let you use it as referenced in the link, but one can always
> build their own profile using the same data. (As the last sentence on the page
> says, you just can't refer to it as "Adobe RGB (1998)"; using "AdobeRGB" should
> be fine.)

If you followed the link provided, you would have seen that Adobe has a color profile bundling license agreement.

Comment 125

[Jeffrey Friedl]

(In reply to comment #124)
> If you followed the link provided, you would have seen that Adobe has a color
> profile bundling license agreement.

Yes, that's why I noted that "they'll let you use it as referenced in the link,"
and made other references to the link you so kindly provided. I was merely intending to say that while it's up to the lawyers whether the license agreement is appropriate for Mozilla, you can get around the whole issue by building your own identical profile and calling it something other than "Adobe RGB (1998)", such as "AdobeRGB".

Comment 126

[tor]

(In reply to comment #125)
> (In reply to comment #124)
> > If you followed the link provided, you would have seen that Adobe has a color
> > profile bundling license agreement.
> 
> Yes, that's why I noted that "they'll let you use it as referenced in the
> link,"
> and made other references to the link you so kindly provided.

Ah, sorry - thought you meant they'd just let you use it by reference.

Comment 127

[Chris Murphy]

>Simon Fraser   2007-08-08 08:54:41 PDT
>Have you considered using a <meta> tag, or new CSS property to control whether
>color correction is enabled for images and/or CSS? I think turning color
>matching on for CSS by default is going to lead to lots of unhappy web
>developers.

No, you're not understanding. You cannot make this behavior optional or you're going to make this explosively complex and impossible for people to get consistent results from machine to machine, platform to platform, or match content from plug-ins.

I cannot stress enough how huge of a mistake it is to put in an option in the UI to turn color  management on and off. It is also a big mistake for this behavior to be off by default.

I suggest, very, very strongly, that you either have color management on for all content (assuming sRGB for untagged images), by default, with no UI option for any other behavior. Or you abandon this entire venture.

What will piss people off beyond belief will be radically different behavior depending on whether the user has opted in or not. The preservation of proper color appearance of content is not, and should not be user domain. It's absurd to give them a choice for this.

Comment 128

[Simon Fraser [no longer active]]

I'm not suggesting a user option. I'm suggesting an option for the content author to opt in, or out, of the new color management. I'm guessing they'll be pissed off that their colors look different in FF compared to IE in a way that they can't control.

Comment 129

[Chris Murphy]

Oh OK, gotcha. Sorry. 

It sounds like a good idea in theory, but in practice I think it will be seen as a tag to "fix" a "problem". Anyone who takes issue with color management occurring will see it at face value as the application making a mistake.

There are many aspects of FF that differ from IE in terms of rendering, and really this is no different.

A legitimate complaint by the content author will be the disconnect between non color managed flash vs color managed images + css content *IF* plugins don't start doing the right thing. Currently they're doing the wrong thing, and this should be clearly understood by content creators. The solution is to fix the plugins, not allow them to screw up images and CSS content in order to match screwed up plugin color.

Comment 130

[Colin Barrett [:cbarrett]]

There are a number of places where we use the Device color space on Mac OS X ( http://mxr.mozilla.org/seamonkey/search?string=devicergb ). Should these all be changed to using a calibrated color space? (Basically, s/DeviceRGB/CalibratedRGB/).

Comment 131

[James Justin Harrell]

This issue recently got a lot of attention on Digg. It's currently at the top of the front page's top 10 list.
http://digg.com/apple/Firefox_Camino_vs_Safari_Image_Quality_Big_difference_IMAGE

Comment 132

[MechCommanderRei]

Attachment: Colors "double-corrected" when copy-pasted from Fx to Gimp

I'm not sure what component to report this bug for, but it relates to color management and the clipboard: It seems that Firefox's Copy Image function is sending the adjusted color values to the clipboard, rather than the original values.

To illustrate, take the Gimp (which supports color management) and Irfanview (which does not).  If you copy an image from Irfanview and paste it into the Gimp, the colors brighten.  Conversely, if you copy from Gimp and paste into Irfanview, the colors darken.  But if you use Print Screen on the Gimp window and paste into Irfanview, the colors aren't darkened. (I'm on Windows XP.)

With Firefox (3.0 Beta 1 with color management enabled), copy-pasting an image into Irfanview does not show color darkening.  And copy-pasting from Firefox to Gimp leads to "double-brightened" colors. (See attachment)

Comment 133

[Glenn Randers-Pehrson]

(In reply to comment #132)
Perhaps this should have been a new bug.  Anyhow, does the original image (that Firefox was reading) have a color profile or other color information?  Please upload or point to a copy.

Comment 134

[MechCommanderRei]

Attachment: Image for testing color double-correction

(In reply to comment #133)
AFAICT the bug works with any image, including the "comparison" one I uploaded in the previous comment.  But I'll attach a second image for testing, this time a png.  The effect seems most noticeable with blues.

I don't think there's an embedded color profile, since I've seen the Gimp pop up a message if it detects one, and it doesn't for these images.

Comment 135

[MechCommanderRei]

(In reply to comment #134)
Whoops, actually the second image is a jpg too, not a png.  My mistake.

But it does show off the bug well.

1. Open in Firefox.
2. Save image.
3. Open in Gimp.
4. Copy from Firefox, paste into Gimp.

Comment 136

[Glenn Randers-Pehrson]

Your first image does not contain color info.  The second one has the sRGB profile, as you can see by running ImageMagick's "identify -verbose *.jpg",
and "convert Bleach_rukia_DFC.jpg Bleach_rukia_DFC.icm" and then examining
Bleach_rukia_DFC.icm with a byte viewer like "od -c" (there are other ways
to extract the color profile and examine it).  Firefox shouldn't be
changing either one, because its default display on Windows is also sRGB.
Have you set up your GIMP to use some other default colorspace?

Comment 137

[MechCommanderRei]

(In reply to comment #136)
>Have you set up your GIMP to use some other default colorspace?

Not that I know of... I have the Color Management preferences set to 2.4.0's default settings (though I've since upgraded the program to 2.4.2).  The settings are:

Mode of operation: Color managed display
RGB profile: None
CMYK profile: None
Monitor profile: None
Try to use system monitor profile: Checked
Display rendering intent: Perceptual
Print simulation profile: None
Softproof rendering intent: Perceptual
Mark out of gamut colors: Unchecked
File open behaviour: Ask what to do

With Firefox, I'm using 3.0 Beta 1, with gfx.color_management.enabled set to "true".

Comment 138

[Chris Murphy]

(In reply to comment #136)
> Firefox shouldn't be
> changing either one, because its default display on Windows is also sRGB.

I find this statement potentially confusing, because it implies perhaps that on Mac OS Firefox is not defaulting to sRGB for tagged images.

sRGB needs to be assumed as source for untagged content regardless of platform.

Comment 139

[Chris Murphy]

(In reply to comment #130)
> There are a number of places where we use the Device color space on Mac OS X (
> http://mxr.mozilla.org/seamonkey/search?string=devicergb ). Should these all be
> changed to using a calibrated color space? (Basically,
> s/DeviceRGB/CalibratedRGB/).

/deviceRGB shouldn't be used, everything should have an explicit profile, either from the object having been tagged, or if untagged the object is assumed to be sRGB.

And in order for things to print correctly, all of these honored source profiles (or assumed sRGB source profile) need to be handed off to the OS at print time. So /deviceRGB doesn't apply for printing either.

Comment 140

[Jeffrey Friedl]

(In reply to comment #136)
> Firefox shouldn't be
> changing either one, because its default display on Windows is also sRGB.

I'm not sure exactly what you mean when you say "default display on Windows is sRGB", but if you mean that the Windows graphics subsystem expects to be given sRGB and that it then does the appropriate modifications to the user's specific display device, I'm fairly sure that's incorrect. It's my understanding that Windows does not do any color management. Viewing an sRGB image with a "dumb" application (that is, not explicitly color managed) like Preview, IE, Firefox 2.x, etc., shows incorrect colors in proportion to how different the display device's profile is from sRGB.  Even with sRGB on Windows, you still need a color-managed app like Photoshop or Safari to see proper colors.

But like I said, I might be misunderstanding what you intended to say. If you intended to say "Firefox on Windows should assume sRGB for all images that have no colorspace indication", I agree completely (although I echo Chris Murphy's sentiments that such an assumption should cover all OSs, not just Windows).

Comment 141

[Chris Murphy]

(In reply to comment #140)

> if you mean that the Windows graphics subsystem expects to be given
> sRGB and that it then does the appropriate modifications to the user's specific
> display device, I'm fairly sure that's incorrect.

It is correct for printing (sRGB is to be assumed by the driver proprietary color management used by default, and is expressly assumed for untagged data if ICM is selected).

It is not correct for display. Untagged content is /deviceRGB on Windows including I *think* even Vista.


>Viewing an sRGB image with a "dumb"
> application (that is, not explicitly color managed) like Preview, IE, Firefox
> 2.x, etc., shows incorrect colors in proportion to how different the display
> device's profile is from sRGB.  Even with sRGB on Windows, you still need a
> color-managed app like Photoshop or Safari to see proper colors.

Correct.

Comment 142

[Chris Murphy]

General question & suggestion:

1. FF3 betas I've used thus far have gfx.color_management.enabled = false by default. Will it be true by default with shipping product?

2. Related to 1, my recent understanding is the Safari development team is suggesting that they are holding off on fully color managing untagged content (images, CSS, text, etc. assumed to be sRGB source) until Flash gets color managed.

My comment/suggestion is that if FF3 won't ship with color management enabled by default, that having a version of Safari and Firefox released at about the same time that have full color management enabled would be a great cover for both web browsers to do the exact right thing. I think it would encourage Apple to not wait until Flash gets its act together. The waiting game has not thus far managed to motivate Flash development in this respect at all. I think it's time to just do the right thing and Flash can play catch up or not.

Comment 143

[Glenn Randers-Pehrson]

The sRGB specification says that untagged images are supposed to be assumed to be sRGB.  That seems to be overreaching, but there you have it.  Curiously, the official sRGB spec has disappeared from www.color.org, and sRGB isn't even mentioned there, but W3C still has a copy:

    http://www.w3.org/Graphics/Color/sRGB

Note the sections near the end entitled "Standard Color Space in Practice" and "Browsing scenarios".

Some of us (PNG group) disagreed with that when the sRGB spec was being developed and felt that untagged images should default to "unknown" or "native colorspace" rather than "sRGB".  The PNG spec says "When the incoming image has an unknown gamma, choose a likely default gamma but allow the user to select a new one if the image proves too dark or too light".

But you are right, I should not have said "because its default display on Windows is also sRGB."

Comment 144

[Chris Murphy]

Option A: If we treat untagged images as "native colorspace" we end up with images that have a huge range of color appearances especially moving forward in time as display technologies diverge, rather than converge on a common color space. This is simply messy, and in practice does not encourage stamping out untagged RGB off the face of the planet. "native color space" is an assumption also, and doing so gives you a range of appearances, thus no consistency.

Option B: Untagged RGB = sRGB is perhaps not ideal, but it is at least a consistent way to treat such data, because something is going to be assumed. It also saves us from having to embed redundant data in billions of images on the internet, and having to push that through our networks and store that redundant data. So untagged RGB is very reasonable as long as we agree on what it should be.

I'd entertain a conversation elsewhere on a space other than sRGB being used, but I think at this point sRGB is reasonable, and the market has essentially decided this. So I'm OK with it.

The problem I have with the CSS2 spec is the notion that display compensation only needs to occur on Mac OS, and I think Solaris, and that Linux and Windows are exempt. Those operating systems can have non-sRGB displays connected to them to and thus have the same problem as every other platform if content is not fully color managed. So that part of the spec is just plain wrong and I suspect it's because it's antiquated, focusing on the TRC differences between the two platforms rather than dealing with the real issue which is that displays are increasingly not described by sRGB.

Comment 145

[Jeffrey Friedl]

(In reply to comment #144)

One consideration for the "what colorspace to assume for untagged images" is that the vast majority of images these days -- from common consumer point-n-shoots and cell-phone cameras -- are sRGB, and usually remain so even if their metadata is stripped.  I'd strongly guess that a guess of sRGB for an image with an unknown colorspace would have a very high success rate, one that would only increase over time.

By the way, just to make sure, does Firefox recognize the Exif "ColorSpace" and "InteroperabilityIndex" tags? It's through those simple notational tags, and not an attached color profile, that all modern digital cameras (that I know of) indicate an image's color space. Last time I checked, Safari did NOT recognize these tags, which meant that straight-from-the-camera images would never look right. What a shame. 

The standards allow for only two color spaces that can be indicated with these tags -- sRGB and AdobeRGB -- so it's a simple matter of including those color profiles in the code and referring to them when the tags indicate so.

Comment 146

[Stuart Parmenter]

this was checked in a long time ago.

Comment 147

[Colin Barrett [:cbarrett]]

Cases like bug 403169 will crop up if we assume that all colors are sRGB. Frankly, when it comes down to it, when you are making a theme for Firefox, you are usually working with colors in the monitor color space (comparing against other apps on the system).

Perhaps Chrome & Content should have different base profiles?

Comment 148

[Jacob Rus]

In my opinion, untagged images should definitely be assumed to be sRGB, if only because the W3C specifications require that untagged CSS/HTML/SVG colors be interpreted as sRGB (and browsers should actually do this properly, particularly on the Mac where display gamma differs dramatically from sRGB), and untagged images should ideally match with untagged CSS colors on web pages.

As for chrome (comment #147), it should certainly not (for the moment) be assumed to be sRGB, as no existing platform color manages any of its chrome, and browsers should fit in with the rest of the system.

Comment 149

[Chris Murphy]

Regarding the rendering intent to use from source (assumed sRGB or explicitly tagged) to destination (display profile):

Ideally we would use Relative colorimetric + black point compensation. In the case of most display profiles, which are not built correctly, RelCol alone will suffice which is the majority instance. However, correctly built custom display profiles contain actual black point information in them, describing the display as having a dynamic range less than that of the source color space. Therefore RelCol alone will cause shadow detail clipping, whereas RelCol+BPC will cause dynamic range compression to the display to preserve shadow detail.

Again, just an FYI. I've heard there is an API for BPC in ColorSync. I do not know if there is one for ICM. I think there is, but not certain there is one for lcms.

Currently I do see a difference between images displayed in FF3b with color management on, compared to say Photoshop.

Are CMYK images supported by web browsers? Should they be? If so the discrepancy is even greater there between BPC on or off.

Comment 150

[Colin Barrett [:cbarrett]]

(In reply to comment #149)
> Currently I do see a difference between images displayed in FF3b with color
> management on, compared to say Photoshop.

David Baron and I were talking about this and he theorized that the cms stuff was doing gamma correction. On mac at least, this would cause everything to look quite a bit darker.

Is that the case?

Comment 151

[tor]

(In reply to comment #150)
> (In reply to comment #149)
> > Currently I do see a difference between images displayed in FF3b with color
> > management on, compared to say Photoshop.
> 
> David Baron and I were talking about this and he theorized that the cms stuff
> was doing gamma correction. On mac at least, this would cause everything to
> look quite a bit darker.

Correction for the output device gamma is part of the color correction, yes.

Comment 152

[tor]

(In reply to comment #149)
> Regarding the rendering intent to use from source (assumed sRGB or explicitly
> tagged) to destination (display profile):
> 
> Ideally we would use Relative colorimetric + black point compensation. In the
> case of most display profiles, which are not built correctly, RelCol alone will
> suffice which is the majority instance. However, correctly built custom display
> profiles contain actual black point information in them, describing the display
> as having a dynamic range less than that of the source color space. Therefore
> RelCol alone will cause shadow detail clipping, whereas RelCol+BPC will cause
> dynamic range compression to the display to preserve shadow detail.
> 
> Again, just an FYI. I've heard there is an API for BPC in ColorSync. I do not
> know if there is one for ICM. I think there is, but not certain there is one
> for lcms.
> 
> Currently I do see a difference between images displayed in FF3b with color
> management on, compared to say Photoshop.

Keep in mind that those of us implementing color correction in Firefox are not experts in the area, so you might need to dumb stuff down for us.

Unless an image includes a profile with a particular intent, we correct with a perceptual intent.  I'm not sure what Photoshop uses by default, but if it is RelCol+BPC that would probably be the difference for untagged images.

Regarding BPC, from what I read it appears to be a whole-image correction that changes the mapping based on what gamut the image uses.  If so, this isn't desirable for the web environment where we want to display the images as they stream in, and have separate images that use the same colors match after correction.

> Are CMYK images supported by web browsers? Should they be? If so the
> discrepancy is even greater there between BPC on or off.

We support CMYK when color correction is enabled.

Comment 153

[Colin Barrett [:cbarrett]]

(In reply to comment #151)
> (In reply to comment #150)
> > (In reply to comment #149)
> > > Currently I do see a difference between images displayed in FF3b with color
> > > management on, compared to say Photoshop.
> > 
> > David Baron and I were talking about this and he theorized that the cms stuff
> > was doing gamma correction. On mac at least, this would cause everything to
> > look quite a bit darker.
> 
> Correction for the output device gamma is part of the color correction, yes.

Didn't we end up not doing gamma correction in bug 53597 because people complained that it made things darker and they didn't like it and what did you do to my browser you evil developers how dare you, and so on?

Comment 154

[tor]

(In reply to comment #153)
> Didn't we end up not doing gamma correction in bug 53597 because people
> complained that it made things darker and they didn't like it and what did you
> do to my browser you evil developers how dare you, and so on?

Back then we hardcoded the gamma value to the traditional mac value, which was not always appropriate.  This time around we're doing our best to find the appropriate profile of the monitor.

Comment 155

[Chris Murphy]

OK I'm going to be a color geek, so forgive the following A.R. commentary :-)

a.) Color management always compensates for tone reproduction curve of the display, so this is something FF3b is doing when color management is enabled and something that Photoshop always does. 

b.) So the discrepancy between them is surely the fact that Photoshop does RelCol + BPC to the display (and that I happen to have a custom profile that says display black is L*=4 rather than L*=0 like most profiles including simple matrix+TRC profiles), and FF3b is using just RelCol to the display. I'll address this in a separate post.

c.) output device = printer or press.

d.) Nitpicky but what we're compensating for is tone reproduction curve, not gamma. A display's tone reproduction curve could be defined with a gamma function or points on a curve or a parametric function, etc. So a display doesn't have a gamma. It has a tone response or tone reproduction curve.

e.) Regardless of a display's TRC, the display profile contains the information about the display's TRC so that it can be compensated for by a cms. So a properly configured system A with TRC defined with gamma 1.8 will display images exactly the same as system B with TRC defined with gamma 2.2 (assuming all other things are the same).

Comment 156

[Chris Murphy]

(In reply to comment #152)
> Unless an image includes a profile with a particular intent, we correct with a
> perceptual intent.  I'm not sure what Photoshop uses by default, but if it is
> RelCol+BPC that would probably be the difference for untagged images.

Photoshop uses RelCol+BPC by default for both RGB and CMYK images. The difference between RelCol and Relcol+BPC is, I admit somewhat minor for the particular display profiles I'm referring to which most people do not have. However those who have correctly built display profiles are LIKELY hardcore Photoshop users. And they are likely the ones to wonder why the web browser still doesn't match their images in Photoshop.

> Regarding BPC, from what I read it appears to be a whole-image correction that
> changes the mapping based on what gamut the image uses.

It is a dynamic range compression/expansion function. If source dynamic range is greater than destination, then it slightly lightens the image to make room for shadow detail to be displayed, instead of clipped which is what Relcol would do.

The consequence of not doing relcol+bpc across the board for all images is that there will be a discrepancy *on the same machine* between browser and Photoshop. It will be far less than the discrepancy we have now with FireFox 2 and other web browsers that don't do color management at all.

I would characterize this as a minor difference. But those who have correctly built display profiles are likely Photoshop users and will likely notice the remaining discrepancy. But given the improvement over FF2 and other web browsers, it's probably a minor issue.

(As as aside, it is not going to remain a minor issue for long because we need different rendering intents entirely in contexts such as smaller gamut displays, wider gamut displays, high dynamic range displays and high dynamic range images. How are we going to get non-HDR images to display correctly on HDR displays? AbsCol. What about HDR images on non-HDR displays? That's an ICC v4 perceptual intent and image state rendering issue. Just pointing out one size fits all kinda sorta can work now, but won't for long.)


>  If so, this isn't
> desirable for the web environment where we want to display the images as they
> stream in, and have separate images that use the same colors match after
> correction.

For images, it's desirable for them to *look* correct, not necessarily display accurately because you can't ensure they display accurately on all displays anyway. Difference displays have differences in dynamic range. The choice for handling shadow detail is clipping (RelCol) or compression (RelCol+BPC).

 
 
> We support CMYK when color correction is enabled.

Hmm, this is one of those instances were it's more complicated because CMYK dynamic range is *less* than that of the display dynamic range. By quite a bit. Black L* is around 15 out of 100 levels. And it has a completely different white point as well. So you really have three valid options: RelCol, RelCol+BPC, and AbsCol.

Again, default in Photoshop is RelCol+BPC. This stretches the dynamic range of the CMYK image to that of the display dynamic range. It makes black look black and ignores the fact CMYK paper white is yellower and darker than display white.

In order for the image to be viewed correctly on screen (as it will print) a soft proofing option needs to be manually turned on. In Adobe applications, turning off BPC to the display for CMYK images is actually called "Simulate Ink Black". You check that on, and the image to display goes from RelCol+BPC to RelCol. And if you check "Simulate Paper White" you're forced to also "Simulate Ink Black" - behind the scenes the Absolute Colorimetric intent is being employed to do this.

So if your argument is to show CMYK exactly correct as it would print on a CMYK device, the intent should be AbsCol. That would be accurate. But it won't look good.

And what of untagged CMYK? What is the assumed source profile going to be?

Are you sure you want to support CMYK? :-)

Comment 157

[Chris Murphy]

Commenting on my own post:
>>>Again, default in Photoshop is RelCol+BPC. This stretches the dynamic range of
the CMYK image to that of the display dynamic range. It makes black look black
and ignores the fact CMYK paper white is yellower and darker than display
white.<<<

1. makes black look black. Clarification: CMYK black is a lot lighter than display black. RelCol will cause CMYK black on-screen to appear light, as it would when printed. This will make the CMYK image look flat, lower in contrast on-screen. RelCol+BPC will remap CMYK black to that of the display. So you get a dynamic contrast boost and now the image looks better, even if it isn't going to print that way.

2. As for what source profile to use for untagged CMYK: most CMYK in the world is untagged. So to support untagged CMYK you'll need to assume something rational as the source profile. If you don't, something is assumed by the OS and I think on OS X that's Generic CMYK which is effectively SWOP - a specification for publications (magazine and ad printing, i.e. not the best quality, but many CMYK images are prepared this way). I do not know what is assumed on Windows or other platforms, it's possible they're going to be different.

Also, what is used for publication printing in the U.S. is not what's used in other countries. So no matter what the untagged CMYK situation is actually more up in the air than untagged RGB being assumed to be sRGB.

So the more I think about this, I wonder why support CMYK in a web browser? If anyone wants to simulate a CMYK image, they can do so by converting the CMYK image using AbsCol or RelCol to sRGB and put that up on a web site. If they want it more color accurate, convert to Adobe RGB (1998) and tag it. Either way it will be a.) smaller since it's 3 channels instead of 4, b.) vastly better supported by other web browsers.

Also for what it's worth. sRGB and Adobe RGB (1998) and ProPhoto RGB profiles, embedded in images, are going to increase file size maybe 2-4k. Embedding even an average CMYK profile is 350k and good ones are 3-4MB.

So I'm not convinced at this moment that supporting CMYK is necessary or a good idea. But I'm open to being convinced as it's entirely possible there's some need or scenario I'm not aware of.

Comment 158

[Craig Ringer]

CMYK support would be very valuable for some classes of user. In particular, people working with print media tend to receive a lot of CMYK JPEG images. While most of these come in by email (where CMYK support in the core would potentially help tbird handle them), the users also run into a fair few on the web, mostly from image download sites.

Why do those sites publish CMYK images? Beats me, since RGB with ColorMatch or Adobe RGB would be a much saner choice when targeting print media. They do, though, and it'd be a handy thing to support when it can be done at a low cost through the color management engine. 

If CMYK images end up not being supported, it'd be best if Firefox detected CMYK images and displayed an informative message about them rather than treating them as damaged images. If the image is loaded as a "page" rather than embedded in HTML, firefox should probably offer to save it to disk (as it does any other unhandled file type). In other words, "CMYK/other unsupported image" should be treated as a different file type to "RGB image" with regards to handlers, etc.

Comment 159

[Chris Murphy]

(In reply to comment #158)
> While most of these come in by email (where CMYK support in the core would
> potentially help tbird handle them), the users also run into a fair few on the
> web, mostly from image download sites.

OK yeah good point both for webmail and email incoporating a web content rendering engine.

So no matter what you can second guess the source for untagged CMYK so in a sense there is no right choice. It's not as obvious as what to do with untagged RGB (i.e. assume sRGB). It's kindof a regional thing.

That said, what you're trying to do is just display them with some kind of sanity. The browser is not a desktop publishing application. There are several standard characterization sets that would be rational choices to assume as source. I would choose SWOP2006_Coated3v2.icc for a number of compromising reasons.

1. It's based in one of the most common standard characterization sets on the planet.

2. It's been updated for a higher quality stock than the original characterization, so it's somewhere between the lower quality #5 groundwood stock and very high quality #1/#2 stock. The Coated3 refers to it being based on a #3 stock which is a very high quality publication stock, but lower quality than high-end commercial work.

3. CMYK images assumed to be in this space will look very similar to those in Photoshop with default settings, at least in North America. They will look similar to Photoshop in other countries, just not as close as the defaults in North America. (Photoshop has different CMYK defaults depending on region, one of three profiles are possible).

The 2nd option would be GRACoL2006_Coated1v2.icc

The 3rd option would be ISO12647-2, FOGRA39

As for rendering intent, again I'd recommend RelCol+BPC to match Photoshop as close as possible, even if it's not "accurate." But if you go with RelCol, you'll get questions about why the blacks look so much lighter than in Photoshop. But, at least the image will be displayed.

I do not know what the usage issues are with either the characterization data set itself, or the profiles that already exist for them from a few different sources. So if those making decisions about this need contacts to talk to about that, I can help out with it.

Comment 160

[Alvaro Munoz-Aycuens]

I was pondering to open a bug for asking to enable color managment by default, is there any reason why it isn't that I should be aware of?

Comment 161

[Ryan VanderMeulen [:RyanVM]]

Bug 437300 is what you want. Also see the below blog post:
http://www.dria.org/wordpress/archives/2008/04/29/633/