On Thu, May 12, 2016 at 3:46 PM, Elle Stone wrote:

There is a new "Image/Color Management" option to "Enable Color Management". The option is checked by default. For sRGB images, checking or unchecking the option doesn't seem to make any difference.

What is the purpose of this new option? It doesn't do the same thing as going to Preferences and selecting "Color Management/Mode of operation/No color management".

It isn't supposed to. This is a per-image option. Similarly, you get to choose an ICC profile when you create a new image.

Alex

On Thu, 2016-05-12 at 08:46 -0400, Elle Stone wrote:

There is a new "Image/Color Management" option to "Enable Color  Management". The option is checked by default. For sRGB images, checking 
or unchecking the option doesn't seem to make any difference.

Exactly, even without a profile, pixels have some meaning. And in GIMP, the "default" meaning is sRGB.

What is the purpose of this new option? It doesn't do the same thing as 
going to Preferences and selecting "Color Management/Mode of  operation/No color management".

The prefs option is for display color management, and will soon only be a default for a per-display switch.

The option in Image -> New allows to disable color management and whatever color management transforms on a per-image base.

This is mainly because almost nobody understands what this whole color stuff is about at all. All (sic!) graphics artists I know and have asked switch off color management entirely in Photoshop because it's this confusing thing that changes colors in an unpredictable way  (which is not surprising given the cluelessness).

Most people dealing with photos do know their colors however and have it on, and have the right profiles.

The sane choice way to let users disable it, rather than forcing it upon them.

Regards, --Mitch

On Thursday, May 12, 2016, Michael Natterer wrote:

Most people dealing with photos do know their colors however and have it on, and have the right profiles.

The sane choice way to let users disable it, rather than forcing it upon them.

Agreed.

pat david
http://blog.patdavid.net

On Thu, 2016-05-12 at 16:28 -0400, Elle Stone wrote:

On 05/12/2016 03:56 PM, Michael Natterer wrote:

The prefs option is for display color management, and will soon only be a default for a per-display switch.

What does the above sentence mean?

Specifically what does "per-display switch" mean? Is this for  multi-monitor support? Or something else?

I should have written "image window" not "display", that's an internal code term. There will color management options per image view, so you can e.g. see the normally color managed and the proof version side by side.

--Mitch

Am 12.05.2016 um 21:56 schrieb Michael Natterer :

What is the purpose of this new option? It doesn't do the same thing as
going to Preferences and selecting "Color Management/Mode of operation/No color management".

The prefs option is for display color management, and will soon only be a default for a per-display switch.

The option in Image -> New allows to disable color management and whatever color management transforms on a per-image base.

Woooh, I can’t believe it! You’re saying that

This is mainly because almost nobody understands what this whole color stuff is about at all.

Is this how you think about all the people who use GIMP? That almost none of them understands color management?

May I remind you of your product vision? -> http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision

"GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists"

Do you really think, that these targeted audience, your targerted audience, doesn’t know what color management is all a bout? Or, sorry to say so, is it that _you_ are the one that does not know waht different aspects of color management have to be taken care of in an image editor?

All (sic!) graphics artists
I know and have asked switch off color management entirely in Photoshop because it's this confusing thing that changes colors in an unpredictable way (which is not surprising given the cluelessness).

So, this is how you think about your target users? They are clueless? Your target users - professional artists and photographers - switch off color management, because it’s confusing them? Or is it that the users _you_ know and the users who claim theirselves as professionals do not know what color manangement is and don’t know how to handle it?

So, may it be, that this - „all graphics artist you know … switch off color management - is the real cause why GIMP doesn’t have a working color management in 2016? You don’t know anybody who uses it and so you don’t see any need to implement it? Come on, let’s face reality. It’s 2016 and almost all software for image or photo editing I know is capable to handle color management. Yet GIMP 2.8.x is still broken in some parts….

Trust me, there are a lot, a really lot of professional users, artists, scientists and photographers - again I’ll remind you that these are your target audience as described in your product vision - who know what color management is about and who use it and want to use it in a correct and predictable way. Count me one of them.

Most people dealing with photos do know their colors however and have it on, and have the right profiles.

The sane choice way to let users disable it, rather than forcing it upon them

Well, this may be the sane choice for _you_ but, please, don’t tell others - your target audience: professional photographers, artists and scientists - what their sane choice has to be.

Regards Simone Karin

13 мая 2016 г. 1:22 пользователь "Simone Karin Lehmann" написал:

Is this how you think about all the people who use GIMP? That almost none

of them understands color management?

There are probably a few dozens of people in the world who really do understand CM. It's one of those things where the more you know, the more you don't know.

May I remind you of your product vision? ->

http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision

"GIMP is a platform for programming cutting-edge image processing

algorithms, by scientists and artists"

Do you really think, that these targeted audience, your targerted

audience, doesn’t know what color management is all a bout?

That's the reality.

So, this is how you think about your target users? They are clueless?

Your target users - professional artists and photographers - switch off color management, because it’s confusing them?

People who are professionals still do crazy things like tagging a photo with an ICC profile of a display. And yes, I know quite a handful of those who found CM to be too complicated, switched CM off and "calibrated" their output to work well with just one print shop.

So, may it be, that this - „all graphics artist you know … switch off

color management - is the real cause why GIMP doesn’t have a working color management in 2016? You don’t know anybody who uses it and so you don’t see any need to implement it?

Please calm down.

The sane choice way to let users disable it, rather than forcing it upon them

Well, this may be the sane choice for _you_ but, please, don’t tell

others - your target audience: professional photographers, artists and scientists - what their sane choice has to be.

You are pretty much saying that it is wrong to force freedom of choice upon people. This doesn't make any sense.

Ale

On Sun, 2016-05-15 at 08:14 -0400, Elle Stone wrote:

On 05/12/2016 03:56 PM, Michael Natterer wrote:

On Thu, 2016-05-12 at 08:46 -0400, Elle Stone wrote:

There is a new "Image/Color Management" option to "Enable Color Management". The option is checked by default. For sRGB images, checking
or unchecking the option doesn't seem to make any difference.

Exactly, even without a profile, pixels have some meaning. And in GIMP, the "default" meaning is sRGB.

Frankly I don't see the utility of this new option. Users who don't want 
to deal with the complexities of ICC profile color management already 
have the option to only edit sRGB images.

True, but they need to know that what they want is equivalent to using sRGB. They want a "don't bother me with any of this" setting because they really don't know or don't want to know any of it.

But if there really is a defensible use case, here are two concrete  suggestions:

1. Move this new option down to the group of options below and separated 
from the two normal Color Management options.

Do you mean in the new submenu? IMO a global "enable" switch clearly belongs at the beginning of a section.

2. Relabel the option as "Assume this image is an sRGB image".

That's exactly what is confusing to them :) "What is sRGB again?"

Here is why I'm making these two suggestions:

GIMP menu items and help hover tips shouldn't misinform GIMP users, but 
instead should tell GIMP users the truth and also help to educate them.

I agree, and propose to have tooltips that disabling is the same as using the built-in sRGB profiles.

In an ICC profile color-managed editing application, pixels are  literally meaningless without knowing which ICC profile should be used 
to give the channel values meaning. You can't change the very basis of 
ICC profile color management by arbitrarily deciding that for GIMP "no 
profile" actually means "sRGB". Because it doesn't. And pretending that 
it does will mislead GIMP users.

But it does, it really does in the code. no profile == sRGB.

The global switch in "Preferences/Color Management" to set the Image  display mode to "No color management" actually does disable color  management. This means that the image RGB channel values are sent  directly to the screen. This is the functional equivalent of assigning 
the user's chosen monitor profile to all open images.

That switch is *only* for display color management, If you disable it, things are still properly converted if you copy pixels between images.

Unchecking the pre-checked box in the "Images/Color Management" menu  that says "Enable Color Management" sounds like it should do the exact 
same thing as going into Preferences and setting the Image display mode 
to "No color management". But what unchecking "Images/Color Management" 
actually does is *assume* the image is an sRGB image, even if the image 
already has an ICC profile that's not the sRGB profile. This assumption 
only produces the same result as choosing "No color management" in  Preferences if the user has also chosen sRGB as their monitor profile in 
"Preferences/Color Management".

I just reorganized the prefs page and it should now be clearer that it  is meant for display settings only.

The truthful and less confusing verbiage for this prechecked  "Images/Color Management/Enable Color Management" option would be  "Images/Color Management/Assume this image is an sRGB image".

We can have a tooltip saying so, but using that suggested wording defeats the "don't bother me, I don't want to understand it" purpose of the setting.

Also, the position of the new option gives it "mouse scrolling" and  "visual" importance. The user has to read and then scroll past this new 
option to get to the more normal Color Management options to assign or 
convert to a new ICC profile.

So the new option is at the right place. Sorry, but I'm 100% convinced that the vast majority of users has no clue whatsoever about color management. Heck they can't even distinguish pixels from DPI. A simple was to turn it off is IMO exectly what's needed.

This prominent placement of the new option in the "Image/Color  Management" menu makes it seem like a normal thing to do while editing 
an image is to disable Color Management, which of course isn't at all 
what this option really does.

It switches to default things and that's all it can do, there are no pixels without meaning ever since we made color management omnipresent in GIMP.

So again, if this new option really does have some utility (and again I 
can't see that it does), then it would be better to do the following:

1. Move this new option down to the group of options below and separated 
from the two normal Color Management options.

Sorry, nope, unless you convince me with some better arguments :)

2. Relabel the option as "Assume this image is an sRGB image".

That definitely not, but I will immediately add tooltips saying that it is the same as choosing sRGB.

Regards, --Mitch

On Sun, 2016-05-15 at 09:28 -0400, Elle Stone wrote:

On 05/15/2016 08:14 AM, Elle Stone wrote:

2. Relabel the option as "Assume this image is an sRGB image".

And make this option be *un*checked by default, of course. So the image 
by default is color-managed in the normal way. And checking the new  option would make GIMP treat the image "as if" it were an sRGB image, 
even if it's not.

Sorry about leaving this part out.

Yea, reversing the meaning of the label would of course reverse the meaning of the default.

But aside from what I wrote before, I think that "disable" toggles are a bad thing in general.

"Enable this option to disable something" -> what? -> bad.

--Mitch

On Mon, 2016-05-16 at 17:26 +0200, Michael Natterer wrote:

 

2. Relabel the option as "Assume this image is an sRGB image".

That definitely not, but I will immediately add tooltips saying that it is the same as choosing sRGB.

Done, this should be more obvious now:

commit c0fb1362034fb4da24ee46a677f9833495ee6ca5 Author: Michael Natterer
Date:   Mon May 16 17:41:04 2016 +0200

    app: add tooltips that mention that disabling color management == sRGB
    
    Also say "better leave this enabled".

commit 335727dd267a44ac48fc4fdfa1678f7005fbb50f Author: Michael Natterer
Date:   Mon May 16 17:37:22 2016 +0200

    libgimpwidgets: change the tooltip of GimpColorConfig:mode     
    to say "How images are displayed on screen." instead of "Mode of     operation for color management.". The old text was never accurate.

Elle Stone wrote:

I can't think of a single use case for trying to edit a non-color-manged image in an ICC profile color-managed editing application such as GIMP.

I think I can think of one: creating displacement/bump maps (often used as textures in 3D graphics). Often in that case, pixel values aren't treated as color, but a numeric non-color data (i.e. it's an instruction to displace geometry---or other pixels---by this numeric mapping value).

But perhaps the artists that create these maps are not covered in the audience specified in GIMP's vision statement.

-Jason

/me scurries off to a corner

On Fri, May 20, 2016 at 9:37 PM, Jason van Gumster wrote:

But perhaps the artists that create these maps are not covered in the audience specified in GIMP's vision statement.

They are.

Alex

El vie, 13-05-2016 a las 00:15 +0200, Simone Karin Lehmann escribió:

 
The prefs option is for display color management, and will soon only be a default for a per-display switch.

The option in Image -> New allows to disable color management and whatever color management transforms on a per-image base.

Woooh, I can’t believe it! You’re saying that

This is mainly because almost nobody understands what this whole color stuff is about at all.

Is this how you think about all the people who use GIMP? That almost none of them understands color management? 

Although I share your shock, I think Michael is right. Almost nobody using GIMP understands color management, because there is virtually nobody using GIMP seriously, and probably nobody will because of this kind of design decisions.

I'm one of the few guys around using GIMP professionally in the field of graphic design, and with each decision like this one, pointing to the wrong audience (not the audience defined in the "product vision") I'm becoming less and less convinced that it is a good idea to keep using it.

The most pressing issues (like performance and quality) are constantly postponed. But hey, we have a new dark theme and new icons.

This is ridiculous. And this is what is keeping serious users from being interested in the application. And if things keep going in this direction, GIMP will end up losing the handful of people actually using it seriously and caring about it.

Instead of focusing on imagers devs seem to be focusing on eventual users who only use the tool once a month for scaling some photos and remove red eyes or making banners for online forums.

If that's the audience you care about, please amend the product vision so people like me can move on, since there is no future for us with GIMP. Eventual users and clueless people can learn. It only takes education.
Aiming low with features like this only makes us, the real audience, want to run in the opposite direction.

Gez.

On 06/04/2016 04:25 AM, Gez wrote:

The most pressing issues (like performance and quality) are constantly postponed. But hey, we have a new dark theme and new icons.

We have these because there are people interested in them and contributing to GIMP.

I'm not going to tell them to stop doing this. You?

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

Hi Gez.

Gez (listas@ohweb.com.ar) wrote:

Although I share your shock, I think Michael is right. Almost nobody using GIMP understands color management, because there is virtually nobody using GIMP seriously, and probably nobody will because of this kind of design decisions.

[...]

Instead of focusing on imagers devs seem to be focusing on eventual users who only use the tool once a month for scaling some photos and remove red eyes or making banners for online forums.

I don't understand your line of reasoning. Did you realize, that Mitch has literally spent months to make color management actually work in Gimp - i.e. cut'n'paste between images with different color profiles attached, color managed color selectors etc. pp.

And now all this work is jeopardized, because he made a preferences option to disable this stuff a little bit more visible? And we seem to have troubles in finding a correct way to describe what this toggle button does?

If this is your line of reasoning, then, sir, your priorities are messed up.

Bye,
Simon

simon@budig.de              http://simon.budig.de/

On Sat, Jun 4, 2016 at 5:25 AM, Gez wrote:

I'm one of the few guys around using GIMP professionally in the field of graphic design, and with each decision like this one, pointing to the wrong audience (not the audience defined in the "product vision") I'm becoming less and less convinced that it is a good idea to keep using it.

Would you like to talk about the issue in hand rather than go around bashing developers without providing useful insights?

The most pressing issues (like performance and quality) are constantly postponed. But hey, we have a new dark theme and new icons.

This is ridiculous.

People who work on themes and icons are not the same people who work on e.g. color management. C'mon, Gez, you've been around for long enough to know that.

Alex

El sáb, 04-06-2016 a las 10:07 +0200, Michael Schumacher escribió:

On 06/04/2016 04:25 AM, Gez wrote:

The most pressing issues (like performance and quality) are constantly
postponed. But hey, we have a new dark theme and new icons.

We have these because there are people interested in them and contributing to GIMP.

I'm not going to tell them to stop doing this. You?

Of course not, but take a quick look at the GIMP mailing lists archives and see how much attention got that minor subject and how much attention other important subjects receive.

That speaks volumes about the priorities of the project. Why is it the goal of GIMP 2.10 to produce a GEGL-based version with feature parity with the current stable? Why is legacy support so important? where are the users saying that their work will suffer if you move from sRGB compositing to linear compositing?

So no, I'm not going to tell anybody to stop doing what they are doing. I'm not the one who has to set your priorities, it's you. 

Is it your priority to produce a great image manipulation software? Then give imagers the tools they need.

Gez.

El sáb, 04-06-2016 a las 11:04 +0200, Simon Budig escribió:

I don't understand your line of reasoning. Did you realize, that Mitch
has literally spent months to make color management actually work in Gimp - i.e. cut'n'paste between images with different color profiles attached, color managed color selectors etc. pp.

And now all this work is jeopardized, because he made a preferences option to disable this stuff a little bit more visible? And we seem to
have troubles in finding a correct way to describe what this toggle button does?

If this is your line of reasoning, then, sir, your priorities are messed up.

I couldn't care less about what the toogle does. It's secondary. The problem here is the motivation for including such toggle.
No serious imager would think about turning CM off. Introducing that toggle is producing a feature that is not needed by the supposed audience of the tool.

And it's not only that. What resulted from this discussion is even more concerning. Like this claim for instance:

"And then we have this "even without a profile, pixels have some meaning. And in GIMP, the default meaning is sRGB."

That's absolutely wrong. Without a colorspace definition, pixels ARE meaningless.
RGB is just 3 colored lights. The value of an RGB pixel is only light intensity (from no intensity to max) and has no information whatsoever about the color of each primary.

In GIMP the default meaning is sRGB because it was decided that RGB means sRGB. So when CM is off you're not treating those pixels as pixels, you're treating them as sRGB. Because of GEGL, GIMP expect them to be sRGB. So CM converts them to sRGB anyway, no CM treats them as sRGB anyway.

That's what Elle has been fighting against for a long time, and that's still the problem.

The CM or no-CM discussion only uncovers this issue once again. GIMP 2.9 is still a sRGB editor, assuming sRGB everywhere. Again, GIMP provides something that is enough for the wrong audience, but clearly inadequate and insufficient for the supposedly intended audience.

G.

El sáb, 04-06-2016 a las 14:22 +0300, Alexandre Prokoudine escribió:

On Sat, Jun 4, 2016 at 5:25 AM, Gez wrote:

I'm one of the few guys around using GIMP professionally in the field
of graphic design, and with each decision like this one, pointing to
the wrong audience (not the audience defined in the "product vision")
I'm becoming less and less convinced that it is a good idea to keep using it.

Would you like to talk about the issue in hand rather than go around bashing developers without providing useful insights?

Do you think that my e-mail didn't provide any useful insights? Read again. I think that, despite the apparent angry tone, it says a couple of things about taking care of your audience and making decisions for them, not for the wrong people.

We can tal about that anytime.

People who work on themes and icons are not the same people who work on e.g. color management. C'mon, Gez, you've been around for long enough to know that.

Sure, but that's not the point. I'm not charging against the guys who made the themes. I'm questioning that the development community seems to pay more attention to those secondary things rather than focusing on the real shit.

G.

On Sat, Jun 4, 2016 at 6:00 PM, Gez wrote:

Of course not, but take a quick look at the GIMP mailing lists archives and see how much attention got that minor subject and how much attention other important subjects receive.

That speaks volumes about the priorities of the project.

That speaks nothing about priorities. Most discussions on development take place on IRC, and those discussions are about all sorts of dev efforts. Which you are well aware of, because you are on that channel and you participate in those discussions. I have logs proving that.

So why don't you take one step back and re-evaluate your claims?

Personally, I'm fine with a rant that has helpful bits of information in it that could be extracted. All I can extract from your rant is that you are annoyed so much that you post knowingly false information. How does it help us make GIMP better?

Why is it the goal of GIMP 2.10 to produce a GEGL-based version with feature parity with the current stable?

Where did you even read this?

Alex

El vie, 20-05-2016 a las 14:37 -0400, Jason van Gumster escribió:

Elle Stone wrote:

I can't think of a single use case for trying to edit a non-color- manged 
image in an ICC profile color-managed editing application such as GIMP.

I think I can think of one: creating displacement/bump maps (often used as
textures in 3D graphics). Often in that case, pixel values aren't treated as
color, but a numeric non-color data (i.e. it's an instruction to displace
geometry---or other pixels---by this numeric mapping value).

But perhaps the artists that create these maps are not covered in the audience
specified in GIMP's vision statement.

  -Jason

If pixel values aren't supposed to be treated as color, then they shouldn't go through any color operation. I mean, no operation should turn your RGB data to XYZ, LCH or whatever. In GIMP, GEGL operations decide when that happens, so your pixels are likely to be treated like color anyway and the no-color management option in this case wouldn't make any difference.

As Alex mentioned, the artists who create those maps are not necessarily excluded from the target audience, but GIMP doesn't provide the tools for editing such maps, and it will always treat them as sRGB (which means that CM on or off won't make any difference).

Gez.

On Sat, Jun 4, 2016 at 6:24 PM, Gez wrote:

Do you think that my e-mail didn't provide any useful insights?

It had zero technical information, only a rant. Why don't _you_ re-read it?

People who work on themes and icons are not the same people who work on e.g. color management. C'mon, Gez, you've been around for long enough to know that.

Sure, but that's not the point.

No, it _is_ the point. There a ca. 1K people subscribed to this list, and very few of them are actual contributors. I suspect most of them are just genuinely interested in what's going on and provide their input when they feel it's necessary. Sure, you can judge the whole community by that, but how sensible of an idea that would be is anyone's guess.

I'm not charging against the guys who made the themes. I'm questioning that the development community seems to pay more attention to those secondary things rather than focusing on the real shit.

Like I said, you well aware of the fact that most discussions take place on IRC.

Alex

El sáb, 04-06-2016 a las 18:26 +0300, Alexandre Prokoudine escribió:

 
Personally, I'm fine with a rant that has helpful bits of information in it that could be extracted. All I can extract from your rant is that you are annoyed so much that you post knowingly false information.

What "knowingly flase information"?

How does it help us make GIMP better?

Hopefully making people involved take one step back and re-evaluate how they are addressing the target audience's needs.

Why is it the goal of GIMP 2.10 to produce a GEGL-based version with
feature parity with the current stable?

Where did you even read this?

Oh, come on! You say you never heard that? That the linear mode was a side effect from switching to GEGL, that some features like that weren't supposed to be in 2.10 as the minimum goal was producing a GEGL version of the 2.8 features, and anything else would be a plus?
Iirc it was in the context of the first discussion about color management (supporting other colorspaces than just sRGB). And iirc it sounded as a pretext for kicking it to the future roadmap. I don't have a link to a ml thread or an IRC log, so you'll have to take my word.

G.

On Sat, Jun 4, 2016 at 6:17 PM, Gez wrote:

That's what Elle has been fighting against for a long time, and that's still the problem.

Fighting? Against? This is a community project. We don't fight here, we make stuff happen. Althought it looks like you really, really want to fight.

"Support for RGB working spaces other than sRGB" is already in the roadmap, which one might attribute to Elle's eloquence.

May I ask you why you chose this fine Saturday to unleash your frustration of world's imprfection to this particular public mailing list?

Alex

On Sat, Jun 4, 2016 at 6:52 PM, Gez wrote:

El sáb, 04-06-2016 a las 18:26 +0300, Alexandre Prokoudine escribió:

Personally, I'm fine with a rant that has helpful bits of information in it that could be extracted. All I can extract from your rant is that you are annoyed so much that you post knowingly false information.

What "knowingly flase information"?

How does it help us make GIMP better?

Hopefully making people involved take one step back and re-evaluate how they are addressing the target audience's needs.

Probably 90% of commits are done by a single person who is already overworked. What re-evaluation are you talking about? Is this discussion for real?

Why is it the goal of GIMP 2.10 to produce a GEGL-based version with
feature parity with the current stable?

Where did you even read this?

Oh, come on! You say you never heard that?

And you are asking me what knowingly false information you posted? How about this bit above?

Sorry, but the way things are going, I don't see this conversation leading to anything positive.

If you have a clear vision, how color management should work in GIMP, please share it.

If you are concerned about new menu options and you think that should do different things, please tell us exactly what they should do or say.

If you are concerned about core CM features, tell us what they should or should not do, exactly.

But if you expect to be listened to and taken seriously, don't start the conversation with this sort of a rant.

Alex

On Sat, Jun 4, 2016 at 8:11 PM, Elle Stone wrote:

And you are asking me what knowingly false information you posted? How about this bit above?

Gez hasn't posted any false information.

He has.

His choice of comparing attention to themes with attention to the big picture regarding the direction GIMP has taken with respect to the needs of people using high end workflows was a bit unfortunate (the new themes are very nice and also the result of a lot of work from people who don't normally write code for GIMP). But I 100% understand and share his frustration.

I get that.

The new menu items shouldn't do or say anything. They should be removed.

Including softproofing?

Alex

On Sat, Jun 4, 2016 at 9:04 PM, Elle Stone wrote:

On 06/04/2016 01:50 PM, Alexandre Prokoudine wrote:

Including softproofing?

Of course not.

Given the tensions, we are not in a situation where "of course I meant something entirely different" is a sensible approach to a conversation.

2. "File/New/Color manage this image". Unchecking this option does NOT disable color management, but merely assigns the GIMP built in sRGB profile to the image, which is already the default color profile for new images.

Supposing the option was renamed to be more explicit about what it does, would it still bother you?

Is this rather sidewise-seeming question a ploy to draw attention away from more important issues that Gez is trying to draw attention to?

Thank you for testing my patience with annoying, misplaced questions. It's precisely what I need on a fine Saturday night.

Namely the
fact that GIMP is morphing into an image editor that won't serve the needs of the target audience outlined in the GIMP vision statement?

Have faith, Elle.

Alex

On Sat, Jun 4, 2016 at 8:11 PM, Elle Stone wrote:

If you have a clear vision, how color management should work in GIMP, please share it.

1. Get rid of the babl flip code and attendant linear vs "gamma" precision code. Rip it completely out of babl, GEGL, and GIMP. I wrote a patch for this back in 2014, and I'd be happy to write a new patch for today's code base.

2. Apply my patches for allowing to edit in any well-behaved user-chosen RGB working space.

A start on the above two items is available from my github clones of babl/GEGL/GIMP: https://github.com/ellelstone

I vaguely recall design issues with your former proposals, but I for one would welcome a technical review for your patchset.

Alex

Elle Stone wrote:

On 05/20/2016 02:37 PM, Jason van Gumster wrote:

Elle Stone wrote:

I can't think of a single use case for trying to edit a non-color-manged image in an ICC profile color-managed editing application such as GIMP.

I think I can think of one: creating displacement/bump maps (often used as textures in 3D graphics). Often in that case, pixel values aren't treated as color, but a numeric non-color data (i.e. it's an instruction to displace geometry---or other pixels---by this numeric mapping value).

But perhaps the artists that create these maps are not covered in the audience specified in GIMP's vision statement.

In point of fact, the new GIMP color management options do NOT disable ICC profile color management.

If you want to disable color management, go into "Edit/Preferences/Color Management" and for "Image display mode" select "No color management".

Or you can achieve the same effect by assigning your monitor profile to the image file.

And that's all well and good, but either my ignorance is showing or this is starting to sound like a case of semantics. I wasn't asking for the process of how one might go about editing a non-color-managed image in a color-managed application like GIMP. I was simply pointing out that there *is* at least one use case for doing so.

As for the mechanics of actually doing this, you've pointed out a couple ways to go about it (though disabling color management for the entire application feels excessive). When working on these kinds of images---er, *maps*---aside from numeric accuracy of the actual values, the priority when editing is being able to see as much of the full range as possible, with even proportion between values. To that end, temporarily assigning the monitor's color space to the map is probably the best approach, I think.

That said, this does get me thinking and wondering a bit (though still tangentially on-topic). A few GIMP filters such as Depth Merge, Lighting Effects, Bump Map, and Displace rely on these kinds of maps. So technically, you could have a color managed image that includes one or more of these maps on separate layers. Ideally, it would be nice to be able to reliably edit those layers as non-color maps without splitting them into different images with their own independent "non"-color space.

How would you propose that GIMP handle color management in that case? In Blender's compositor, for example, there's an option to explicitly set an input image node to be interpreted as non-color data. Would it make sense to offer that kind of option to individual layers in GIMP? If that doesn't make sense, what's an alternative approach that *does*?

Thanks.

Jason

Gez wrote:

...GIMP doesn't provide the tools for editing such maps...

Maybe I'm simply not understanding. Typically these kinds of maps get edited with color curves, layer blending modes (straight-forward mathematical ones like multiply, add, and subtract are most intuitive), and painting. How does GIMP not provide these tools?

I'm sure I'm missing something obvious here. If you could explain what you mean, I'd be most appreciative.

Thanks.

-Jason

On Sat, 4 Jun 2016, Elle Stone wrote:

Keep in mind that many "don't know/don't want to know" users do manage to use high end software like PhotoShop, Krita, and Blender without the software being hampered by training wheels, belts and suspenders.

To be honest... We get a lot of feedback like "Where can I disable color management, it's too complicated, I don't want this, why should I want this, Paintool Sai doesn't have it, it makes my images weird in firefox, you guys suck".

Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

On Sat, 4 Jun 2016, Elle Stone wrote:

On 06/04/2016 05:28 PM, Boudewijn Rempt wrote:

To be honest... We get a lot of feedback like "Where can I disable color management, it's too complicated, I don't want this, why should I want this,
Paintool Sai doesn't have it, it makes my images weird in firefox, you guys suck".

Tell them to choose sRGB as the monitor profile and the image profile. Problem solved. In GIMP they can use the built-in sRGB profile as the monitor profile by choosing "None".

That's what we do -- it just doesn't work! People can get incredibly angry at learning that they have some learning to do.

Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

On Sat, Jun 4, 2016 at 11:13 PM, Elle Stone wrote:

If GIMP is being developed for high end workflows as specified in the Vision statement, then it's important to get input from people who actually use high end workflows. Gez is exactly such a person. I think I qualify, though I'm not a professional.

High-end workflows doesn't have to mean that the user understands all details about things like color-management, some things can be handled automatically - note that this is not about making it impossible to do things; but harder to do the wrong thing.

I've had a small number of high end users including two bonified professionals from very different fields look at both default GIMP and my patched GIMP which has the babl flips disabled. Unanimously these people say that there is no way they would use default GIMP because the babl flips interfere with their workflow. Plus they need the option to work in wider color spaces than sRGB. But they liked using my patched GIMP.

snip<

Let's be completely clear about this: These high end users and professionals aren't praising *my* coding ability or *my* vision for GIMP. I'm a terrible coder and all I've done in my patched GIMP is disable the babl flips, add a few extra LCH functionalities, and recently added "anyrgb".

One of the important features of the "babl flips" is that they make gamma erros as they apply to scaling and blurring, and more go away see http://www.4p8.com/eric.brasseur/gamma.html GEGL code in general prefers using linear variants of the used RGB color-space for processing (and compositing). One major short-coming of babl/GEGL color handling currently - as elle has pointed out, is for operations that multiply pixels values - like the multiply layer mode - most editing features in GIMP do not rely on multiplication of color components.

At the moment things are a mix of constraints of 8bit like GIMP-2.8 had and how closely workflows from 2.8 are reproducible in the development version, some features and menu options in GIMP-2.9 are not desirable as a finished streamlined GEGL based editing experience. After GIMP-2.10 and GIMP-3.0 get released; I hope we can see a significant trimming down of the UI for instance the precision menu in GIMP, defaulting to 32bit floating point with linear TRC (maybe with precision over-ridable per layer - to save memory) in addition to other improvements that might break more GIMP-2.8 era assumptions and constraints. This is also when experimenting with filters embedded in the layer stack similar to adjustment layers/effect layers and more is on the roadmap.

Elles simplified babl/GEGL with removed the TRC to/from linear conversions or as she calls it "babl flips" will make GIMP produce wrong results for scaling, blurring and more - *unless* the user has specifically chosen to edit in a linear RGB space; only then will scaling or blurring and other resampling produce correct results. Another issue not dealt with by Elles approach to patching babl/GEGL is juggling multiple immutable different RGB formats in one process. GIMP can open multiple images with different ICC profiles - and we want users to be able to predictably view and copy/paste between multiple images with different profiles. How this is dealt with isn't certain - some ideas have gone into a babl roadmap, but the needs are summed up in this email.

I see it as important to get a working 2.10 released, what we currently have in git is better than GIMP-2.8 in most ways. More important than to perfect it so that we start the work on making a GIMP using GTK3 in master - as well as adding more advanced non-destructive features based on GEGL after 3.0. With GIMP 2.10 and 3.0 maybe there will be an influx of interest from developers or sponsorship and I have the motivation to properly add such capabilities to babl myself - for now I am the janitor/maintainer of GEGL - making sure also not to break expectations other software have from it - enjoy some goats https://www.youtube.com/watch?v=GJJPgLGrSgc

/pippin

On Sun, Jun 5, 2016 at 1:16 AM, Elle Stone wrote:

If GIMP is being developed for high end workflows as specified in the Vision
statement, then it's important to get input from people who actually use high end workflows. Gez is exactly such a person. I think I qualify, though
I'm not a professional.

High-end workflows doesn't have to mean that the user understands all details about things like color-management,

Practical, applied color management is not that complicated. Neither is understanding the basics of radiometrically correct editing.

Most people - including people doing photography and graphic design work for a living - prefer not to. I used to teach people becoming such professionals at a university level. It should also be possible to use GIMP for color scientists and color science geeks that care more about color accuracy control than image composition.

A professional high end workflow by definition implies that the user understands the nature of the provided tools, what the tools can do and what the limitations are.

Or the tools provide professional level outputs; tools for digital media manipulation are abstractions - and a professional should be able to use tools without knowing how to reimplement the tools.

some things can be handled
automatically - note that this is not about making it impossible to do things; but harder to do the wrong thing.

As an experiment, I tried using default babl/GEGL/GIMP patched to use Rec.2020 Y and XYZ, but with the babl flips intact and using an ICC profile with the Rec20202 primaries and the sRGB TRC.

I had no way to know, short of looking in the code, which operations were being done on linearized RGB, and which on perceptually uniform RGB.

Well, sometimes it was obvious. For example GIMP by default uses perceptually uniform RGB for Curves and Levels, and this is radiometrically incorrect and produces all kinds of obvious gamma artifacts.

These are bugs.

I know exactly when I want to use linear RGB and exactly when I want to use perceptually uniform RGB, as do other high end/professional users.

Maybe not, professional photographers might not know that they want pre-multiplied alpha, linear light data for doing resampling, nor what goes wrong if the pixel data for some reason isn't pre-multiplied or linearized, providing constraints that makes such misconfiguration hard is a service to novice and professional user alike.

The babl flips take that critically important freedom of choice away from me.

I've had a small number of high end users including two bonified professionals from very different fields look at both default GIMP and my patched GIMP which has the babl flips disabled. Unanimously these people say
that there is no way they would use default GIMP because the babl flips interfere with their workflow. Plus they need the option to work in wider color spaces than sRGB. But they liked using my patched GIMP.

snip<

Let's be completely clear about this: These high end users and professionals
aren't praising *my* coding ability or *my* vision for GIMP. I'm a terrible
coder and all I've done in my patched GIMP is disable the babl flips, add a
few extra LCH functionalities, and recently added "anyrgb".

One of the important features of the "babl flips" is that they make gamma erros as they apply to scaling and blurring, and more go away see http://www.4p8.com/eric.brasseur/gamma.html GEGL code in general prefers using linear variants of the used RGB color-space for processing (and compositing).

One of the professionals who has used my patched GIMP (actually there were three professional that I know of, I don't usually ask people who send me emails what they do for a living, but sometimes they tell me anyway) has specifically noted that for scaling an image to a larger size, scaling perceptually uniform RGB can provide a smoother result. And the babl flips take this option away from users of default GIMP.

This points to a shortcoming in the "make all the decisions for the user" approach to coding: It assumes the devs know better than the users what is the right thing to do.

We make decisions for the user, in what capabilities are included, and where menu items are. To return to the topic of this thread; the decision to make it easy to "assume all settings as sRGB" temporarily, and then flip back to the custom perhaps misconfigured settings is another such service realising that not all operators of the software know or care as deeply about ICC workflows as you do.

One major short-coming of babl/GEGL color handling currently - as elle has pointed out, is for operations that multiply pixels values - like the multiply layer mode - most editing features in GIMP do not rely on multiplication of color components.

Well, actually many editing operations in GIMP are chromaticity-dependent, producing different results in different RGB working spaces, precisely because multiply itself is chromaticity-dependent.

For a list see Section B of this article: http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html#chromaticities-matter.

For editing examples, see Section C of the same article.

For a more technical discussion, see these three articles:

Multiplying out of gamut colors in the unbounded sRGB color space produces meaningless results
(http://ninedegreesbelow.com/photography/unbounded-srgb-multiply-produces-meaningless-results.html)

Color correction fails in unbounded sRGB (http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html)

About RGB Colourspace Models Performance (http://colour-science.org/posts/about-rgb-colourspace-models-performance/)

And this thread: https://www.freelists.org/post/argyllcms/White-Point,45

Why did you "well actually me" and repeat all of the above? I acknowledge this short-coming, and that it is something we want to work on and that you are the one that have convinced me and other developers of this need. I am not re-starting or reiterating this argument, I am, as I have repeatedly done - acknowledge that this is a short coming of the current architecture that needs remedying, but your way of remedying it break other expectations of software using GEGL.

At the moment things are a mix of constraints of 8bit like GIMP-2.8 had and how closely workflows from 2.8 are reproducible in the development version, some features and menu options in GIMP-2.9 are not desirable as a finished streamlined GEGL based editing experience.

This is exactly what Gez was saying: there are constraints on GIMP 2.10 for legacy/backward-compatibility reasons.

After GIMP-2.10 and GIMP-3.0 get released; I hope we can see a significant trimming down of the UI for instance the precision menu in GIMP, defaulting to 32bit floating point with linear TRC (maybe with precision over-ridable per layer - to save memory) in addition to

It would be excellent to have default 32f *linear* *gamma* processing (no babl flips to perceptually uniform RGB behind the user's back and without their consent), preferably coupled with a "per layer/layer group" user option to choose a perceptually uniform TRC. Otherwise the user needs the option to convert to a profile with a user-chosen TRC, and of course the user needs this option anyway, and again with *no* *babl* *flips*.

If the babl flips are flipping the RGB channels back and forth between linear and perceptually uniform RGB without the *user* being able to control the encoding, this is a design decision that precludes using high bit depth GIMP for high end/professional workflows.

There is also flipping to/from formats with alpha. Pre-multiplied and non-premultiplied alpha. As well as flips to/from higher and lower bit-depths as well as to/from CIE Lab. By necessity of the operations involved, working on linear data is another one of these constraints that should be fulfilled. Whenever possible the developer/designer of image processing algorithms should be burdened with reducing the number of parameters, as well as sticking with good defaults - making efficient work-flows possible. If you continue calling it "babl flips" I will start calling your non-flipping-babl a lobotomized babl - you could also collapse "RaGaBaA float" into "RGBA float" along with "R'G'B'A float" to make babl even less capable of providing internal color / pixel-representation management for GEGL and thus GIMP and other applications using GEGL. Before scaling or blurring an image a user would then have to run a pre-multiply filter and after-wards un-premultiply filter.

other improvements that might break more GIMP-2.8 era assumptions and constraints. This is also when experimenting with filters embedded in the layer stack similar to adjustment layers/effect layers and more is on the roadmap.

Elles simplified babl/GEGL with removed the TRC to/from linear conversions or as she calls it "babl flips" will make GIMP produce wrong results for scaling, blurring and more - *unless* the user has specifically chosen to edit in a linear RGB space; only then will scaling or blurring and other resampling produce correct results.

Exactly and by design. The user needs control over their RGB data.

Another issue not dealt with by Elles approach to patching babl/GEGL is juggling multiple immutable different RGB formats in one process. GIMP can open multiple images with different ICC profiles - and we want users to be able to predictably view and copy/paste between multiple images with different profiles. How this is dealt with isn't certain - some ideas have gone into a babl roadmap, but the needs are summed up in this email.

Well, let's see how this might be handled:

First the user picks the color space for compositing the image layers together.

Then the user drags the layers over from other image layer stacks, and if the source and destination layer stacks are in different ICC profile color spaces, a conversion is done during the drag and drop operation (which Mitch already added code to make happen).

Problem solved.

Oh, if "predicatably view" means "always get the same result from all compositing operations", then the developer must command and enforce that the user can only composite in a working space that the developer has a priori chosen, precisely because multiply is a chromaticity-dependent editing operation that affects a multitude of editing operations and blend modes.

High end work flows absolutely require that the user be in control of the compositing color space.

If the consensus among the devs (the devs that control the overall course of GIMP development) is that GIMP is for "don't know and don't want to know" users, then please revise the Vision statement accordingly, and feel free to keep those babl flips.

Revising the Vision statement would clarify the nature of the project on which we are all working as a team, and perhaps some of us would choose to not continue participating in GIMP development. I believe this is one of the points that Gez was making when he said:

And if things keep going in this direction, GIMP will end up losing the handful of people actually using it seriously and caring about it.

Instead of focusing on imagers devs seem to be focusing on eventual users who only use the tool once a month for scaling some photos and remove red eyes or making banners for online forums.

If that's the audience you care about, please amend the product vision so people like me can move on, since there is no future for us with GIMP. Eventual users and clueless people can learn. It only takes education.
Aiming low with features like this only makes us, the real audience, want to run in the opposite direction.

Some of the developers do care about on-boarding of new users and making the experience of using the tool that GIMP is fluid for both novices that haven't done any image manipulation before as well as experts; all operators have to start somewhere; this means being thoughtful of both defaults and automatic behaviour.

These email threads makes me want to stop volunteering my time, I am sad that over the last couple of years the many hundreds of hours I have spent on babl/GEGL/GIMP - a too large portion of them have been in anger dealing with long email tirades spat out at an alarming rate. You have repeatedly been invited to turn up at libre graphics meeting; our annual in person meet-up - with travel expenses covered, where both professional users are present, and more GIMP developers can participate without having to read books worth of email (as well as additional books to understand the disagreements in those email threads.).

I consider babl/GEGL feature complete for a 2.10 release of GIMP, and am only intending to incorporate small patches and do semi-periodic snapshot releases for the benefit of GIMP / GNOME photos / imgflo / gedl / gnome-scan until after GIMP-3.2 development starts. If I had more time or energy; I would've focused on improving the mipmap preview code in GEGL/GIMP, so that the on-canvas preview of both layers composition and live filters on huge images would be faster - but those are things that maybe can be picked up on in GIMP-3.0 as well.

/pippin - maintainer of babl/GEGL

El dom, 05-06-2016 a las 09:26 +0200, Øyvind Kolås escribió:

 

Practical, applied color management is not that complicated. Neither is
understanding the basics of radiometrically correct editing.

Most people - including people doing photography and graphic design work for a living - prefer not to. I used to teach people becoming such professionals at a university level. It should also be possible to use GIMP for color scientists and color science geeks that care more about color accuracy control than image composition.

That should come endorsed by a professional photographer or designer saying she doesn't care about color management. We can assume that the silence is because nobody cares. But there is also a fat chance that there aren't many of those professionals around here.

It's also possible that many future professionals at university level truly don't care, because they weren't taught about the importance and influence of color management in their work. I know that was the case with me. The quality of my work improved substantially after I understood the basics of color management. "just works" for most of the people means "I don't have to care about that" and that's a huge mistake.

I do graphic design work for a living, and for ideological reasons I chose to do it with free software. I do care about proper color management because I know how doing it wrong degrades and limits the quality of my work.

I know exactly when I want to use linear RGB and exactly when I want to use
perceptually uniform RGB, as do other high end/professional users.

Maybe not, professional photographers might not know that they want pre-multiplied alpha, linear light data for doing resampling, nor what
goes wrong if the pixel data for some reason isn't pre-multiplied or linearized, providing constraints that makes such misconfiguration hard is a service to novice and professional user alike.

snip

There is also flipping to/from formats with alpha. Pre-multiplied and non-premultiplied alpha. As well as flips to/from higher and lower bit-depths as well as to/from CIE Lab. By necessity of the operations involved, working on linear data is another one of these constraints that should be fulfilled. Whenever possible the developer/designer of image processing algorithms should be burdened with reducing the number of parameters, as well as sticking with good defaults - making efficient work-flows possible. If you continue calling it "babl flips"
I will start calling your non-flipping-babl a lobotomized babl - you could also collapse "RaGaBaA float" into "RGBA float" along with "R'G'B'A float" to make babl even less capable of providing internal color / pixel-representation management for GEGL and thus GIMP and other applications using GEGL. Before scaling or blurring an image a user would then have to run a pre-multiply filter and after-wards un-premultiply filter.

The fully automatic choice of alpha association is not always the best way to go.
Sure, there are many documented cases where you know exactly what's the most adequate association, but then there are also cases (which are not corner cases at all) that completely fall apart with an automatic selection.
For instance, take an EXR file with luminescent transparent pixels. That's a perfectly valid case that is used extensively in VFX to composite fire, light effects and any kind of emissive phenomena that produce light but don't occlude light from the background. It's important to note that what I mention is not a hack used by artists at all. It's a valid alpha compositing situation described both in the original porter-duff paper and the EXR specs. If you feed that data to a program that decides a strategy of alpha association, the most probable outcome is that the information in pixels with zero alpha is discarded. There is an infamous thread at Adobe Forums that had the most renowned imagers ranting about how Photoshop was screwing image data because programmers decided for users and made assumptions.

That's why it's important to know what artists will do with your software before making such assumptions. I'm not saying that every single option in a graphics program should come with a toggle, but you can't choose for users if you don't know what they need.

G.

On Sun, Jun 5, 2016 at 5:14 PM, Gez wrote:

El dom, 05-06-2016 a las 09:26 +0200, Øyvind Kolås escribió:

Practical, applied color management is not that complicated. Neither is
understanding the basics of radiometrically correct editing.

Most people - including people doing photography and graphic design work for a living - prefer not to. I used to teach people becoming such professionals at a university level. It should also be possible to use GIMP for color scientists and color science geeks that care more about color accuracy control than image composition.

That should come endorsed by a professional photographer or designer saying she doesn't care about color management. We can assume that the silence is because nobody cares. But there is also a fat chance that there aren't many of those professionals around here.

It's also possible that many future professionals at university level truly don't care, because they weren't taught about the importance and influence of color management in their work. I know that was the case with me. The quality of my work improved substantially after I understood the basics of color management. "just works" for most of the people means "I don't have to care about that" and that's a huge mistake.

I do graphic design work for a living, and for ideological reasons I chose to do it with free software. I do care about proper color management because I know how doing it wrong degrades and limits the quality of my work.

I am not saying that there should be no ability to do color management - or that it is worthless. I have been doing color science research as well as been teaching bits of color reproduction knowledge. I am saying that expecting a user to understand color management before being able to do decent work with GIMP and its user interface is unreasonable. Just like a good photographer beats a bad one with an expensive camera; detailed knowledge of color management and pixel representation is secondary to other skills in producing quality photos.

mitch manages ignore the mailinglist and stay productive - astonishing given the level of distraction here on gimps mailinglist.

/pippin

On Sun, Jun 5, 2016 at 5:14 PM, Gez wrote:

There is also flipping to/from formats with alpha. Pre-multiplied and non-premultiplied alpha. As well as flips to/from higher and lower bit-depths as well as to/from CIE Lab. By necessity of the operations involved, working on linear data is another one of these constraints that should be fulfilled. Whenever possible the developer/designer of image processing algorithms should be burdened with reducing the number of parameters, as well as sticking with good defaults - making efficient work-flows possible. If you continue calling it "babl flips"
I will start calling your non-flipping-babl a lobotomized babl - you could also collapse "RaGaBaA float" into "RGBA float" along with "R'G'B'A float" to make babl even less capable of providing internal color / pixel-representation management for GEGL and thus GIMP and other applications using GEGL. Before scaling or blurring an image a user would then have to run a pre-multiply filter and after-wards un-premultiply filter.

The fully automatic choice of alpha association is not always the best way to go.
Sure, there are many documented cases where you know exactly what's the most adequate association, but then there are also cases (which are not corner cases at all) that completely fall apart with an automatic selection.
For instance, take an EXR file with luminescent transparent pixels. That's a perfectly valid case that is used extensively in VFX to composite fire, light effects and any kind of emissive phenomena that produce light but don't occlude light from the background. It's important to note that what I mention is not a hack used by artists at all. It's a valid alpha compositing situation described both in the original porter-duff paper and the EXR specs. If you feed that data to a program that decides a strategy of alpha association, the most probable outcome is that the information in pixels with zero alpha is discarded. There is an infamous thread at Adobe Forums that had the most renowned imagers ranting about how Photoshop was screwing image data because programmers decided for users and made assumptions.

That's why it's important to know what artists will do with your software before making such assumptions. I'm not saying that every single option in a graphics program should come with a toggle, but you can't choose for users if you don't know what they need.

babl being able to deal with pre-multipled/associated and non-premultiplied / non-associated alpha/transparency and know if a buffer contains one or the other is a neccesary for being able to make the choice of doing things automatically or not in GEGL/GIMP ; remove this capabilitity from babl - like removing the capability to request RGB data in a linear variant of the used RGB color space, removes the ability to deal with thing automatically and requires full manual control by the operator.

/pippin - digital media artist and toolsmith

On Sun, Jun 5, 2016 at 3:48 AM, Elle Stone wrote:

On 06/04/2016 02:21 PM, Alexandre Prokoudine wrote:

Supposing the option was renamed to be more explicit about what it does, would it still bother you?

Making color management "disappear" for users who prefer to not ever think about color management (very different from "disable color management") is not such a bad goal, though the new image/color management options don't (imho) accomplish this goal.

Maybe try something along these lines?

Put a user option in Preferences/Color Management that says "Check this box if you really don't want to ever be bothered with color management." Write an explanation that says something like:

snip<

If you check this box, the following will happen:

1. sRGB will be used as your monitor profile. If your monitor has an sRGB emulation mode, please enable it.
(Perhaps add additional options for users who don't want to think about color management but do have a monitor or installed system profile that they want GIMP to use).

2. All color management options will be grayed out in the UI.

Such graying out is a good idea; all of this code is unfinished code that mitch is currently working on, combined with graying out as well as setting the title of the titleboxes to the name of the internal sRGB profile - I think a short text of "Assume sRGB for all profile settings" might be sufficient for such a check--box, if that is the direction GIMP choses to take on this issue.

3. All imported images will automatically be converted to sRGB for editing. You won't have to think about this. It will just happen.

For some people this might not be what they desired though; they might have desired assignment of sRGB rather than conversion to sRGB - to preserve numeric values; thankfully for sRGB images those actions would have the same result.

4. Your XCF files will be automatically saved in the sRGB color space.

5. All exported images will be exported as untagged sRGB images. (Perhaps add an option to embed an sRGB profile from disk for users who are aware of how Firefox default color management settings. Though this might be "too much information" as they would also need to know the difference between what makes sense for UI elements in web design, vs what makes sense for photographic images.)

Well, it's just a thought. I get emails from people asking me how to avoid color management as much as possible, and above is pretty much the advice I give them, and they do seem to understand and follow through. They even understand the part about Firefox default color management settings once they've been given an explanation.

The goal of the setting mitch has started experimenting with is a response to similar desires users baffled by the permutation of possible misconfigurations of color management continue to express.

/pippin