Re: [Gimp-developer] GIMP should fork babl and GEGL

[Jon Nordby]

On 5 November 2014 14:50, Elle Stone  wrote:

> On 11/05/2014 08:22 AM, Jon Nordby wrote:
>
>> What you just described IS side-by-side implementations of
>> operations. In an ICC profile color-managed application, sRGB is
>> just another RGB working space. You don't need to special-case sRGB.
>>
>>
>> No it is not. There will be one implementation of say "multiply". It
>> will be able to work on any RGB color space. Including sRGB, but without
>> need for special casing.
>>
>> Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc.
>>
>> In Pippin's originally planned "unbounded sRGB architecture",
>> "bablRGB" meant "convert the image to unbounded sRGB before
>> perfoming *any* editing operation". Now the plan is that bablRGB
>> will mean "convert to unbounded sRGB for *some* operations".
>>
>>
>> The meaning of the "bablRGB" specifiers has not, and will not change.
>> The vast majority of operations will just stop using them (because they
>> have hardcoded sRGB parameters), and instead use the new specifiers, as
>> per the roadmap.
>>
>>
> For the babl code that converts an sRGB image to grayscale for use as a
> layer mask, do you plan to add a new set of functions that convert from
> UserRGB to grayscale?
>
> That code would, of course, need to pull Y values from UserRGB. Which of
> course means that the new code for UserRGB would also work for sRGB images.
>
> For the babl code that converts from color to Y for painting on a mask,
> that code currently is hard-coded to use sRGB Y values. Do you plan to add
> a new set of functions that convert from UserRGB to Y for painting on a
> mask? That code would also, of course, need to pull Y values from UserRGB.
> Which of course means that the new code for UserRGB would also work for
> sRGB images.
>
> For all the GIMP UI functions that currently use hard-coded sRGB Y values
> sprinkled through babl, GEGL, and GIMP, do you plan to add a new set of
> alternate functions that will use Y values pulled from UserRGB? Again, that
> new UserRGB code will also work for sRGB images.
>
> How is this not side-by-side implementation?
>

When I said "operations" I meant GEGL operations: There will be no
side-by-side implementation of GEGL operations.
Yes, we will have to introduce new babl color conversion functions which
handle arbitary RGB color spaces by looking up parameters from UserRGB.
Both to convert from&to grayscale and between the various RGB spaces. There
is no escaping that, as we don't have any code that can handle these cases
right now.

Whether the existing conversion functions with hardcoded sRGB parameters
for bablRGB will remain once general functions exists, is an open question.
It could be that they will just call into the general RGB color conversion
functions with the particular parameters of sRGB.
Or it could be that keeping the functions as-is has benefits that outweigh
the cost of keeping the code around, like being able to do performance
optimization tricks not possible in the general case.

What part of the latest new plan am I missing? Could you explain the
> purpose that is served by having all the functions with hard-coded sRGB
> parameters sit side by side with equivalent functions that use UserRGB
> parameters?
>
> Or are you really getting rid of *all* the hard-coded sRGB parameters? In
> which case, what is the new purpose for the bablRGB formats that "will not
> change" their meanings?

For operations which have an actual dependency on sRGB parameters, like the
previously mentioned operations emulating color blindness. Or for
interacting with (sometimes broken) operating-system/library interfaces
which expects sRGB. I don't expect it to be particularly common.
The primary reason (as I see it) for not changing the semantics of existing
specifiers is to preserve compatibility. Code outside of BABL/GEGL/GIMP
could very well be reliant on the current meaning of the bablRGB formats.



-- 
Jon Nordby - www.jonnor.com
___
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] [Gimp-user] GIMP should fork babl and GEGL

[Elle Stone]

On 11/05/2014 07:34 AM, Alexandre Prokoudine wrote:

On Tue, Nov 4, 2014 at 10:27 PM, Elle Stone wrote:


Another advantage to forking babl and GEGL for GIMP is that GIMP's fork of
babl and GEGL could be GPLed, thus freeing the GIMP devs to add FFTW
(Fourier transforms, http://www.fftw.org/) and other new functionality to
GIMP. FFTW is GPLed. At present, GIMP is somewhat hobbled as to what GPL
code can be used for new editing functions because the babl/GEGL code is
LGPLed.


Well, it's a shame we can't legally use FFTW to revive that GSoC
project, but FFTW is not the only option out there. There's e.g.
https://github.com/anthonix/ffts.

Also, as Jehan correctly stated, licensing a library under GPL opens a
whole can of worms. Just google for "libredwg gpl freecad librecad" to
see what kind of madness can happen.


I'm not exactly keen on the idea of forking babl and GEGL. Nonetheless, 
it is a legitimate question to consider much GIMP is being/might in the 
future be compromised by the needs of other projects that use babl and GEGL.


The FFTW code is a case in point. I haven't looked at the anthonix code 
and frankly I'm not enough of a mathematician to make an informed 
judgement (has any free/libre software adopted it in place of FFTW?).


There is already that google summer of code Fourier branch, and I've 
peeked into enough useful algorithms to know that GIMP users would 
benefit from having access to Fourier-based algorithms, which is useful 
even for "simple" things like a convincing lens blur and motion blur, 
and of course sharpening that goes beyond unsharp mask.


At the moment GIMP devs have way more than "enough to do" without 
worrying about Fourier-based enhancements. But it seems a shame to have 
to worry about licensing issues if/when that happy day comes when 
Fourier-based code reaches the head of the "let's do this" list.


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] [Gimp-user] GIMP should fork babl and GEGL

[Elle Stone]

On 11/05/2014 09:07 AM, Simon Budig wrote:

Elle Stone (ellest...@ninedegreesbelow.com) wrote:

Why would any sane developer want to write all the new code and have it
exist side by side with equivalent hard-coded sRGB functions?


Why would any sane developer want to fork an existing libary and have it
exist side by side with an equivalent but subtly incompatible library?

Bye,
 Simon



You are entirely avoiding the very pertinent question I just asked and 
you full well know it.


Now could you try answering the question I did ask? Although frankly I'd 
rather hear what Jon Nordby has to say.


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] [Gimp-user] GIMP should fork babl and GEGL

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
> Why would any sane developer want to write all the new code and have it
> exist side by side with equivalent hard-coded sRGB functions?

Why would any sane developer want to fork an existing libary and have it
exist side by side with an equivalent but subtly incompatible library?

Bye,
Simon

-- 
  si...@budig.de  http://simon.budig.de/
___
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] GIMP should fork babl and GEGL

[Elle Stone]

On 11/05/2014 08:22 AM, Jon Nordby wrote:

What you just described IS side-by-side implementations of
operations. In an ICC profile color-managed application, sRGB is
just another RGB working space. You don't need to special-case sRGB.


No it is not. There will be one implementation of say "multiply". It
will be able to work on any RGB color space. Including sRGB, but without
need for special casing.

Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc.

In Pippin's originally planned "unbounded sRGB architecture",
"bablRGB" meant "convert the image to unbounded sRGB before
perfoming *any* editing operation". Now the plan is that bablRGB
will mean "convert to unbounded sRGB for *some* operations".


The meaning of the "bablRGB" specifiers has not, and will not change.
The vast majority of operations will just stop using them (because they
have hardcoded sRGB parameters), and instead use the new specifiers, as
per the roadmap.



For the babl code that converts an sRGB image to grayscale for use as a 
layer mask, do you plan to add a new set of functions that convert from 
UserRGB to grayscale?


That code would, of course, need to pull Y values from UserRGB. Which of 
course means that the new code for UserRGB would also work for sRGB images.


For the babl code that converts from color to Y for painting on a mask, 
that code currently is hard-coded to use sRGB Y values. Do you plan to 
add a new set of functions that convert from UserRGB to Y for painting 
on a mask? That code would also, of course, need to pull Y values from 
UserRGB. Which of course means that the new code for UserRGB would also 
work for sRGB images.


For all the GIMP UI functions that currently use hard-coded sRGB Y 
values sprinkled through babl, GEGL, and GIMP, do you plan to add a new 
set of alternate functions that will use Y values pulled from UserRGB? 
Again, that new UserRGB code will also work for sRGB images.


How is this not side-by-side implementation?

Why would any sane developer want to write all the new code and have it 
exist side by side with equivalent hard-coded sRGB functions?


What part of the latest new plan am I missing? Could you explain the 
purpose that is served by having all the functions with hard-coded sRGB 
parameters sit side by side with equivalent functions that use UserRGB 
parameters?


Or are you really getting rid of *all* the hard-coded sRGB parameters? 
In which case, what is the new purpose for the bablRGB formats that 
"will not change" their meanings?


Best regards,
Elle Stone
--
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] GIMP should fork babl and GEGL

[Jon Nordby]

On 5 November 2014 13:50, Elle Stone  wrote:

> On 11/04/2014 02:31 PM, Jon Nordby wrote:
>
>> (apologies for top-posting)
>>
>> Hi Elle,
>>
>> The BABL roadmap[1], which was written in response to comments raised by
>> you (and others),
>> details a mechanism for working with multiple RGB color spaces. It will
>> be possible to create a babl format specifier which means
>> "whatever-the-artist-chose-for-this-image RGB".
>> All GEGL operations which currently wrongly use hardcoded bablRGB ("RGBA
>> float" and similar) will be changed to use this new specifier.
>> Duplicate/side-by-side implementations of operations is not necessary
>> nor planned.
>>
>
>  With this BABL work in place, GIMP/GEGL can then use LCMS to read in the
>> ICC color profiles from inputs and set up the parameters for this color
>> space.
>>
>> I do not understand how this solution (once implemented) will not work
>> for your usecase. If you think it will not, please explain why.
>>
>> I have no desired for a "sRGB only" workflow, and it does not help the
>> discussion to jump such a conclusion. Please do not assume that the
>> different needs are in conflict/adverserial to each other.
>>
>> 1. https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74
>>
>
> What you just described IS side-by-side implementations of operations. In
> an ICC profile color-managed application, sRGB is just another RGB working
> space. You don't need to special-case sRGB.
>

No it is not. There will be one implementation of say "multiply". It will
be able to work on any RGB color space. Including sRGB, but without need
for special casing.


> Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc.
>
> In Pippin's originally planned "unbounded sRGB architecture", "bablRGB"
> meant "convert the image to unbounded sRGB before perfoming *any* editing
> operation". Now the plan is that bablRGB will mean "convert to unbounded
> sRGB for *some* operations".
>

The meaning of the "bablRGB" specifiers has not, and will not change. The
vast majority of operations will just stop using them (because they have
hardcoded sRGB parameters), and instead use the new specifiers, as per the
roadmap.


-- 
Jon Nordby - www.jonnor.com
___
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] [Gimp-user] GIMP should fork babl and GEGL

[Alexandre Prokoudine]

On Wed, Nov 5, 2014 at 4:57 PM, Elle Stone wrote:

> Drop the incredibly paternalistic attitude that the devs know better than
> the GIMP users what GIMP users really need.

Out of curiosity: if we had that attitude, what was the point of
working with a user experience architect from 2006 to 2013, actually
conducting interviews with end-user and adding/rewriting features
based on those interviews? :)

> Try finding a few actual high end users who understand ICC profile color
> management and the requirements for proper RGB image editing, and *ask* them
> what they need. Talk to Krita users and Darktable users. Even try to find a
> few Adobe Cloud refugees and talk to them - there is certainly enough
> interest in high bit depth GIMP being expressed in the various photography
> forums.

With Peter's departure, someone would have to take over the role of
UI/UX guy to do interviews properly and write specs.

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] [Gimp-user] GIMP should fork babl and GEGL

[Elle Stone]

My apologies in advance for sounding preachy, but here goes:

GIMP developers need to start paying attention to what potential and 
actual GIMP users really want and need from their RGB image editor.


I respectfully suggest the following:

Drop the incredibly paternalistic attitude that the devs know better 
than the GIMP users what GIMP users really need.


Try finding a few actual high end users who understand ICC profile color 
management and the requirements for proper RGB image editing, and *ask* 
them what they need. Talk to Krita users and Darktable users. Even try 
to find a few Adobe Cloud refugees and talk to them - there is certainly 
enough interest in high bit depth GIMP being expressed in the various 
photography forums.


Ask these actual and potential new GIMP users how GIMP would need to 
change before these users would be happy using GIMP for photographic 
image editing. And please don't try to hide from the user what's 
happening in the background. Instead show some respect the user's RGB 
data. Users are trusting that GIMP doesn't do silly things like 
converting to unbounded sRGB in the background or deciding for the user 
whether an operation should be done on linear or perceptually uniform RGB.


Best regards,
Elle Stone
___
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] GIMP should fork babl and GEGL

[Elle Stone]

In his last post on the topic Pippin said:


Once we have the vocabulary to also describe this aspect of the
pixelformats used by operations, the first thing we should do is to
annotate all the operations which are broken when done with sRGB
primaries, then we will be able to continue refactoring, profiling and
optimizing; without breaking existing functionality/rendering. Not
only in terms of making more operations request directly userRGB, but
also doing things like make some linear operations accept any of
userRGB or bablRGB (or other linear RGB); and creating output buffers
in the same format – to avoid unnecessary conversions in such cases.

Using a fixed linear RGB format instead of userRGB is what for some
operations will provide the consistent results for the same property
values / slider positions. Knowing which operations this is important
for is easier to determine when we have code providing the vocabulary
in babl. The further along on the roadmap, more of the road will have
to be laid/determined as we walk it.



Nothing in the above post shows that Pippin has given up on unbounded 
sRGB. If Pippin really understood anything I've been trying to explain, 
he wouldn't still be saying things like:


//begin quote
"Using a fixed linear RGB format instead of userRGB is what for some 
operations will provide the consistent results for the same property 
values / slider positions. Knowing which operations this is important 
for is easier to determine when we have code providing the vocabulary in 
babl."

//end quote

There is not one single operation for which it is important that sliders 
produce consistent results. NONE. NOT ONE. The whole premise that 
sliders should produce consistent results is grounded in a misconception 
of the requirements for RGB image editing.


Anyone not indoctrinated in the whole unbounded sRGB mystique that's 
been perpetrated among the babl/GEGL/GIMP devs for the last however many 
years would be rolling on the floor laughing if they could fight their 
way past the nonstandard "color management" vocabulary enough to 
understand what you all have been talking about all these years.


I no longer have the time to continue being actively involved with GIMP 
development (OK, that cheering in the background isn't nice! :) ). My 
hope is to see the whole unbounded sRGB thing abandoned. Let bablRGB be 
UserRGB. You can deal with device-specific code with a UI warning. An 
RGB image editor should NEVER mess with the user's RGB data without the 
user's explicit request. Behind the scenes conversions to unbounded sRGB 
is just wrong.


GIMP is important to free/libre artists. GIMP is also important to 
would-be refugees from Adobe Cloud. Artists need non-proprietary 
alternatives and specifically they need software that doesn't lock the 
user's work inside proprietary formats that can't even be accessed 
without a subscription.


(To forestall one of Pippin's stock responses, no, I am not advocating 
that GIMP be a PhotoShop clone. One reason I switched to Linux and free 
software was because I was unhappy with PhotoShop limitations regarding 
linear gamma image processing; sadly Cinepaint capabilities were 
overrated; even more sadly, all these years later GIMP high bit depth 
image processing is saddled with the whole unbounded sRGB overlay.)


If GIMP can't get ICC profile color management exactly right, well, 
DarkTable partly fills the gap with its built-in masks. And Krita is 
frankly leaving GIMP in the dust in very many ways. Krita is a load of 
fun to use for painting. But Krita not aimed at photographers and it's 
not as easy to use for strictly RGB image editing as GIMP would be, 
could be, if unbounded sRGB is just abandoned and the devs starting 
listening to potential and actual GIMP users.


What free/libre photographers really need is for GIMP to be everything 
it could be if ICC profile color management is properly implemented 
across the board for all editing operations. This whole unbounded sRGB 
thing is a dead-end street.


Best regards,
Elle Stone
___
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] GIMP should fork babl and GEGL

[Elle Stone]

On 11/04/2014 02:31 PM, Jon Nordby wrote:

(apologies for top-posting)

Hi Elle,

The BABL roadmap[1], which was written in response to comments raised by
you (and others),
details a mechanism for working with multiple RGB color spaces. It will
be possible to create a babl format specifier which means
"whatever-the-artist-chose-for-this-image RGB".
All GEGL operations which currently wrongly use hardcoded bablRGB ("RGBA
float" and similar) will be changed to use this new specifier.
Duplicate/side-by-side implementations of operations is not necessary
nor planned.



With this BABL work in place, GIMP/GEGL can then use LCMS to read in the
ICC color profiles from inputs and set up the parameters for this color
space.

I do not understand how this solution (once implemented) will not work
for your usecase. If you think it will not, please explain why.

I have no desired for a "sRGB only" workflow, and it does not help the
discussion to jump such a conclusion. Please do not assume that the
different needs are in conflict/adverserial to each other.

1. https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74


What you just described IS side-by-side implementations of operations. 
In an ICC profile color-managed application, sRGB is just another RGB 
working space. You don't need to special-case sRGB.


Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc.

In Pippin's originally planned "unbounded sRGB architecture", "bablRGB" 
meant "convert the image to unbounded sRGB before perfoming *any* 
editing operation". Now the plan is that bablRGB will mean "convert to 
unbounded sRGB for *some* operations".


But thankfully the "convert from UserRGB to unbounded sRGB" code has not 
yet been written. So in reality, at this point in time "bablRGB" already 
IS UserRGB. There is no reason to write a whole bunch of new babl format 
specifiers for UserRGB. That would be side-by-side implementation.


ALL current babl/GEGL/GIMP editing operations already work just fine, 
regardless of the user's chosen RGB working space, EXCEPT for the fact 
that there are still hard-coded Y and XYZ parameters in the 
babl/GEGL/GIMP code base.


To work with UserRGB data, those hard-coded sRGB Y and XYZ parameters 
need to be generalized to use Y and XYZ parameters pulled from the 
user's chosen RGB working space. If you generalize those operations to 
work with Y and XYZ pulled from UserRGB, those operations will work just 
fine even when UserRGB really is sRGB.


"bablRGB" is now in fact and should remain UserRGB. There is no reason 
to write code that makes "bablRGB" mean "convert to unbounded sRGB" and 
then write more code that means "use UserRGB instead of sRGB".


I'm leaving to one side the babl sRGB TRC flips because that code 
requires special handling, and the user really does need a way to 
completely disable those TRC flips. A fundamental premise for writing an 
RGB image editor is that you never mess with the user's RGB data without 
their explicit permission. Just opening the image with GIMP is NOT 
explicit permission.


Best regards,
Elle Stone
___
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] [Gimp-user] GIMP should fork babl and GEGL

[Alexandre Prokoudine]

On Tue, Nov 4, 2014 at 10:27 PM, Elle Stone wrote:

> Another advantage to forking babl and GEGL for GIMP is that GIMP's fork of
> babl and GEGL could be GPLed, thus freeing the GIMP devs to add FFTW
> (Fourier transforms, http://www.fftw.org/) and other new functionality to
> GIMP. FFTW is GPLed. At present, GIMP is somewhat hobbled as to what GPL
> code can be used for new editing functions because the babl/GEGL code is
> LGPLed.

Well, it's a shame we can't legally use FFTW to revive that GSoC
project, but FFTW is not the only option out there. There's e.g.
https://github.com/anthonix/ffts.

Also, as Jehan correctly stated, licensing a library under GPL opens a
whole can of worms. Just google for "libredwg gpl freecad librecad" to
see what kind of madness can happen.

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] [Gimp-user] GIMP should fork babl and GEGL

[Michael Bauer]

Not to mention the extra work created for localizers if they have to 
maintain two forks... it would be like the OpenOffice / LibreOffice mess.


I must admit I understand very little about the technical arguments put 
forth in this debate but from the localizer (and to a certain extent 
end-user) perspective, forking should be a very very very very last 
resort if a project is dead in the water but somehow under someone's 
deathgrip. Most 'normal' end users glaze over when I try to explain the 
difference between OpenO and LibreO... I wouldn't want to have to do 
that with Gimp too.


Michael

05/11/2014 12:00, sgrìobh gimp-developer-list-requ...@gnome.org:

Another advantage to forking babl and GEGL for GIMP is that GIMP's fork
of babl and GEGL could be GPLed, thus freeing the GIMP devs to add FFTW
(Fourier transforms,http://www.fftw.org/) and other new functionality
to GIMP. FFTW is GPLed. At present, GIMP is somewhat hobbled as to what
GPL code can be used for new editing functions because the babl/GEGL
code is LGPLed.

With kindest regards,
Elle Stone


--
*Akerbeltz *
Goireasan Gàidhlig air an lìon
Fòn: +44-141-946 4437
Facs: +44-141-945 2701

*Tha Gàidhlig aig a' choimpiutair agad, siuthad, feuch e!*
Iomadh rud eadar prògraman oifis, brabhsairean, predictive texting,
geamannan is mòran a bharrachd. Tadhail oirnn aig www.iGàidhlig.net 


___
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