date:20160604


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:


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.

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


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.


Best,
Elle

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option


On 06/04/2016 12:12 PM, Alexandre Prokoudine wrote:


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?


You mean Mitch. Mitch is the heart and soul of GIMP. Without Mitch, 
where would GIMP be?


Mitch has written a *lot* of new color management code over the last 
several years, and it's excellent. I watch for new color management code 
as it's committed to git, and I try really hard to pick holes in the 
code from the point of view of "does it work", and Mitch's code works.


I don't know how many of you realize the color picking tools are now 
color-managed and the code works perfectly, except for an issue with 
colors that the user might like to pick that are outside the sRGB color 
gamut.


I certainly couldn't have written that code. In fact I tried to several 
times over the last year and made no progress at all.


I can't help but notice how much of the GIMP color management code deals 
with the switches between linearized RGB (linearized from the sRGB TRC) 
and perceptually uniform RGB (meaning the sRGB TRC).


Writing color management code would surely be easier if the babl 
flip-related code were stripped out of babl/GEGL/GIMP. I rather suspect 
a lot of the rest of the code also would be simpler to write.


Best,
Elle


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option


On 06/04/2016 05:37 PM, Øyvind Kolås wrote:

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,


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


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.



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.


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.


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.



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


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

Re: [Gimp-developer] New Image/Color Management option

2016-06-04 Thread Øyvind Kolås

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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

2016-06-04 Thread Boudewijn Rempt


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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option


On 06/04/2016 05:36 PM, Elle Stone wrote:

Tell them to choose sRGB as the monitor profile and the image profile.
Problem solved.


Oh, and set their monitor to sRGB emulation mode, if it's available.

Elle

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

2016-06-04 Thread Boudewijn Rempt


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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option


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".


Best,
Elle
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Delay with 'Lock brush size to zoom' feature enabled - 2.9.3 GIMP Git Master

2016-06-04 Thread Americo Gobbo

On Sat, Jun 4, 2016 at 6:16 AM, Michael Schumacher  wrote:

> Stroking as in stroking a path or selection, or painting?


Sorry, is painting process.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option


On 06/04/2016 12:12 PM, Alexandre Prokoudine wrote:


What re-evaluation are you talking about? Is this
discussion for real?


I think there does need to be a real and on-going discussion.

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.


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.


One comment was that my patched GIMP, and especially with the extra LCH 
functionality, felt natural to use and was an easy replacement for 
PhotoShop. A related comment was that the LCH functionalities open up 
new possibilities for digital painting.


One comment was that if my patched GIMP had one additional feature 
that's already on the GIMP roadmap - something to do with 
non-destructive ediing but I don't remember the specifics - it would be 
the preferred editing application for many high end users. Other people 
also mentioned non-destructive editing and of course adjustment layers 
and the ability to easily record and replay repetitive actions.


A comment made by a couple of people was that the unbounded floating 
point ICC profile editing was incredibly useful, something apparently 
PhotoShop and most other image editors don't support very well.


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".


These people are talking about the truly awesomely excellent work that 
*everyone* on the GIMP team has done, with Mitch doing most of the 
actual coding for GIMP. So they were complimenting all of you devs, or 
all of us devs (people keep telling me I'm one of the GIMP devs).


And speaking of vision, I never would have realized the usefulness of 
unbounded image editing, which I think is from Pippin's vision. But now 
I can't imagine going back to editing bounded RGB.


As Gez has suggested, I think the GIMP devs should start seeking out 
high end users and asking for specific concrete feedback, which is 
something I've been trying to do for the last year.


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.


Best,
Elle

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

2016-06-04 Thread Jason van Gumster


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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

2016-06-04 Thread Jason van Gumster

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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option


On 06/04/2016 02:50 PM, Elle Stone wrote:



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?


My apologies, you are referring to the New Image menu. No, there is 
absolutely no way to reword that option to make it less confusing and 
misleading.


New images by default are sRGB images unless the user explicitly chooses 
a different ICC profile for the image.


The only rewording that doesn't mislead the user is something like 
"Uncheck this option to assign the GIMP built-in sRGB profile to your 
new image."


Unchecking this option creates an image that says "not color managed" as 
the ICC profile, (even if the unsuspecting and confused user also chose 
a different ICC profile from disk).


But checking the Image Properties, the Color Profile is GIMP built-in sRGB.

And checking the displayed colors against the colors that are seen on my 
monitor when color management really is disabled confirms that color 
management isn't disabled.


How are users not going to be confused about this?

Changing the verbiage in the Image Properties is not a solution because 
in reality the image really is color-managed and it really does have the 
GIMP built-in sRGB profile assigned.


"Color managed" has a meaning. It's not a complicated meaning.

You can't make things simpler for users by trying to redefine the basic 
terms that are used by all other image editors and the entire community 
of people who use color management in their workflows. This 
"redefinition" just isn't going to accomplish anything except to confuse 
and mislead users.


Best,
Elle

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option


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

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.


OK, fair enough.




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?


The only wording that doesn't mislead the user is something like:

"Uncheck this option to assign the GIMP built-in sRGB profile to your 
image".


Which brings us back to the fact that the user already has the option to 
assign the GIMP built-in sRGB profile, using "Image/Color 
Management/Assign".


And then there is "Image/Color Management/Discard Color Profile", which 
also assigns the GIMP built-in sRGB profile.


How many ways of assigning the GIMP built-in sRGB profile need to be 
packed into the "Image/Color Management" menu?


How are all these various ways a user now has to assign the GIMP 
built-in sRGB profile going to make things easier for users to understand?





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.


My apologies, I was out of line.

Best,
Elle


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option


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

Gez hasn't posted any false information.

He has.

What false information? Can you be specific? I don't see any false 
information.


Elle
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option


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

Including softproofing?


Of course not.

Gez wasn't talking about the new soft proofing options, and neither am 
I. Gez was talking about the same options that have always been the 
subject of this particular thread, which is to say:


1. "Image/Color Management/Enable Color management".
   Unchecking this option does NOT disable color management but merely 
assigns the GIMP built in sRGB profile.
   This task can already be accomplished by going to "Image/Color 
Management/Assign Color Profile" and assigning the GIMP built-in sRGB 
profile.


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.


Is this rather sidewise-seeming question a ploy to draw attention away 
from more important issues that Gez is trying to draw attention to? 
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?


Best,
Elle

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option


On 06/04/2016 12:12 PM, Alexandre Prokoudine wrote:

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ó:



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?


I can dig out specific posts if you really want me to. But Gez is quite 
correct - the notion of "backwards compatibility" has from time to time 
received considerable mention on the gimp developers list.




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


Gez hasn't posted any false information. 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.




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.


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



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.


The new menu items shouldn't do or say anything. They should be removed. 
If a GIMP user doesn't want to deal with color management, they already 
have the option to only edit sRGB images.


Best,
Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

On 06/04/2016 11:53 AM, Alexandre Prokoudine wrote:

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.

Just to set the record straight regarding the outcome of my "eloquence":

Beginning in April 2014, and with help from several other people, I
spent an enormous amount of time and effort testing and documenting the
inadequacies of the babl architecture that uses unbounded sRGB as a
universal working space and pseudo-PCS:
http://gimp.1065349.n5.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=unbounded+sRGB&days=0

The net result of my long campaign to persuade the babl/GEGL/GIMP devs
to abandon their long-planned sRGB-only architecture is:

1. A few paragraphs in the babl roadmap:
https://git.gnome.org/browse/babl/tree/docs/roadmap.txt

2. A promise that "eventually" GIMP will support editing in color spaces
other than sRGB: http://wiki.gimp.org/wiki/Roadmap

This is a pitifully small return for the amount of effort I and others
have put into trying to turn GIMP around so it can become the amazing
image editor that it would already be if the misguided babl architecture
had been abandoned back in 2014, as it should have been.

For the foreseeable future:

* GIMP 2.9/2.10 is in fact an "unbounded sRGB only image editor":
http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html

* GIMP code is still written around the misguided notion of "sRGB as
PCS":
http://gimp.1065349.n5.nabble.com/Don-t-make-an-architectural-mistake-based-on-a-groundless-premise-td43812.html#a43875

I feel partly responsible for the current sad state of GIMP code because
in the long discussion of the babl architecture the question came up
concerning whether the babl flips should also be abandoned. I said they
could be useful. I didn't realize just how invasively they would spread
through the GIMP code base.

In retrospect, the sensible thing to do is to completely remove all
traces of the babl flips from babl/GEGL/GIMP. If this is done, then when
a person wants to edit a linear gamma image, all they have to do is
convert the image to a linear gamma ICC RGB working space. The babl
flips aren't needed for linear gamma image editing.

And then institue "per layer/layer group" ability to flip to a
user-specified TRC for the very few cases where an informed imager
really does want or need to edit nonlinear RGB.

Uninformed GIMP users would still have the option to edit in the regular
sRGB color space as they already do.

Best,
Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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.


___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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.

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option

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.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] New Image/Color Management option