hhmm, which version of GIMP do you use? 

The one from gimp.org or the one from gimp.lisanet.de? As far as I remember I've patched my versions ( gimp.lisanet.de) in 2.8.2 or 2.8.4 and that should work well. And as far as I know, the gimp.org version should work well at least in 2.8.14

The same comment as in bug 739989:

GIMP does get the profile from the OS, that is not the problem. The same
color correction is happening twice, but we do need GIMP to convert from
the image's profile to something. Please try setting sRGB as display color
profile (disabling "from system"), this should cause GIMP to convert
from the image's colors to sRGB, and the system from sRGB to the motitor
profile.

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

I am putting this comment here because my report bug 739989 has been marked as resolved. You may, however, need to refer to that report in order to understand some parts of my comments. Note I am now talking about Gimp 2.8.14 and Mac OS but I could not find a way to change those fields.

I can now see three candidates for addressing this issue.

A. Michael Natterer's suggestion

If I have understood you correctly
1. In System Preferences > Displays > Color select the true monitor profile.
2. Set the Gimp colour management preferences as follows:
Monitor profile sRGB
"Try to use the system monitor profile" not checked.

This raises the question, how should these two colour management options be presented in the Mac OS version of Gimp?
i. Removed completely.
ii. Greyed-out so they cannot be changed.
iii. Padlocked so the user has to click on the padlock to change them. At this point a warning is presented.
iv. Marked that they should not normally be changed from "sRGB" and "unchecked."
v. No change from the current presentation.
vi. Other possibilities?

I have tried this and it gives the expected results in two of the scenarios considered in report bug 739989:
sRGB image -> sRGB monitor
sRGB image -> Adobe RGB monitor
It does not give the expected results in the other two scenarios:
Adobe RGB image -> Adobe RGB monitor
Expected (255, 0, 0), (0, 255, 0), (0, 0, 255)
Actual (219, 0, 0), (144, 255, 60), (0, 0, 250)
No colour management
Expected (255, 0, 0), (0, 255, 0), (0, 0, 255)
Actual - depends on the monitor profile set in System Preferences

In other words, when working with wide-gamut images and a wide-gamut monitor, there is a problem, because the images are going through an sRGB "bottleneck."

Depending on whether the presentation of the colour management options is changed, it would also be desirable or essential to make some additions to the documentation, explaining the settings required for Mac OS. I think it is unlikely that a user could guess or deduce the settings, without some additional information.

B. A new suggestion

1. In System Preferences > Displays > Color select sRGB.
2. Set the Gimp colour management preferences as follows:
Monitor profile - the true monitor profile
"Try to use the system monitor profile" not checked.

This gives the expected results in all four scenarios considered above.

Again, it would be essential to change the presentation of the colour management options or to make some additions to the documentation.

There is, however, a snag with this suggestion. The snag arises if the user has calibrated and profiled the monitor, and the profile includes curves to be loaded into the video card gamma table. With this suggestion, the curves will not be loaded - unless someone knows a means of
i. Extracting the data for the table from the relevant profile
ii. Loading this data into the video card
on Mac OS. (Argyll CMS does not do it on Mac OS.)
Alternatively, the sRGB profile could be modified by adding the data for the table, if suitable software can be identified to do this. (In Mac OS, the OS loads the curves into the video card as soon as the monitor profile is changed in System Preferences.)

C. The suggestion in report bug 739989

1. Gimp converts the image to the (true) monitor profile. I believe that this is the currently intended behaviour of Gimp; that this is what Gimp actually does; and that retaining this behaviour would keep the Mac OS version in line with the Windows and Unix/Linux versions.
2. Gimp tells the Mac OS that the image has already been converted to the monitor profile, when Gimp opens an image window.

I believe this would give the expected results in all four scenarios considered above.

No changes would be needed to the presentation of the colour management options or to the documentation.

We would clearly prefer C, but haven't investigated if there is API to tell
the system not to color manage a particular window or area.

I have investigated further and I now understand your hesitation over suggestion C. All of the following is my best guess: I have not investigated in sufficient detail to gain greater certainty.

I have no knowledge of the code of Gimp. But after a quick look, I see that Gimp calls the cairo API, and cairo calls the OS API. The problem is that cairo does not support color management. The intended behaviour of cairo is that it passes on the image data unchanged to the display.

From http://cairographics.org/manual/cairo-Quartz-Surfaces.html#cairo-quartz-surface-create:

"The surface is created using the Device RGB (or Device Gray, for A8) color space."

Up to OS X 10.7, Device RGB was, in effect, the monitor color space. From OS X 10.8, Device RGB is sRGB. The intended behaviour of cairo has been derailed by this change. So the 'clean' fix for the issue with Gimp would be for cairo to be modified to restore the intended behaviour following the change in OS X. What do you think is the likelihood of this being done in time for, say, the 2.8.16 release of Gimp? I think any request for a change to cairo would be better coming from a Gimp developer than from me.

Otherwise, we are down to a nasty kludge in Gimp. One possibility is suggestion B in comment 4. Another possibility might be to bypass cairo to apply the monitor profile to the Quartz image window. See http://cairographics.org/manual/cairo-cairo-device-t.html However it was not clear to me whether this bypass is available when using the cairo_surface_type quartz_image. Also I do not know whether it is possible to change the color profile of a Quartz image window after the window has been opened.

I am on Windows with a standard-gamut display (probably even less than standard). Yet I think I see the same behavior. My laptop screen is calibrated, and the calibraton data is loaded into the device LUT via Argyll color management. So, if my Desktop is neutral gray RGB, it really looks neutral gray (managed) instead of the original system blue-ish (without management). This is then applied to everything that appears on the screen, regardless of the application.

If I open an image in Gimp, it is already color managed. So, to see the expected colors, I either use "no color management" in Gimp, or choose color management with the sRGB profile (not my monitor's calibration profile).

If instead I choose color management with my monitor's profile, then the image is double-corrected, once by the system, then again by Gimp. The result is incorrect color. Instead of single-correction of bluish-gray to neutral gray, I see a double-correct of bluish-gray to reddish-gray.

I also have Photoshop Elements 11, which I hardly use. It seems that this program knows that the LUT is already corrected, and does not double-correct.

I am using Windows 10, but saw this in earlier Windows, and in earlier Gimp (currently 2.8.16).

As i have learnt at LGM this year, a "proper" (whatever that means)
display profile can and should be used by both the system for managing
all of the screen (including ui elements), *and* by applications that
have special needs (such as GIMP) to manage the image display.

Magically, both system and application would use the right parts
and together do the right thing.

Now I have no clue how to make such a profile, or how to detect
if the display profile is made for that, and how to warn the user
if it isn't.

Elle, maybe you can help?

(In reply to Michael Natterer from comment #8)
> As i have learnt at LGM this year, a "proper" (whatever that means)
> display profile can and should be used by both the system for managing
> all of the screen (including ui elements), *and* by applications that
> have special needs (such as GIMP) to manage the image display.

Do you have a link to the presentation at LGM that discussed how a display profile can be used for UI elements and also for color-managed editing applications? 

> Magically, both system and application would use the right parts
> and together do the right thing.

Are you saying the display profile itself needs to be made in a way that allows some kind of "two-mode" color management (this seems odd)?

> Now I have no clue how to make such a profile, or how to detect
> if the display profile is made for that, and how to warn the user
> if it isn't.
> 
> Elle, maybe you can help?

No, sorry. I have not kept up with whatever progress has been made for desktop color management - my Icewm "desktop" is and has always been a vast expanse of empty gray. If you have any links to relevant information, I'll do my best to learn something about desktop color management.

In the time since I made my above post, I have installed dual-boot Ubuntu 16.04 with compiler, and have compiled GIMP master. Looks very good! Runs better than Partha's earlier Windows compilation. I cannot write (or even read) code, but I can compile, understand color more or less, and have access to the (real) Munsell book of color with its color chips.

I have looked at many online articles explaining color management, most of which were written for Photoshop users, most of which were written for web-image users, some of which were written for print production. It seems to me that part of the problem is inaccurate explanation of what is happening. For example, it seems to me that too much effort is spent complaining about browser rendition of color spaces. My proposed remedies in GIMP:

(1) I suggest that part of the difficulty understanding GIMP's color management could be eased, if the menu choices were changed. For Mode of Operation, instead of the existing three choices (no color management, color managed display, print simulation) thre should be only two: system color management, print simulation.

"System color management" is identical to the existing "no color management." But we don't want to imply that color isn't managed. It's just that GIMP is not doing the management. The Help file should say: "The colors you see in the color picker are identical to the colors in the image. The accuracy of color seen on your monitor is determined by how well your system complies with color standards. The accuracy of colors seen by others will depend on how well their own monitors comply with standards. Properly calibrated devices, with the calibration *.icc or *.icm file loaded into the system, will be most accurate."

For "Print Simulation," the Help file should say: "You must specify the *.icc or *.icm file for the target device, which is usually a printer. In this mode, a color mask is applied to the image on your screen, so that the result is closer to what will be seen on the target device. This is a temporary effect that only appears when using this mode within GIMP. The actual RGB colors of your image are not changed. The accuracy of the simulated colors will depend on how well your monitor is calibrated, and how well the target *.icc or *.icm file corresponds to its device."

(2) The existing "RGB Profile" menu is confusing. It should be changed to "Color Space Model." The Help file should say: "The Color Space Model describes how the image RGB colors are mapped to a a standard set of colors. The sRGB model encompasses colors that within the color rendition capabilities of most monitors, whether CRT or LCD. Use sRGB for routine images to be viewed by computers, especially via Internet. The AdobeRGB model encompasses a greater range of colors, some of which are outside the range that can be accurately seen on computer monitors or printed. However, since AdobeRGB is s super-set of both monitors and printers, it is the color model most often expected by professional and commercial printers. Also use AdobeRGB for prints to `real photo' devices. Color models other than sRGB or AdobeRGB are for specialty use only. Do not use your monitor's calibration profile here."

(3) The existing "CMYK Profile" is also confusing. It should be changed to "Printing Conditions." The Help file should say: "Commercial four-color (CMYK) printers refer to a number of standard printing conditions that describe the capabilities of their machines, inks, and paper. For example, the `FOGRA39' print condition is often used in Europe, and `US Web Coated SWOP v2.' is often used in the USA. If you are using a commercial four-color printer, or have a printer that conforms to one of the accepted standards, load its file here. Some printers do not use a standard print condition, but instead have their own *.icc or *.icm color profile, which is loaded here. If you are printing to a device with unknown or unspecified conditions, use `Unknown' as the choice."

Thus, there should be an `Unknown' choice offered, that does something that would be acceptable to (say) a home printer.

(4) Move and re-purpose "Monitor Profile" as described below.
 
(5) Eliminate the "Print Simulation Profile" choice. It is to become part of "Printing Conditions."

(6) For "mark out of gamut colors," change it to two checkboxes: "Mark out of gamut colors in RGB" and "Mark out of colors in Print Simulation." Either, both, or neither may be checked.

If the "Mark out of gamut colors in RGB" is checked, then the user must load the monitor's *.icc or *.icm profile (or try to read it from system). Use sRGB as default. This determines how the monitor's gamut compares to the Color Space Model. For example, if the Color Space Model is AdobeRGB and the monitor is an ordinary near-sRGB device, then a lot of colors will be out of gamut in RGB. [Note: My own monitor, with calibration, has less gamut than even sRGB.] The Help file should say: "This is applied only in System Color Management mode. It enables you to locate colors that are beyond the ability of you own monitor's cability to display accurately, even though some other devices may be able to display them accurately. This is not necessarily a concern, unless it is vital that other users see these colors rendered closely to your own rendition."

If the "Mark out of gamut colors in Print Simulation" box is checked, then the gamut is marked for print softproofing, the way it is now, but using the "Print Conditions."

(In reply to Elle Stone from comment #9)
> Are you saying the display profile itself needs to be made in a way that
> allows some kind of "two-mode" color management (this seems odd)?

Yes I could not believe it myself but that's exactly what happens.

Apparently the "system" part is simply a LUT that is uploaded to
the gfx hardware and causes zero CPU load; this is clearly a good
enough correction for any GUI elements. The "application" part is
doing everything not possible with the LUT (if anything at all),
costs CPU time (naturally) and is done by applications where needed.

This makes a lot of sense to me, so I probably understood it right :)

I'll try to find the resp. link, It was all explained to me while
they were trying to create such a profile for my laptop monitor,
using some colorimeter device.

Richard, can you please read comments 8, 9 and 11 and paste us the
link you guy used when trying to calibrate my monitor at LGM?

(In reply to Michael Natterer from comment #11)
> (In reply to Elle Stone from comment #9)
> > Are you saying the display profile itself needs to be made in a way that
> > allows some kind of "two-mode" color management (this seems odd)?
> 
> Yes I could not believe it myself but that's exactly what happens.
> 
> Apparently the "system" part is simply a LUT that is uploaded to
> the gfx hardware and causes zero CPU load; this is clearly a good
> enough correction for any GUI elements. The "application" part is
> doing everything not possible with the LUT (if anything at all),
> costs CPU time (naturally) and is done by applications where needed.
> 

Oh. You are talking about the vcgt tag. It is absolutely not the case that all display profiles should have a vcgt tag. See this article: http://ninedegreesbelow.com/photography/monitor-profile-calibrate-confuse.html

I'm pretty sure there's a whole lot more to proper desktop color management than trying to force everyone to make display profiles with vcgt tags.

I believe the OP's post, and my own subsequent post, relate to the situation "Scenario 2: Monitor profiles that DO alter the video card LUTs" in the above-linked article from ninedegreesbelow.

Note that the article describes two kinds of *.icc files: One kind ("calibration") is generally loaded into system LUT by Argyll. It causes the monitor colors to be as close as they can get to the ideal sRGB standard. This kind of *.icc should not be re-applied by GIMP. The second kind of *.icc file ("profile") describes the difference between the calibrated response (which is imperfect despite calibration) and the ideal sRBG response. The second kind of *.icc file could be used by GIMP for additional image correction.

That's my understanding of the article. Could be wrong. Part of the problem is that the term "profile" is being used to mean several different things (calibration, differential response, gamut limits, working color space).

I was told "yes you indeed use the same profile". Each part will
know what to use. Apart from the fact that the calibration device
failed on my monitor, the guys knew what they were talking about,
and yes we used an Argyll tool to upload the LUT, which it took
from the very same .icc I then used in GIMP.

But I suppose there are many combinations that yield correct results,
and many more wrong ones. We really need better docs with reasonable
suggestions here.

I'll reply to comment 10 when I had the time to read it :)

(In reply to anyttwo from comment #14)
> I believe the OP's post, and my own subsequent post, relate to the situation
> "Scenario 2: Monitor profiles that DO alter the video card LUTs" in the
> above-linked article from ninedegreesbelow.
> 
> Note that the article describes two kinds of *.icc files: One kind
> ("calibration") is generally loaded into system LUT by Argyll. It causes the
> monitor colors to be as close as they can get to the ideal sRGB standard.

This is true only if the person doing the calibrating chose sRGB as the target color space. The person doing the calibrating might well have chosen some other target color space, and also might only want to set a neutral gray ramp for the monitor.

> This kind of *.icc should not be re-applied by GIMP. 

AFAIK, no code in GIMP uses the vcgt tag, whether there is one or not (I'm fairly familiar with GIMP's color management code).

> The second kind of
> *.icc file ("profile") describes the difference between the calibrated
> response (which is imperfect despite calibration) and the ideal sRBG
> response. 

You are assuming that everyone wants their monitor to be calibrated as closely as possible to sRGB, which would be a disservice to anyone using a wide gamut monitor, unless the only reason the person purchased a wide gamut monitor is to be able to "calibrate down" to sRGB.

> The second kind of *.icc file could be used by GIMP for additional
> image correction.

No. Both types of monitor profiles are equally useable by GIMP. 

If the user's chosen monitor profile in GIMP Preferences has a vcgt tag (or if the monitor was calibrated and the graphics card curves were stored in a separate file, which is also an option), then the curves in the vcgt tag (or separate file) should be loaded into the graphics card, or else GIMP will show the wrong colors.

If the user chose to profile the monitor in its native state (no curves to be loaded into the graphics card), then of course no curves should be loaded into the graphics card. Or else GIMP will show the wrong colors. 

In either case, GIMP is (should be) completely unaware of what curves might or might not have been loaded into the graphics card.

> That's my understanding of the article. Could be wrong. Part of the problem
> is that the term "profile" is being used to mean several different things
> (calibration, differential response, gamut limits, working color space).

If there is an area that needs to be clarified in the article, send me a private email and I'll try to modify the article to make it more clear (or post here but only if it's relevant to this bug report).

(In reply to Elle Stone from comment #16)
> (In reply to anyttwo from comment #14)
> > I believe the OP's post, and my own subsequent post, relate to the situation
> > "Scenario 2: Monitor profiles that DO alter the video card LUTs" in the
> > above-linked article from ninedegreesbelow.
> > 
> > Note that the article describes two kinds of *.icc files: One kind
> > ("calibration") is generally loaded into system LUT by Argyll. It causes the
> > monitor colors to be as close as they can get to the ideal sRGB standard.
> 
> This is true only if the person doing the calibrating chose sRGB as the
> target color space. The person doing the calibrating might well have chosen
> some other target color space, and also might only want to set a neutral
> gray ramp for the monitor.
> 
> etc.
>

Indeed, I rashly assumed that Gimp users would always to calibrate to sRGB. As you noted, that's not necessarily so. I also read the rest of your reply. Upon further experiment, I have concluded that Gimp's underlying color engine is OK as-is. However, the means of applying it, via the user interface, is the problem.

Experiments (Gimp 2.8 Windows):

My monitor has a calibration file "myCal.icc" which is normally loaded into system LUT by Argyll upon boot. This calibration was created by comparing the original factory colors to the sRGB standard.

EXPERIMENT 1, WITHOUT CALIBRATION LOADED INTO SYSTEM LUT

In this expermiment, I unloaded "myCal.icc" from the LUT, and restored the original factory colors to the screen using the "factory.icc" that came with the product. The screen now appears brighter and bluer, because the manufacturer intended the screen to be more visible in a brightly lit environment, rather than to have accurate color.

I launch Gimp 2.8 and load a known image, with "No Color Management." Everything on screen, including the image, is brighter and bluer than it should be. This is expected.

I go to Preferences > Color Management and use "Color Managed Display." I check the box "Try to use the system monitor profile." Result: The image is corrected to what appears to be proper colors, as if it were calibrated. (I don't have the equipment to determine how accurate it is.)

However, everything else, including Gimp's foreground and background color pickers, are bluish. Thus, if an RGB value is chosen from the color picker and applied to the image, it looks different in the image. This may be the theoretically correct behavior, but it is surprising.

If instead, I un-check "Try to use the system monitor profile" and choose a "Monitor profile" *.icc file, the image colors return to the bluish state, just as if no color correction were applied. It does not matter whether I attempt to load "myCal.icc" or any random *.icc file.

EXPERIMENT 2, WITH CALIBRATION LOADED INTO SYSTEM LUT

I reloaded "myCal.icc" into the LUT. Now everything on screen appears as proper color, not bluish.

In Gimp with no color management, all colors are correct.

With "Color managed display" and "Try to use the system monitor profile," the image colors are incorrect. They are dimmer and browner than they should be. This indicates that "myCal.icc" from the LUT is being applied to the image a second time by Gimp, on top of the LUT. I get the same result if I uncheck "try to use..." and specify "myCal.icc" as the Monotor profile.

However, if I un-check "try to use..." and specify "sRBG.icc" as the Monitor profile, the image colors are correct. This is as expected. Here's why: With "myCal.icc" loaded into the LUT, my machine is effectively converted to a machine with sRBG color rendition. Its as-displayed profile is therefore sRBG.icc, not myCal.icc.

SUMMARY:

I believe that Gimp needs to re-describe the usage and meaning of the choices offered in the Preferences > Color Management dialogs. The currently offered choices are confusing to the user, and do not carry the same meaning as they do in some other graphics programs or in on-line graphic arts discussions.

The underlying engine seems OK as-is. But its usage is baffling.

Proposed solution: Re-structure the dialog boxes and help files. That was the subject of my lengthy post #10, although I am sure it could be improved.

This bug report started with OS X and expanded to include Windows. But AFAIK system color management is not the same on the two operating systems.

Is the OS X problem possibly related to the topic discussed in this thread? https://discuss.pixls.us/t/monitor-profile-support-under-osx-with-gtk-toolkit/1015

Is the Windows problem possibly related to an issue with Nvidia graphics cards (probably not, but it doesn't hurt to ask)? http://forum.luminous-landscape.com/index.php?topic=47976.0

(In reply to Elle Stone from comment #18)
> This bug report started with OS X and expanded to include Windows. But AFAIK
> system color management is not the same on the two operating systems.
> 
> Is the OS X problem possibly related to the topic discussed in this thread?
> https://discuss.pixls.us/t/monitor-profile-support-under-osx-with-gtk-
> toolkit/1015
> 
> Is the Windows problem possibly related to an issue with Nvidia graphics
> cards (probably not, but it doesn't hurt to ask)?
> http://forum.luminous-landscape.com/index.php?topic=47976.0

My laptop uses Intel GMA ("el cheapo") graphics, not Nvidia. Since I can dual-boot to Ubuntu 16.04, I re-did the above experiment with Gimp there. Both the Windows 10 and Ubuntu 16.04 can load my monitor calibration into system LUT.


LINUX, WITHOUT LOADING CALIBRATION INTO LUT (default factory.icc is loaded):

Screen and everything on it is bluish, as expected.

In "color managed display" mode, checking "try to use the system monitor profile" (uncalibrated factory.icc) DOES correct the colors in the Gimp image. No longer bluish. The Gimp UI and color picker remain bluish.

If I un-check "try to use.." and also choose factory.icc as monitor profile, same result as above.

But if I un-check "try to use..." and select myCal.icc (the calibration) as monitor profile, the image remains uncorrected bluish. Likewise, if I choose sRGB.icc for monitor profile, the image remains bluish. The sRGB result is as expected. But to my surprise, it does not seem to matter whether I choose myCal.icc or sRGB.icc; same bluish either way.


LINUX, WITH CALIBRATION LOADED INTO LUT (myCal.icc):

Screen and everything on it is color-correct.

In "color managed display" mode, checking "try to use.." makes no change to the image. That is, myCal.icc is not doubly-applied.

If I un-check "try to use.." and specify myCal.icc as monitor profile, there is no change to the image. Also, if I specify "sRGB.icc" as monitor profile, there is no change to the image.

But if I un-check "try to use..." and select "factory.icc" as monitor profile, the image turns brownish. I had to give this some thought, and concluded that this is correct behavior. If another user (or myself without using calibration) prepared an image that objectively appeared neutral gray when viewed under factory.icc conditions, then it was really a brownish image in color-corrected (sRGB) standards.

I set up a spreadsheet to try to correlate your Windows and Linux results (still working on it). But I'd really like to see your profiles and test image. 

Would you be willing to send along (upload to the web or this bug report or send in a pm) "factory.icc", "myCal.icc", "sRGB.icc", and your test image?

Created attachment 328103 [details]
zip file with color profiles, test image

As requested, zip file here.

Created attachment 328133 [details]
Test image with colors and grayscale ramp

(In reply to anyttwo from comment #21)
> Created attachment 328103 [details]
> zip file with color profiles, test image
> 
> As requested, zip file here.

Thanks! "factory.icc" really is set up to correct a heavy blue color cast! It doesn't have a vcgt tag, rather it uses the Red, Green, and Blue TRC tags to color-correct your monitor's blue color cast. 

Based on your Linux test results I expected your sRGB profile and your myCal.icc profile to have very similar colorants, but they really don't.

When testing ICC profiles a gray test image only tests the gray ramp, and the gray ramp for sRGB and myICC are very similar. So visually you wouldn't notice any change. But the situation changes when looking at a color test image.

Would you be willing to repeat your Windows and Linux comparison, but this time use this attached image? https://bug708579.bugzilla-attachments.gnome.org/attachment.cgi?id=328133

(In reply to Elle Stone from comment #23)
> (In reply to anyttwo from comment #21)
> > Created attachment 328103 [details]
> > zip file with color profiles, test image
> > 
> > As requested, zip file here.
> 
> Thanks! "factory.icc" really is set up to correct a heavy blue color cast!
> It doesn't have a vcgt tag, rather it uses the Red, Green, and Blue TRC tags
> to color-correct your monitor's blue color cast. 
> 
> Based on your Linux test results I expected your sRGB profile and your
> myCal.icc profile to have very similar colorants, but they really don't.
> 
> When testing ICC profiles a gray test image only tests the gray ramp, and
> the gray ramp for sRGB and myICC are very similar. So visually you wouldn't
> notice any change. But the situation changes when looking at a color test
> image.
> 
> Would you be willing to repeat your Windows and Linux comparison, but this
> time use this attached image?
> https://bug708579.bugzilla-attachments.gnome.org/attachment.cgi?id=328133

Got image, will do. Might be able to get photo screenshots with quality camera. Due to time zone differences, you might not see my report until "tomorrow" in your time (England?). The sRGB.icc file was a copy of a generic sRBG file, not a calibration. I don't recall whether it was a copy of the one bundled with Gimp, or with my Adobe software, or part of Windows...

(In reply to anyttwo from comment #24) 
> > Would you be willing to repeat your Windows and Linux comparison, but this
> > time use this attached image?
> > https://bug708579.bugzilla-attachments.gnome.org/attachment.cgi?id=328133
> 
> Got image, will do. Might be able to get photo screenshots with quality
> camera. Due to time zone differences, you might not see my report until
> "tomorrow" in your time (England?). 

Thanks! and no hurry! As another thing to check, is it possible that some errant settings in the Windows Color System might be causing some interference? 
http://photo.net/digital-darkroom-forum/00aA69
http://forum.luminous-landscape.com/index.php?topic=76312.0

> The sRGB.icc file was a copy of a
> generic sRBG file, not a calibration. I don't recall whether it was a copy
> of the one bundled with Gimp, or with my Adobe software, or part of
> Windows...

It's not from GIMP. It might be from Windows - I have an identical profile that came from Windows 2000.

I don't use any secondary color management in either Windows or Linux. Windows has an Intel graphics management panel that could be used for color tweaks, and Windows itself allows color tweaks. But those are set to neutral. Linux allows color tweaks via command line, unused. On both sides, I am loading the color profile into LUT using Argyll (DisplayCal GUI).

Previously, I reported Gimp's behavior using only a gray image, just to focus on overall effect. But using color ramps, the situation is clearer: Both Windows and Linux behave the same way!

What I did: I used a color target provided by Elle, and focused on the color ramps for cyan, magenta, yellow, black, red, green, and blue (columns 13-19 in the target). The effect was easier to describe there. I paid particular attention to the evenness of the ramps, whether the colors hit gamut limit before reaching the end of the ramp, and generally whether rendition was warm or cool relative to expectations. Using a camera was unhelpful.

Display intent was set to "relative colorimetric" so that any gamut problem would be easier to notice. Of course, "try to use..." was unchecked.

1. No matter which profile (myCal, factory, sRGB) was loaded into LUT, the image colors were the same using no color management, and color management with sRBG as monitor profile. I don't mean that they were correct; only that switching between no color management and management with monitor sRBG did not make a difference.

2. With myCal in LUT: Colors were correct using either no color management, or (as stated above) color management with monitor sRGB. Using myCal as monitor profile produced a slightly warm color rendition, with the red-containing colors bonked against gamut (the top 2 or 3 steps were rendered identically). That's also what happens if I "try to use" the system profile, which is the expected result. If monitor profile was set to factory, colors were oversaturated and very warm.

3. With factory in LUT: With no color management (or management using sRBG monitor profile) color rendition was cool. Managed using myCal, colors were slightly cool, and red-containing colors bonked against gamut. Managed using factory, colors seemed correct (hard to tell with the bluish screen).

4. With sRBG in LUT: With no color management (or managed with sRBG profile) colors were cool. Managed using myCal, colors were slightly cool. Managed using factory, colors were oversaturated and warm.

Again: Same for Windows and Linux.

I am unable to discern the underlying logic. Does anyone else have a color-managed system with its calibration loaded into LUT, for comparison?

I note that the myCal calibration has file extension icc, whereas the factory and sRGB profiles have file extension icm. Does that make a difference?

Tech note: I don't believe I've ever seen a color-tagged jpeg or tiff with anything other than sRGB or AdobeRGB attached. That would be the workspace, not the calibration profile.

(In reply to anyttwo from comment #26)

Cutting to the chase: When I replicate your tests using your profiles on my monitor, of course the colors are wrong. But what I see coheres with what you describe. In particular, your test results for case 2 match what I'm seeing in terms of increased saturation. 

As your results for Windows and Linux exactly match even for case 2, my guess is that GIMP is doing the right thing on both Windows and Linux, or else there would be a lot of other GIMP users complaining about problems with installed monitor profiles with nonlinear vcgt tags.

> I am unable to discern the underlying logic. Does anyone else have a
> color-managed system with its calibration loaded into LUT, for comparison?

I'll try to find the time to make such a monitor profile and see what happens, though hopefully someone else will chime in. 

In the meantime, I've made some notes below (not relevant to this bug report except to possibly clarify some practical issues when testing GIMP and monitor profiles):

> What I did: I used a color target provided by Elle, and focused on the color
> ramps for cyan, magenta, yellow, black, red, green, and blue (columns 13-19
> in the target). The effect was easier to describe there. I paid particular
> attention to the evenness of the ramps, whether the colors hit gamut limit
> before reaching the end of the ramp, and generally whether rendition was
> warm or cool relative to expectations. 
> 
> Display intent was set to "relative colorimetric" so that any gamut problem
> would be easier to notice. Of course, "try to use..." was unchecked.

Your monitor profiles are matrix profiles, and your sRGB profile and also the GIMP built-in sRGB profile are matrix profiles, which don't have perceptual intent tables. So when you ask for perceptual intent what you get is relative colorimetric. 

GIMP 2.8 has a coding error that makes perceptual intent use black point compensation (bpc) and relative colorimetric not use bpc. Using or not using bpc is irrelevant unless your chosen monitor profile and/or your image's profile has a non-zero black point. myCal does have a non-zero black point tag, but the TRCs (which take precedence over the black point tag) still start at zero.

Regardless, keeping the Display rendering intent constant at relative colorimetric is a good idea  as it eliminates a possible source of differences between Windows and Linux (unlikely but possible).


> 
> 1. No matter which profile (myCal, factory, sRGB) was loaded into LUT, the
> image colors were the same using no color management, and color management
> with sRBG as monitor profile. I don't mean that they were correct; only that
> switching between no color management and management with monitor sRBG did
> not make a difference.

When color management is disabled, the image RGB values are sent unchanged straight to the screen.

Your sRGB.icm and GIMP's built-in sRGB profile are almost identical. When color management is enabled, sRGB.icm is selected as the monitor profile, and the image is assigned the GIMP built-in sRGB profile, the image RGB values are converted from sRGB to sRGB, resulting in unchanged image RGB values being sent to the screen.

So for sRGB images the test case of "no color management" and "color management using sRGB as the monitor profile" reduce to exactly the same thing. It would indicate a serious problem if your results were actually different in these two test cases. 


> 
> 2. With myCal in LUT: Colors were correct using either no color management,
> or (as stated above) color management with monitor sRGB. Using myCal as
> monitor profile produced a slightly warm color rendition, with the
> red-containing colors bonked against gamut (the top 2 or 3 steps were
> rendered identically). That's also what happens if I "try to use" the system
> profile, which is the expected result. If monitor profile was set to
> factory, colors were oversaturated and very warm.

To follow your test procedure, I set my monitor to use its sRGB preset.
Using "dispwin -I -v3 myCal.icc" to install myCal.icc makes everything look very warm, which is expected because my monitor's sRGB preset is pretty close to neutral, and your monitor's default state is very cool. Also choosing myCal.icc as the monitor profile (instead of sRGB) indeed makes the colors look more saturated. On my monitor I still see color gradations. However many notebook display screens (and even some desktop monitors) have "smaller than sRGB" color gamuts, which might be why the most saturated red colors look exactly the same on your screen.


> 3. With factory in LUT: With no color management (or management using sRBG
> monitor profile) color rendition was cool. Managed using myCal, colors were
> slightly cool, and red-containing colors bonked against gamut. Managed using
> factory, colors seemed correct (hard to tell with the bluish screen).
> 
> 4. With sRBG in LUT: With no color management (or managed with sRBG profile)
> colors were cool. Managed using myCal, colors were slightly cool. Managed
> using factory, colors were oversaturated and warm.

My results are consistent with what you describe. As an aside, factory and sRGB don't have vcgt tags, so installing them as the system monitor profile actually loads a linear ramp into the video luts, same as running "dispwin -c".


> 
> I note that the myCal calibration has file extension icc, whereas the
> factory and sRGB profiles have file extension icm. Does that make a
> difference?

No, the extension makes no difference whatsoever. 

> 
> Tech note: I don't believe I've ever seen a color-tagged jpeg or tiff with
> anything other than sRGB or AdobeRGB attached. That would be the workspace,
> not the calibration profile.

Many people do produce tiffs in color spaces other than sRGB or AdobeRGB, but these people hopefully are using high bit depth image editors. The color space you choose depends on your workflow and image editor. For editing at 8-bit precision you really need to stick to sRGB, though some people do edit 8-bit AdobeRGB images.

To summarize, your test case 2 does produce noticeably more saturated colors when myCal is installed as the system monitor profile and also chosen as the monitor profile in GIMP. The question is whether this is correct behavior. I'm guessing it is, but I'll ask around to see if I can find anyone who uses a system monitor profile with a vcgt tag, and/or make such a profile for my own monitor and see what happens.

Created attachment 328289 [details]
zip file with scripted html showing proposed UI change

After learning about vcga in its gory details, it seems to me that GIMP's internal color management behavior is OK as-is, but the color management user interface needs to change (and the help file). I have attached an html page with javascript, showing what I believe to be a compliant UI. The choices can be selected and some notes appear, but of course it does nothing in GIMP.

Highlights: (1) "RGB profile" is now "RGB Workspace" to agree with common usage. Built-in choices (no need to choose a file, it's included) are sRGB and AdobeRGB, with option to pick some other from *.icc. (2) No more "CMYK profile." It's the same as printer color profile. Several common choices are built-in (if they are available as open-source or licensed). (3) User is asked how the monitor is calibrated. Sensible choices are offered, including none. These are explained in more detail in help. In most cases, the user will not load an *.icc file, and GIMP will quietly do what it does now when sRBG.icc is loaded here. The concept is that a calibrated (or eyeball-adjusted) monitor is actually sRBG, so GIMP makes no additional color adjustment to the displayed image. This is actually what I have been doing in GIMP, and it works both onWindows and Linux.

...just for the files, we've already been at his point of the discussion in Oct 2014

https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00057.html

"Therefore in GTK+ applications such as GIMP, images must be converted to
sRGB before they can be displayed on the screen."

Excellent, Simone! That confirms the recent discussion.

Elle, others: Please do take a look at the file I attached in my comment #28. All I did was show how, with a change to the color management UI (not the engine), users can be forced to "do the right thing" by carefully-phrased option choices. It is what I have figured out by trial-and-effor usage, but only recently have I come to understand why. Of course, the Help file would also have to be changed there. Not a big deal. Easy for me to say, since I'm not a programmer.

Also, ignore my earlier comment #10.

Just tested: On Linux, Krita's color management behavior when choosing the system profile is identical to GIMP's behavior. That is, if the system already has calibration loaded to LUT, then the correct choice for profile within the application is sRGB. Choosing to use the monitor profile will over-manage color, producing an incorrect result. This is counter-intuitive to ordinary users. I really think that GIMP (and Krita) need to re-do that.

I have also looked at the online help file for Photoshop CS6. Apparently, Photoshop provides a pre-configured menu of Workspace profiles (sRGB, AdobeRGB, ProPhoto, etc.) but does not expect the user to load the monitor's profile or any custom profile (it can be done, as an exception). The Workspace, which is a standard industry term, is what GIMP calls the "RGB color profile." It is a place for choosing standard color space, not calibration curves. Not clear if there is anywhere one would load the monitor's profile. It is expected to be a calibrated machine, for that kind of user. It may be that Photoshop can detect whether the monitor is calibrated to sRGB or AdobeRGB or something else, and suggest that as the default Workspace? In my case, that would be sRGB, as expected.

Photoshop does provide for a CMYK profile, which again is a standard color space used in the print industry, with a choice of standard options. These are well-known from Acrobat Pro, which is intended for printing and uses the standard term "output intent" there. Examples of standard output intent are FOGRA39 and CGATS.6. If I understand Photoshop's terminology, the CMYK Workspace and sofproofing device profile are expected to be the same, in most cases. In GIMP, that's what I have done in the past: Same profile selected for CMYK and softproofing, and it is one of the standard industry print profiles. Photoshop comes with them built-in.

Also, I looked through Elle's site, and learned that if GIMP wants to get a workspace beyond sRGB, that involves BABL and GEGL and possible OpenCL. Ouch.

(In reply to anyttwo from comment #31)
> Just tested: On Linux, Krita's color management behavior when choosing the
> system profile is identical to GIMP's behavior. That is, if the system
> already has calibration loaded to LUT, then the correct choice for profile
> within the application is sRGB. 

This is not true for monitor profiles that don't require loading vcgt tags into the video card. And in theory it shouldn't be true for monitor profiles that do require loading vcgt tags into the video card. But theory is one thing, testing is another. So I did some testing.

> Choosing to use the monitor profile will
> over-manage color, producing an incorrect result. This is counter-intuitive
> to ordinary users. I really think that GIMP (and Krita) need to re-do that.

Your attention to detail and also your writing skills are very impressive (and GIMP needs people to help with writing documentation for 2.10, hint hint!). But you are basing conclusions on what you observe with just the one laptop display? 

I replicated your experiments with two very different systems:

1. An older Acer laptop running Debian Sid, with on-board intel graphics and a really poor display with a color gamut that's considerably smaller than sRGB. sRGB's reddest red is pretty far outside the color gamut of this display, so when using a properly made monitor profile, sRGB's reddest reds will be clipped, which is what I think you are seeing in the test image.

2. A desktop running Gentoo Linux, again with on-board intel graphics, but with an NEC monitor designed for photographic editing - not wide gamut but with a color gamut that's about 12% larger than sRGB. This monitor can show red colors that are outside the sRGB color gamut, redder than sRGB's reddest reds.

I used ArgyllCMS 1.8.3 and a Spyder2 color measuring instrument to make monitor profiles with vcgt tags for both systems, using the following commands:

dispcal -gs -o acer_srgbtrc_vcgt
dispcal -gs -o nec_srgbtrc_vcgt

"-gs" means "calibrate the TRC of the monitor/graphics card to match the sRGB TRC, which isn't an especially great idea (http://argyllcms.com/doc/gamma.html, http://argyllcms.com/doc/dispcal.html#g), but seems to be widely recommended.

Then I installed the new monitor profiles on each system, made sure the vcgt tags were correctly loaded into the video LUTs, started GIMP, and repeated your tests comparing using sRGB vs the respective system monitor profiles as the selected monitor profiles in GIMP:

* Using sRGB as the monitor profile for my Asus display makes the red colors in the test image look much *duller* than using acer_srgbtrc_vcgt.icc. This is because my Asus display has a smaller color gamut than sRGB. Using the argyllcms profile made reds look clipped.

* Using sRGB as the monitor profile for my NEC makes the red colors in the test image much *brighter* than using nec_srgbtrc_vcgt.icc. This is because my NEC monitor has a larger color gamut than sRGB.

Using the right monitor profile in each case does show more accurate colors, but only insofar as the displayed colors fall inside each monitor's respective color gamut. Once the colors reach the limit of the monitor's color gamut, the monitor just shows solid red (or green or whatever other color is clipping at the edges of the monitor's color gamut).

This article has pictures illustrating the problem of a mismatch between various LCD monitors' color gamuts and sRGB: How much of the sRGB color gamut can be displayed on your LCD monitor? (http://ninedegreesbelow.com/photography/srgb-bad-working-space-profile.html)

> Also, I looked through Elle's site, and learned that if GIMP wants to get a
> workspace beyond sRGB, that involves BABL and GEGL and possible OpenCL. Ouch.

Indeed Ouch.

Anyway, Linux doesn't seem to have any problems with monitor profiles that have vcgt information, and if you get the exact same results on Windows and Linux, probably Windows also doesn't. Rather I will guess that what you are seeing is from a color gamut disparity between sRGB and your Acer display.

The problem with MacIntosh would seem to be a completely separate issue.

OK, I can see that. Although I can access wider-gamut monitors with Photoshop at the friendly local university, I cannot change any settings involving the system. Don't have power-user authority. And, I can't use GIMP (not even portable).

My limited-gamut laptop does indeed bonk colors less than full srGB. But I only use color management for softproofing to press, where the CMYK gamut is also rather small. It is much smaller than a home photoprinter. Except for a small range of green-blue, there's not much my screen cannot show, that could have been printed.

In Gimp 2.8 I can "softproof" my screen's own *.icc profile, and see its gamut, as if it were a printer. This hack is also done in Photoshop, according to some users. But Gimp 2.9 (as of a week or two ago) detects if the user attempts to use an RGB profile as a softproof output, and prohibits it.

But the real point I am trying to make is that Gimp's color management, in particular its dialog and choices, is obscure. By experiment I learned that with my vcgt loaded into system, RGB profile AdobeRBG (for press), sRBG as monitor profile (not loading system), and the print device *.icc for both CMYK profile and printer profile, I get good printed color. That is, keeping gamut in mind.

Looking around the Internet, I see that the main complaint is handling color with wider-gamut monitors and photo-quaility printers. So maybe that's a more important issue than anything pertaining to low-gamut press.

(In reply to anyttwo from comment #33)
> In Gimp 2.8 I can "softproof" my screen's own *.icc profile, and see its
> gamut, as if it were a printer. This hack is also done in Photoshop,
> according to some users. But Gimp 2.9 (as of a week or two ago) detects if
> the user attempts to use an RGB profile as a softproof output, and prohibits
> it.

Good that you mention that. At the time I hacked this it didn't occur to
me that you could use a non-CMYK profile for proofing. Will drop that
restriction.

After exhanging a few PMs with Elle, I believe I have hunted down the reason for the "double color management" behavior. The solution requires a particular way to use DisplayCAL, works with both Windows and Linux, and works in all color-managed applications I have on both systems (including a few Windows-native that are not open source).

It seems that the problem arises when DisplayCAL loads a calibration profile into LUT at login, then an application later tires to re-apply that same profile to "correct" what was already corrected. The solution is to fool the application into thinking that the monitor profile is sRGB, even though it is not.

Step 1: Use DisplayCAL to load sRGB (not the calibration profile) as monitor profile, at each login. This informs all applications that the profile is sRGB, but does not color-correct any part of the display.

Step 2: After login, launch DisplayCAL, and tell it to "Load calibation curves from calibration file or profile..." using the calibration *.icc file. This will color-correct all of the monitor, as desired. But it will NOT change the reported monitor profile; it is still sRGB, as far as applications are concerned. This step has to be manually repeated after each login; do not automate it with DisplayCAL. It may or may not be necessary to leave DisplayCAL open (it can be minimized).

Now, in GIMP (and every color-managed application), I can shoose sRBG (or whatever) as my RGB Workspace. Image colors will only change in response to Workspace gamut, not calibration. And, I can choose "try to load monitor profile" for "monitor profile." This is the desired behavior: The whole screen is color-corrected, but GIMP thinks it's sRGB and does not apply a second correction.

I note that some other applications do not offer a choice for monitor profile; it is loaded from the system automatically.

(In reply to anyttwo from comment #35)
> After exhanging a few PMs with Elle, I believe I have hunted down the reason
> for the "double color management" behavior. The solution requires a
> particular way to use DisplayCAL, works with both Windows and Linux, and
> works in all color-managed applications I have on both systems (including a
> few Windows-native that are not open source).

My apologies if I said something in our email exchange that wasn't clear. As we discussed, trying to make a very accurate monitor profile for a display with a very small color gamut can make too many colors display as clipped colors.

What you describe sounds like a reasonable solution for your particular display screen given your current monitor profile. Though it would be nice if you could also try making a profile monitor profile using ArgyllCMS "colprof -ag", without a vcgt tag (which is what I do with my very small gamut laptop screen).

However, your procedure is not suitable for a larger gamut monitor that has been properly calibrated and profiled, and in fact on such a monitor your procedure produces systematically incorrect colors. For example, trying your procedure on my calibrated and profiled desktop monitor (that has a somewhat wider than sRGB color gamut) produces colors that are systematically too warm and oversaturated, regardless of whether I load a vcgt tag into the video card.

This bug report originally is about problems with Mac. Linux doesn't have the same problem, and as far as I can tell neither does Windows.

Yes, the large-gamut versus small-gamut issue was mentioned and understood. But I can only replicate with small gamut, as was noted. In my case, using Argyll executables alone (without DisplayCAL, and with sRGB as nominal profile) I can script the solution:

dispwin -L && dispwin /path/to/myCal.icc && exit

Since I regrettably cannot be of use here, not having large-gamut, I will drop the subject.

I have repeated the tests described in bug 739989 using Gimp 2.8.16 (instead of 2.8.14) under Mac OS X 10.9.5 and the results are the same.

As no-one has contradicted the guesses I made in comment 6, I assume they are correct.

(In reply to Elle Stone from comment 18)
The OS X problem is indeed closely related to the topic discussed in this thread https://discuss.pixls.us/t/monitor-profile-support-under-osx-with-gtk-toolkit/ and they have come to the same conclusion, that the problem is in cairo.

I will open a ticket in the cairo bug tracker, although I think it would be better if the bug report came from a Gimp developer. In particular, I don't know how I could test any fix that might be made by the developers of cairo.

Created attachment 329917 [details]
Version of sRGB profile with video card gamma table (vcgt)

In comment 4, suggestion B, I described a workaround for the OS X problem. I also noted a snag with this workaround if it is necessary to load a video card gamma table. As I noted, the dispwin command of Argyll CMS gives a failure message.

The dispwin command to load a vcgt does work under OS X if the system monitor profile contains a vcgt. So all that is needed to complete the workaround is a version of the sRGB profile that contains a vcgt. I have attached such a profile attachment 329917 [details]. The vcgt "does nothing" (LUT output=input).

Turning to the last part of my suggestion B
"Alternatively, the sRGB profile could be modified by adding the data for the table, if suitable software can be identified to do this."
The sRGB profile that I have attached opens up another way doing this. The vcgt can simply be copied from the true monitor profile, and pasted over the vcgt in the attached sRGB profile, using a hexadecimal editor. I use http://ridiculousfish.com/hexfiend/ You can find a description of the .icc file format at http://www.color.org/ICC_Minor_Revision_for_Web.pdf Alternatively...

I have posted a detailed walkthrough for all of this at http://gimpforums.com/thread-display-color-management-under-os-x which I hope will allow the less technically-minded to do it successfully.

(In reply to Adrian from comment #40)
> 
> Turning to the last part of my suggestion B
> "Alternatively, the sRGB profile could be modified by adding the data for
> the table, if suitable software can be identified to do this."
> The sRGB profile that I have attached opens up another way doing this. The
> vcgt can simply be copied from the true monitor profile, and pasted over the
> vcgt in the attached sRGB profile, using a hexadecimal editor.
> 

Indeed. Although my earlier comments were off-topic regarding OSX, I have solved the issue on Windows and Linux using a hex editor to merge two profiles, as described above. Works. But the OSX issue seems to be GIMP-related, whereas my diversion was prompted by what I now think was a bad (incorrectly done) icc file, and thus was user-specific.

On a related note: Even now (GIMP master today, compiled Linux) could improve its user interface for color management. The recently-added menu item Image... Color Management, in addition to the prior Edit...Preferences...Color Management, is helpful. But I think it would be best if at least part of the color management dialog box could appear as a toolbox tab, so that the current status of color management, as well as any desired changes, could be seen at a glance without obscuring the image by a drop-down menu or dialog box. At a minimum, the mode should be displayed (and changeable beween color managed display and softproof) and the softproof icc (if used) should be displayed and changeable, as well as gamut warning on/off, in the toolbox.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/497.