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

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
___
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 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
___
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 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
___
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-05 Thread Gez

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.

___
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 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
>>

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


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

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 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: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=2=unbounded+sRGB=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

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