Re: [Gimp-developer] [Gegl-developer] [Gimp-user] Discontinuation of mailing lists and moving to Discourse

[GSR - FR]

Hi,
gimp-developer-list@gnome.org (2022-10-18 at 0833.00 +0200):
> Am 18.10.22 um 02:29 schrieb Jehan Pagès via gegl-developer-list:
> > There is one more thing to take into consideration: more
> > infrastructure means more work. I said it above, I am exhausted by
> > this all. I was only managing one of the mailing lists so far (the
> > gimp-gui one, the most recent) and still had to regularly handle
> > spams. I am personally thankful that this work goes to GNOME admins now.
> Spam did indeed heavily outweigh the on-topic messages on the other five
> mailing lists for quite some time - and anyone who's ever maintained a
> mailman-based mailing list can likely confirm that spam handling there
> is not as comfortable as doing this in e.g. a capable mail client.

Not even minimum integration with tools like Spamassassin, CRM114 and
such? Or a workflow in which suspicious posts are sent to moderators
via email, who then send pass/drop commands (automated or by hand in
own mail client) to the mail list? Similar fashion than (un)subscribe
command.

Oh well, it seems too late anyway now.

Cheers,
GSR
 
___
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] [Gegl-developer] [Gimp-user] Discontinuation of mailing lists and moving to Discourse

[Michael Schumacher via gimp-developer-list]

Am 18.10.22 um 02:29 schrieb Jehan Pagès via gegl-developer-list:
[...]

Now we could always try to fight against the current and persuade
GNOME infrastructure team, but we made a small opinion tour among the
current core team and nobody really had particular love or use of our
mailing lists. Also we realize it's very low volume these days (barely
a few threads per month, counting all mailing lists together). Myself
I barely look at mailing lists every once in a while and make a random
answer sometimes. And there were several mailing lists I was not even
subscribed to (I did for the sake of this announcement). So that's
probably why none from the core team is really trying to fight this
change.

There is one more thing to take into consideration: more
infrastructure means more work. I said it above, I am exhausted by
this all. I was only managing one of the mailing lists so far (the
gimp-gui one, the most recent) and still had to regularly handle
spams. I am personally thankful that this work goes to GNOME admins now.


Spam did indeed heavily outweigh the on-topic messages on the other five
mailing lists for quite some time - and anyone who's ever maintained a
mailman-based mailing list can likely confirm that spam handling there
is not as comfortable as doing this in e.g. a capable mail client.


--

Regards,
Michael

___
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] GEGL build failure

[Partha Bagchi via gimp-developer-list]

Thanks for pointing that out.

Yes, empty archives cannot be compiled on Mac. So, you can use an empty
dummy file or combine the 2 lines in ninja. It's not a meson bug.

On Sun, Sep 27, 2020 at 6:04 AM Gregory Reshetniak  wrote:

> Hi Partha
>
> Have a look at this issue, seems to be related
> https://gitlab.gnome.org/GNOME/gegl/-/issues/214
>
>
>
> On Sun, 27 Sep 2020 at 05:08, Partha Bagchi via gimp-developer-list <
> gimp-developer-list@gnome.org> wrote:
>
>> partha@Parthas-MacBook-Pro gegl % ninja install
>> [1/722] Linking static target subprojects/poly2tri-c/libpoly2tri-c.a
>> FAILED: subprojects/poly2tri-c/libpoly2tri-c.a
>> rm -f subprojects/poly2tri-c/libpoly2tri-c.a && ar csr
>> subprojects/poly2tri-c/libpoly2tri-c.a ar: no archive members specified
>> usage:  ar -d [-TLsv] archive file ...
>> ar -m [-TLsv] archive file ...
>> ar -m [-abiTLsv] position archive file ...
>> ar -p [-TLsv] archive [file ...]
>> ar -q [-cTLsv] archive file ...
>> ar -r [-cuTLsv] archive file ...
>> ar -r [-abciuTLsv] position archive file ...
>> ar -t [-TLsv] archive [file ...]
>> ar -x [-ouTLsv] archive [file ...]
>> [10/722] Compiling C object 'libs/rgbe/2e83b36@@rgbe@sta/rgbe.c.o'
>> ninja: build stopped: subcommand failed.
>>
>>
>> This will work on Linux and Windows but not on Mac. I work around it but
>> probably better to fix it at the source.
>>
>> Thanks,
>> Partha
>> ___
>> 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
>>
>
>
> --
>
> 
> Gregory Reshetniak
> about.me/gregory.reshetniak
> 
>
___
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] GEGL build failure

[Gregory Reshetniak via gimp-developer-list]

Hi Partha

Have a look at this issue, seems to be related
https://gitlab.gnome.org/GNOME/gegl/-/issues/214



On Sun, 27 Sep 2020 at 05:08, Partha Bagchi via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:

> partha@Parthas-MacBook-Pro gegl % ninja install
> [1/722] Linking static target subprojects/poly2tri-c/libpoly2tri-c.a
> FAILED: subprojects/poly2tri-c/libpoly2tri-c.a
> rm -f subprojects/poly2tri-c/libpoly2tri-c.a && ar csr
> subprojects/poly2tri-c/libpoly2tri-c.a ar: no archive members specified
> usage:  ar -d [-TLsv] archive file ...
> ar -m [-TLsv] archive file ...
> ar -m [-abiTLsv] position archive file ...
> ar -p [-TLsv] archive [file ...]
> ar -q [-cTLsv] archive file ...
> ar -r [-cuTLsv] archive file ...
> ar -r [-abciuTLsv] position archive file ...
> ar -t [-TLsv] archive [file ...]
> ar -x [-ouTLsv] archive [file ...]
> [10/722] Compiling C object 'libs/rgbe/2e83b36@@rgbe@sta/rgbe.c.o'
> ninja: build stopped: subcommand failed.
>
>
> This will work on Linux and Windows but not on Mac. I work around it but
> probably better to fix it at the source.
>
> Thanks,
> Partha
> ___
> 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
>


-- 

Gregory Reshetniak
about.me/gregory.reshetniak

___
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

[Gimp-developer] GEGL build failure

[Partha Bagchi via gimp-developer-list]

partha@Parthas-MacBook-Pro gegl % ninja install
[1/722] Linking static target subprojects/poly2tri-c/libpoly2tri-c.a
FAILED: subprojects/poly2tri-c/libpoly2tri-c.a
rm -f subprojects/poly2tri-c/libpoly2tri-c.a && ar csr
subprojects/poly2tri-c/libpoly2tri-c.a ar: no archive members specified
usage:  ar -d [-TLsv] archive file ...
ar -m [-TLsv] archive file ...
ar -m [-abiTLsv] position archive file ...
ar -p [-TLsv] archive [file ...]
ar -q [-cTLsv] archive file ...
ar -r [-cuTLsv] archive file ...
ar -r [-abciuTLsv] position archive file ...
ar -t [-TLsv] archive [file ...]
ar -x [-ouTLsv] archive [file ...]
[10/722] Compiling C object 'libs/rgbe/2e83b36@@rgbe@sta/rgbe.c.o'
ninja: build stopped: subcommand failed.


This will work on Linux and Windows but not on Mac. I work around it but
probably better to fix it at the source.

Thanks,
Partha
___
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

[Gimp-developer] GEGL Graph

[Kevin Payne via gimp-developer-list]

I have a couple of questions about using the GEGL graph dialog

When trying to use the gegl:bump-map command, I do not know how to specify the 
"aux" layer to use. Is this possible? if so what do I need to do?

When trying to use the gegl:contrast-curves command I don't know how to format 
the curve parameter as anything I try is crashing GIMP (issue #5607)

can anyone help with either or both?

Kevin 
___
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] GEGL-OpenCL

[Alexandre Prokoudine via gimp-developer-list]

On Wed, Apr 1, 2020 at 4:18 AM Massimo Fidanza wrote:
>
> Hi,
>
> I found this repository https://github.com/OpenCL/GEGL-OpenCL on GitHub
> which is sadly stopped in May 2017. Can I ask if this code has ever been
> merged?

Yes, you can, and yes, it was merged :)

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

[Gimp-developer] GEGL-OpenCL

[Massimo Fidanza via gimp-developer-list]

Hi,

I found this repository https://github.com/OpenCL/GEGL-OpenCL on GitHub
which is sadly stopped in May 2017. Can I ask if this code has ever been
merged?

Thanks
Massimo
___
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] GEGL operation as a GIMP plugin with UI builder

[Ell via gimp-developer-list]

On 1/31/20 1:07 PM, JonnyRobbie via gimp-developer-list wrote:
> 
> Hello,
> 
> I'm still in the quest of creating a pixel based gimp plugin.
> 
> Also this question is both for gimp and gegl, but pippin from gegl, directed
> me more towards gimp list (here).
> 
> I've managd to create a gegl operation - which seems to work fine (apart 
> some detail). The catch is that my implementation currently has the form of 
> directly altering gegl source code, recompiling whole gegl, installing that 
> and loading that into a gimp as a 'Tools-GEGL Operation', which is a lot 
> unwieldy.
> 
> Is there a way to implement a gegl operation in the form of a modular gimp 
> plugin, so it would work with ui builder widgets, like proprerty_double(), 
> auxulary inputs, etc? (see https://gitlab.gnome.org/GNOME/gegl/blob/master/
> operations/common/exposure.c#L26 for example). All the plugins in /plugins/ 
> seems to build its ui from scratch instead uf using gegl-like widgets.

Plug-ins and GEGL operations are two separate things.  Essentially,
plug-ins get a much higher-level access to GIMP -- they understand stuff
like images and layers -- while GEGL operations are filters that
transform an input buffer (or buffers) into an output.  If what you're
making fits into the model of a filter, you're much better off
implementing it as a GEGL operation, for the reasons pippin mentioned in
his mail.  Namely, better integration (e.g., a live on-canvas preview,
and, in the future, non-destructive editing), and much less boilerplate.
Most of the old plug-ins that implemented filters have been converted to
GEGL ops.

The main gotcha right now is the inability of GEGL ops to register a
menu item.  The ones that do show in the menu are hard-coded, while
other operations can only be accessed through the GEGL operation tool.
That's indeed pretty clunky, and it's something we want to fix, along
with better support for applying GEGL operations in scripts and plug-ins.

Plug-ins in general don't get an auto-generated UI right now (other than
scripts and python plug-ins), though the entire plug-in framework is
undergoing major changes for GIMP 3, with support for auto-generated UI
being one of them.

As for building GEGL ops, you can do it out-of-tree, without having to
build it as part of GEGL.  Essentially, if you start with one of the ops
from the GEGL tree, remove the `#include "config.h"` line, and compile
it as a shared library against GEGL (e.g., using `pkg-config --cflags
--libs gegl-0.4`; also, make sure the directory containing your source
file is in the include path), you should be able to get a standalone
library containing your op.

> Hte second issue I have is that most of the enums from here https://gitlab.
> gnome.org/GNOME/gegl/blob/master/gegl/gegl-op.h#L271 work, apart from 
> property_curve() from #L282. Is there a way to enable property_curve in gimp
> ()

Nope, there's no UI for property_curve() in GIMP right now.

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

[Gimp-developer] GEGL operation as a GIMP plugin with UI builder

[JonnyRobbie via gimp-developer-list]

Hello,

I'm still in the quest of creating a pixel based gimp plugin.

Also this question is both for gimp and gegl, but pippin from gegl, directed
me more towards gimp list (here).

I've managd to create a gegl operation - which seems to work fine (apart 
some detail). The catch is that my implementation currently has the form of 
directly altering gegl source code, recompiling whole gegl, installing that 
and loading that into a gimp as a 'Tools-GEGL Operation', which is a lot 
unwieldy.

Is there a way to implement a gegl operation in the form of a modular gimp 
plugin, so it would work with ui builder widgets, like proprerty_double(), 
auxulary inputs, etc? (see https://gitlab.gnome.org/GNOME/gegl/blob/master/
operations/common/exposure.c#L26 for example). All the plugins in /plugins/ 
seems to build its ui from scratch instead uf using gegl-like widgets.

Hte second issue I have is that most of the enums from here https://gitlab.
gnome.org/GNOME/gegl/blob/master/gegl/gegl-op.h#L271 work, apart from 
property_curve() from #L282. Is there a way to enable property_curve in gimp
()

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

[Gimp-developer] gegl i18n update & docs build

[Marco Ciampa via gimp-developer-list]

Hi devs,

please in gegl how can I update the i18n po files & build the docs with
the new meson + ninja method?

The READMEs in the sources are obsolete...

TIA!

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364



___
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] GEGL Drop Shadow filter not working

[Julien Hardelin]

Thank you Alex for your explanation : I missed Crop to content.

Julien

___
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] GEGL Drop Shadow filter not working

[Marco Ciampa via gimp-developer-list]

On Sat, Jan 05, 2019 at 10:38:19PM +0300, Alexandre Prokoudine via 
gimp-developer-list wrote:
> пт, 4 янв. 2019 г., 19:36 Marco Ciampa:
> 
> > On Fri, Jan 04, 2019 at 03:09:21PM +0300, Alexandre Prokoudine via
> > gimp-developer-list wrote:
> > > https://i.imgur.com/TciFDZy.png
> >
> > Sorry, no:
> >
> > https://imgur.com/a/8OepPGF
> 
> 
> I really have no idea what's going on in your case.
> 
> I'm on Ubuntu 18.10 and GIMP from gimp-2-10 master branch, although it
> doesn't change a thing -- it's been working for me since the beginning.
> 
> 1. New image
> 2. New layer
> 3. Select, fill with color
> 4. Crop to content
> 5. Enlarge layer boundary
> 6. Launch the GEGL op in question.
> 
> Or even simpler, with a text layer:
> 
> 1. New image
> 2. New text layer with some text
> 3. Layer to image size
> 4. Launch the GEGL op in question.
> 
> In both scenarios, the GEGL-based filter works just like on my screenshot.

Sorry, I was not clear in my last example message.
After the example of Julien I was able to figure out how that filter worked
and managed to make it work. It was not immediate though... at least to me
that admittedly am not such a great (not at all) GIMP user...

Anyway thanks for clarifying it to me...

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364



___
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] GEGL Drop Shadow filter not working

[Alexandre Prokoudine via gimp-developer-list]

пт, 4 янв. 2019 г., 19:36 Marco Ciampa:

> On Fri, Jan 04, 2019 at 03:09:21PM +0300, Alexandre Prokoudine via
> gimp-developer-list wrote:
> > https://i.imgur.com/TciFDZy.png
>
> Sorry, no:
>
> https://imgur.com/a/8OepPGF


I really have no idea what's going on in your case.

I'm on Ubuntu 18.10 and GIMP from gimp-2-10 master branch, although it
doesn't change a thing -- it's been working for me since the beginning.

1. New image
2. New layer
3. Select, fill with color
4. Crop to content
5. Enlarge layer boundary
6. Launch the GEGL op in question.

Or even simpler, with a text layer:

1. New image
2. New text layer with some text
3. Layer to image size
4. Launch the GEGL op in question.

In both scenarios, the GEGL-based filter works just like on my screenshot.

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] GEGL Drop Shadow filter not working

[Marco Ciampa via gimp-developer-list]

On Sat, Jan 05, 2019 at 09:07:11AM +0100, Julien Hardelin wrote:
> Wel, I progress.
> 
> With text layers, GEGL and Legacy Drop Shadow filters work the same.
> 
> With images, to get, with the GEGL filter, the same effect as the Legacy
> filter, I must use a complex procedure:
> 
> - Open the original image
> 
> - Open a transparent image a little bigger than the original image.
> 
> - Copy-paste the original image into the transparent image.
> 
> - This creates a floating selection. Anchor the floating selection.
> 
> - Apply GEGL Drop Shadow.
> 
> Voilà.

I did:

- Open the original image

- If not present add an alfa channel

- Select the object you want to drop a shadow

- Invert the selection

- Cut the selection

- Past the selection into another layer

- Put that layer as the bottom layer

- Select the first/object layer

- Remove any selection

- Drop the shadow


--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364



___
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] GEGL Drop Shadow filter not working

[Julien Hardelin]

Wel, I progress.

With text layers, GEGL and Legacy Drop Shadow filters work the same.

With images, to get, with the GEGL filter, the same effect as the Legacy 
filter, I must use a complex procedure:


- Open the original image

- Open a transparent image a little bigger than the original image.

- Copy-paste the original image into the transparent image.

- This creates a floating selection. Anchor the floating selection.

- Apply GEGL Drop Shadow.

Voilà.

All my attempts using resizing layer failed. Is there a simpler, at 
once, way to do this as with the legacy filter?


Julien

Le 05/01/2019 à 03:18, Joao S. O. Bueno via gimp-developer-list a écrit :

The GEGLized drop shadow filter is a big regressin in 2.10 -
nonetheless it works, in a destructive way (while the legacy
dropshadow works in a
non destructive way, and even allows adjusting the effect by
displacing the created
shadow layer).

So - it actually only works in a whole layer, is there are no active
selections -
if you are seeing nothing (and have space in the layer), maybe the problem is
that you have an active selection. The legacy drop shadow works
in a similar way, by changing the active layer, if there is an
active selection. The existing GEGL filter have no equivalent mode
to the one that would create a shadow for the selection itself in the
old filter.


On Fri, 4 Jan 2019 at 14:36, Marco Ciampa via gimp-developer-list
 wrote:

On Fri, Jan 04, 2019 at 03:09:21PM +0300, Alexandre Prokoudine via 
gimp-developer-list wrote:

https://i.imgur.com/TciFDZy.png

Sorry, no:

https://imgur.com/a/8OepPGF

what system/gimp-version are you using?

Mine is Ubuntu 18.04 with dev 2.10 branch gimp ...

--


Marco Ciampa

I know a joke about UDP, but you might not get it.



  GNU/Linux User #78271
  FSFE fellow #364



___
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

___
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

___
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] GEGL Drop Shadow filter not working

[Joao S. O. Bueno via gimp-developer-list]

The GEGLized drop shadow filter is a big regressin in 2.10 -
nonetheless it works, in a destructive way (while the legacy
dropshadow works in a
non destructive way, and even allows adjusting the effect by
displacing the created
shadow layer).

So - it actually only works in a whole layer, is there are no active
selections -
if you are seeing nothing (and have space in the layer), maybe the problem is
that you have an active selection. The legacy drop shadow works
in a similar way, by changing the active layer, if there is an
active selection. The existing GEGL filter have no equivalent mode
to the one that would create a shadow for the selection itself in the
old filter.


On Fri, 4 Jan 2019 at 14:36, Marco Ciampa via gimp-developer-list
 wrote:
>
> On Fri, Jan 04, 2019 at 03:09:21PM +0300, Alexandre Prokoudine via 
> gimp-developer-list wrote:
> > https://i.imgur.com/TciFDZy.png
>
> Sorry, no:
>
> https://imgur.com/a/8OepPGF
>
> what system/gimp-version are you using?
>
> Mine is Ubuntu 18.04 with dev 2.10 branch gimp ...
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
> ___
> 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
___
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] GEGL Drop Shadow filter not working

[Marco Ciampa via gimp-developer-list]

On Fri, Jan 04, 2019 at 03:09:21PM +0300, Alexandre Prokoudine via 
gimp-developer-list wrote:
> https://i.imgur.com/TciFDZy.png

Sorry, no:

https://imgur.com/a/8OepPGF

what system/gimp-version are you using?

Mine is Ubuntu 18.04 with dev 2.10 branch gimp ...

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364



___
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] GEGL Drop Shadow filter not working

[Julien Hardelin]

I tried and tried again in all possible ways, and no , it doesn't work.

That's a problem.

Please, give me your step by step procedure.

Julien

Le 04/01/2019 à 13:09, Alexandre Prokoudine via gimp-developer-list a 
écrit :

https://i.imgur.com/TciFDZy.png

On Thu, Jan 3, 2019 at 10:57 AM Julien Hardelin  wrote:

I tried this before posting, using Layer Boundary Size to make the layer size 
bigger : it doesn't work.

Le 02/01/2019 à 22:38, Alexandre Prokoudine a écrit :

The layer has to be the size of the canvas or at least somewhat larger than its 
contents

Alex

ср, 2 янв. 2019 г., 20:39 Julien Hardelin jm.h...@wanadoo.fr:

Hi devs,

With Gimp-2.10.8 and Gimp-2.99, under different systems and computers,
the Drop Shadow filter doesn't work: nothing happens when I use it.
(Drop Shadow (legacy) works perfectly)

Is this due to work in progress or to something I don't understand in
using it?

Julien

___
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

___
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

___
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] GEGL Drop Shadow filter not working

[Alexandre Prokoudine via gimp-developer-list]

https://i.imgur.com/TciFDZy.png

On Thu, Jan 3, 2019 at 10:57 AM Julien Hardelin  wrote:
>
> I tried this before posting, using Layer Boundary Size to make the layer size 
> bigger : it doesn't work.
>
> Le 02/01/2019 à 22:38, Alexandre Prokoudine a écrit :
>
> The layer has to be the size of the canvas or at least somewhat larger than 
> its contents
>
> Alex
>
> ср, 2 янв. 2019 г., 20:39 Julien Hardelin jm.h...@wanadoo.fr:
>>
>> Hi devs,
>>
>> With Gimp-2.10.8 and Gimp-2.99, under different systems and computers,
>> the Drop Shadow filter doesn't work: nothing happens when I use it.
>> (Drop Shadow (legacy) works perfectly)
>>
>> Is this due to work in progress or to something I don't understand in
>> using it?
>>
>> Julien
>>
>> ___
>> 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
___
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] GEGL Drop Shadow filter not working

[Julien Hardelin]

I tried this before posting, using Layer Boundary Size to make the layer 
size bigger : it doesn't work.


Le 02/01/2019 à 22:38, Alexandre Prokoudine a écrit :
The layer has to be the size of the canvas or at least somewhat larger 
than its contents


Alex

ср, 2 янв. 2019 г., 20:39 Julien Hardelin jm.h...@wanadoo.fr 
:


Hi devs,

With Gimp-2.10.8 and Gimp-2.99, under different systems and
computers,
the Drop Shadow filter doesn't work: nothing happens when I use it.
(Drop Shadow (legacy) works perfectly)

Is this due to work in progress or to something I don't understand in
using it?

Julien

___
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


___
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] GEGL Drop Shadow filter not working

[Marco Ciampa via gimp-developer-list]

On Thu, Jan 03, 2019 at 12:38:41AM +0300, Alexandre Prokoudine via 
gimp-developer-list wrote:
> The layer has to be the size of the canvas or at least somewhat larger than
> its contents

What do you mean with this? I create a new image, create a selection in
it, fill it with black and start the filter. Nothing happens. What should
I do to make it work?

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364



___
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] GEGL Drop Shadow filter not working

[Alexandre Prokoudine via gimp-developer-list]

The layer has to be the size of the canvas or at least somewhat larger than
its contents

Alex

ср, 2 янв. 2019 г., 20:39 Julien Hardelin jm.h...@wanadoo.fr:

> Hi devs,
>
> With Gimp-2.10.8 and Gimp-2.99, under different systems and computers,
> the Drop Shadow filter doesn't work: nothing happens when I use it.
> (Drop Shadow (legacy) works perfectly)
>
> Is this due to work in progress or to something I don't understand in
> using it?
>
> Julien
>
> ___
> 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
>
___
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

[Gimp-developer] GEGL Drop Shadow filter not working

[Julien Hardelin]

Hi devs,

With Gimp-2.10.8 and Gimp-2.99, under different systems and computers, 
the Drop Shadow filter doesn't work: nothing happens when I use it. 
(Drop Shadow (legacy) works perfectly)


Is this due to work in progress or to something I don't understand in 
using it?


Julien

___
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] GEGL Compilation Error

[Øyvind Kolås]

The error indicates that the C++ part of gcc is not installed on your
system. Most of GEGL is using just C, but a couple of operations
relying on external C++ based libraries need the C++ parts as well.

On Sat, Mar 24, 2018 at 5:58 PM, Americo Gobbo  wrote:
> Hi all,
> I am trying compile the GEGL but I have this error (git clone updated).
> All dependencies are complete and .autogen.sh is OK.
> Thanks
> americo
>
> ===
> ...
>   CC   clip.o
>   CCLD gcut
> make[2]: Leaving directory '/home/jag/devel/gimp-git-master/gegl/gcut'
> Making all in tools
> make[2]: Entering directory '/home/jag/devel/gimp-git-master/gegl/tools'
>   CC   gegl-imgcmp.o
>   CC   introspect.o
>   CC   operation_reference.o
>   CC   detect_opencl.o
>   CC   gegl-tester.o
>   CC   operations_html.o
>   CXX  exp_combine-exp_combine.o
> ../depcomp: line 772: exec: g++: not found
> make[2]: *** [Makefile:716: exp_combine-exp_combine.o] Error 127
> make[2]: *** Waiting for unfinished jobs
> make[2]: Leaving directory '/home/jag/devel/gimp-git-master/gegl/tools'
> make[1]: *** [Makefile:637: all-recursive] Error 1
> make[1]: Leaving directory '/home/jag/devel/gimp-git-master/gegl'
> make: *** [Makefile:544: all] Error 2
> ___
> gimp-developer-list mailing list
> List membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:https://mail.gnome.org/archives/gimp-developer-list
>
> ___
> 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
___
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

[Gimp-developer] GEGL Compilation Error

[Americo Gobbo]

Hi all,
I am trying compile the GEGL but I have this error (git clone updated).
All dependencies are complete and .autogen.sh is OK.
Thanks
americo

===
...
  CC   clip.o
  CCLD gcut
make[2]: Leaving directory '/home/jag/devel/gimp-git-master/gegl/gcut'
Making all in tools
make[2]: Entering directory '/home/jag/devel/gimp-git-master/gegl/tools'
  CC   gegl-imgcmp.o
  CC   introspect.o
  CC   operation_reference.o
  CC   detect_opencl.o
  CC   gegl-tester.o
  CC   operations_html.o
  CXX  exp_combine-exp_combine.o
../depcomp: line 772: exec: g++: not found
make[2]: *** [Makefile:716: exp_combine-exp_combine.o] Error 127
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/home/jag/devel/gimp-git-master/gegl/tools'
make[1]: *** [Makefile:637: all-recursive] Error 1
make[1]: Leaving directory '/home/jag/devel/gimp-git-master/gegl'
make: *** [Makefile:544: all] Error 2
___
gimp-developer-list mailing list
List membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:https://mail.gnome.org/archives/gimp-developer-list

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

[Michal Vašut]

Thanks Alex for explanation.

I've written a minimally functional gegl ui that works in Laidout:
> https://www.youtube.com/watch?v=GPz3BniLSFw=8s


Wow that's exactly what I had in my mind.

It can also import SVG filters
>

I also thought about this. Inkscape has some SVG filter editor, but this
looks much better!

My intention is to have this node ui usable, if possible, at least via a
> plugin to Gimp (for instance). I'm doing a workshop at the upcoming
> Libre Graphics Meeting about nodes in FOSS to further explore issues
> involved.
>

You are my hero :-D.

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

[Tom Lechner]

On 03/13/2018 01:22 PM, Alexandre Prokoudine wrote:

It does have a UI which is available optionally, and unlike Blender's
node editor, very few people have used it so far. There also was a
GSoC project to build a conventional node-based editor with GTK+ UI
for GEGL, but it didn't exactly succeed.


What and where is this ui? I know of imgflo. Is there another? I see a 
Tool->Gegl Operation in Gimp 2.9, but this seems to be a one time, one 
operation, irreversible thing, with broader reversible node editing only 
in the fullness of time, according to Gimp's roadmap.



I've written a minimally functional gegl ui that works in Laidout:
https://www.youtube.com/watch?v=GPz3BniLSFw=8s

It's very new and not remotely tested enough! It currently can import 
and export gegl xml files. It can also import SVG filters (still working 
on export, and mapping to gegl nodes).


My intention is to have this node ui usable, if possible, at least via a 
plugin to Gimp (for instance). I'm doing a workshop at the upcoming 
Libre Graphics Meeting about nodes in FOSS to further explore issues 
involved.


-Tom
laidout.org
tomlechner.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] GEGL

[Alexandre Prokoudine]

On Tue, Mar 13, 2018 at 7:18 PM, Michal Vašut wrote:
> Is GEGL comparable with Blender's node editor

This is a technically incorrect question.

GEGL is an image processing engine. It isn't UI.

It does have a UI which is available optionally, and unlike Blender's
node editor, very few people have used it so far. There also was a
GSoC project to build a conventional node-based editor with GTK+ UI
for GEGL, but it didn't exactly succeed.

> or could it be visualised this way?

It can be, see above.

> Another one: Does Gimp use GEGL localisations (there are some in GEGL
> repository), or it's own?

If GEGL operations are translated into your native language, and GIMP
uses that language in UI, you will see options of those operations in
your native language.

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

[Gimp-developer] GEGL

[Michal Vašut]

Is GEGL comparable with Blender's node editor or could it be visualised
this way? Or did I miss the concept of it and it's something completely
different?

Another one: Does Gimp use GEGL localisations (there are some in GEGL
repository), or it's own?

Thanks for answers,
Michal
___
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] GEGL make error - Fedora 27

[Shlomi Fish]

On Thu, 8 Mar 2018 09:58:20 -0500
Partha Bagchi  wrote:

> On Thu, Mar 8, 2018 at 9:43 AM, Americo Gobbo  wrote:
> 
> > Hi All,
> > I am trying create the environment on Fedora 27 to GIMP devel... But, I
> > have found problems on 'make' process:
> >
> > Making all in gcut
> > make[2]: Entering directory '/home/jag/devel/gimp-git-master/gegl/gcut'
> > make[2]: Nothing to be done for 'all'.
> > make[2]: Leaving directory '/home/jag/devel/gimp-git-master/gegl/gcut'
> > Making all in tools
> > make[2]: Entering directory '/home/jag/devel/gimp-git-master/gegl/tools'
> >   CCLD introspect
> >   CCLD operation_reference
> >   CCLD detect_opencl
> >   CCLD gegl-tester
> >   CXX  exp_combine-exp_combine.o
> >   CCLD operations_html
> > ../depcomp: line 772: exec: g++: not found
> > make[2]: *** [Makefile:716: exp_combine-exp_combine.o] Error 127
> > make[2]: *** Waiting for unfinished jobs
> > make[2]: Leaving directory '/home/jag/devel/gimp-git-master/gegl/tools'
> > make[1]: *** [Makefile:633: all-recursive] Error 1
> > make[1]: Leaving directory '/home/jag/devel/gimp-git-master/gegl'
> > make: *** [Makefile:540: all] Error 2
> > ===
> > the autogen.sh is OK, all dependencies are completed (less mrg ;)
> > Someone can help me?
> >
> > Thanks
> > americo
> >  
> Seems clear to me americo. :) It says g++ not found. What happens when you
> type g++ in your GIMP shell environment?
> 

hi!

1. on fedora, g++ can be installed by following
https://stackoverflow.com/questions/12952913/how-do-i-install-g-for-fedora

2. ./configure ought to try to see if doesn't exist and fail earlier.



-- 
-
Shlomi Fish   http://www.shlomifish.org/
Why I Love Perl - http://shlom.in/joy-of-perl

Chuck Norris is the ghost author of the entire Debian GNU/Linux distribution.
And he wrote it in 24 hours, while taking snack breaks.
— http://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

Please reply to list if it's a mailing list post - http://shlom.in/reply .
___
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] GEGL make error - Fedora 27

[Partha Bagchi]

Elle,

g++ is the C++ compiler. In your case, it's installed on your system.

Thanks,
Partha

On Thu, Mar 8, 2018 at 10:28 AM, Elle Stone 
wrote:

> On 03/08/2018 09:58 AM, Partha Bagchi wrote:
>
>> It says g++ not found. What happens when you
>> type g++ in your GIMP shell environment?
>>
>
> Hi Partha - thanks! that was interesting. I didn't have a clue what "g++"
> might be, but here's what happened when I typed it into a terminal:
>
> $ g++
> g++: fatal error: no input files
> compilation terminated.
>
> Which seemed mysterious. So I asked Gentoo to tell me which package this
> "g++" thing was part of:
>
> $ equery belongs g++
>  * Searching for g++ ...
> sys-devel/gcc-6.4.0-r1 (/usr/x86_64-pc-linux-gnu/gcc-bin/6.4.0/g++ ->
> x86_64-pc-linux-gnu-g++)
>
> I always thought of "gcc" as the "gnu c compiler". But apparently that's
> no longer the case, instead "gcc" now stands for "gnu compiler collection",
> which includes c++:
>
> https://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/G_002b_002b-and-GCC.html
>
> 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
>
___
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] GEGL make error - Fedora 27

[Elle Stone]

On 03/08/2018 09:58 AM, Partha Bagchi wrote:

It says g++ not found. What happens when you
type g++ in your GIMP shell environment?


Hi Partha - thanks! that was interesting. I didn't have a clue what 
"g++" might be, but here's what happened when I typed it into a terminal:


$ g++
g++: fatal error: no input files
compilation terminated.

Which seemed mysterious. So I asked Gentoo to tell me which package this 
"g++" thing was part of:


$ equery belongs g++
 * Searching for g++ ...
sys-devel/gcc-6.4.0-r1 (/usr/x86_64-pc-linux-gnu/gcc-bin/6.4.0/g++ -> 
x86_64-pc-linux-gnu-g++)


I always thought of "gcc" as the "gnu c compiler". But apparently that's 
no longer the case, instead "gcc" now stands for "gnu compiler 
collection", which includes c++:


https://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/G_002b_002b-and-GCC.html

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] GEGL make error - Fedora 27

[Partha Bagchi]

On Thu, Mar 8, 2018 at 9:43 AM, Americo Gobbo  wrote:

> Hi All,
> I am trying create the environment on Fedora 27 to GIMP devel... But, I
> have found problems on 'make' process:
>
> Making all in gcut
> make[2]: Entering directory '/home/jag/devel/gimp-git-master/gegl/gcut'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory '/home/jag/devel/gimp-git-master/gegl/gcut'
> Making all in tools
> make[2]: Entering directory '/home/jag/devel/gimp-git-master/gegl/tools'
>   CCLD introspect
>   CCLD operation_reference
>   CCLD detect_opencl
>   CCLD gegl-tester
>   CXX  exp_combine-exp_combine.o
>   CCLD operations_html
> ../depcomp: line 772: exec: g++: not found
> make[2]: *** [Makefile:716: exp_combine-exp_combine.o] Error 127
> make[2]: *** Waiting for unfinished jobs
> make[2]: Leaving directory '/home/jag/devel/gimp-git-master/gegl/tools'
> make[1]: *** [Makefile:633: all-recursive] Error 1
> make[1]: Leaving directory '/home/jag/devel/gimp-git-master/gegl'
> make: *** [Makefile:540: all] Error 2
> ===
> the autogen.sh is OK, all dependencies are completed (less mrg ;)
> Someone can help me?
>
> Thanks
> americo
>
Seems clear to me americo. :) It says g++ not found. What happens when you
type g++ in your GIMP shell environment?

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

[Gimp-developer] GEGL make error - Fedora 27

[Americo Gobbo]

Hi All,
I am trying create the environment on Fedora 27 to GIMP devel... But, I have 
found problems on 'make' process:

Making all in gcut
make[2]: Entering directory '/home/jag/devel/gimp-git-master/gegl/gcut'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/jag/devel/gimp-git-master/gegl/gcut'
Making all in tools
make[2]: Entering directory '/home/jag/devel/gimp-git-master/gegl/tools'
  CCLD introspect
  CCLD operation_reference
  CCLD detect_opencl
  CCLD gegl-tester
  CXX  exp_combine-exp_combine.o
  CCLD operations_html
../depcomp: line 772: exec: g++: not found
make[2]: *** [Makefile:716: exp_combine-exp_combine.o] Error 127
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/home/jag/devel/gimp-git-master/gegl/tools'
make[1]: *** [Makefile:633: all-recursive] Error 1
make[1]: Leaving directory '/home/jag/devel/gimp-git-master/gegl'
make: *** [Makefile:540: all] Error 2
===
the autogen.sh is OK, all dependencies are completed (less mrg ;)
Someone can help me?

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

___
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] GEGL errors during 'make' process

[Americo Gobbo]

Hi Jehan,

On 03/02/2018 22:47, Jehan Pagès wrote:

Well there is nothing in the command line itself which relates to
libexiv2. It looks like there is something wrong in the libtool script
wrapper generated by the build system. Delete the file "libtool" which
you will find in the root of the git repository. Then run the
configure script again (this will create again the libtool wrapper),
then make and let's see what happens.

Is the same behavior... very strange.

libtool:   error: cannot find the library '/usr/local/lib/libexiv2.la' 
or unhandled argument '/usr/local/lib/libexiv2.la'

Makefile:571: recipe for target 'gegl' failed
make[2]: *** [gegl] Error 1
make[2]: Leaving directory '/home/jag/devel/gimp-default-master-/gegl/bin'
Makefile:634: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/jag/devel/gimp-default-master-/gegl'
Makefile:541: recipe for target 'all' failed
make: *** [all] Error 2

---

This is my 'autogen.sh' output:

config.status: creating po/Makefile

Building GEGL with prefix=/opt/gimp-default-master

Optional features:
  GEGL docs:   yes
  Build workshop:  no
  Build website:   yes
  SIMD:    sse:yes mmx:yes
  Vala support:    yes

Optional dependencies:
  asciidoc:    yes
  enscript:    no  (enscript not found)
  mrg: no  (mrg not found)
  Ruby:    yes
  Lua: yes
  Cairo:   yes
  Pango:   no  (usable pango not found)
  pangocairo:  no  (usable pangocairo not found)
  GDKPixbuf:   no  (gdk-pixbuf not found)
  JPEG:    yes
  PNG: yes
  OpenEXR: yes
  rsvg:    yes
  SDL: yes
  libraw:  no  (libraw library not found)
  Jasper:  yes
  graphviz:    no  (graphviz not found)
  avformat:    no  (sufficiently new libavformat / libavcodec or 
libswcale not found)

  V4L: no   (v4l library not found)
  V4L2:    no  (usable libv4l2 not found)
  spiro:   yes
  EXIV:    yes
  gexiv2:  yes
  umfpack: yes
  TIFF yes
  webp:    no  (webp library not found)
  poly2tri-c:  yes (internal)

We have optional dependencies not resolved... it seems that they are 
'optional', correct!

ciao e thanks
americo

___
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] GEGL errors during 'make' process

[Jehan Pagès]

On Sun, Feb 4, 2018 at 1:14 AM, Americo Gobbo  wrote:
> Hi Jehan,
>
> On 03/02/2018 22:06, Jehan Pagès wrote:
>>
>> Hi!
>>
>> On Sun, Feb 4, 2018 at 12:59 AM, Americo Gobbo 
>> wrote:
>>>
>>> Hi Jehan,
>>> I have used the git repository to build.
>>> config.log is of my traditional environment to gegl
>>> config-new.log is of a ex-novo environment to gegl to test if was making
>>> something wrong in the traditional env.
>>
>> Both seem fine. pkg-config does not seem to detect any exiv2 in
>> /usr/local/.
>> Are the build still broken and outputting the same errors?
>>
>> Jehan
>
> This is final of my 'make' messages:
>
>   CCLD gegl
> libtool:   error: cannot find the library '/usr/local/lib/libexiv2.la' or
> unhandled argument '/usr/local/lib/libexiv2.la'
> Makefile:571: recipe for target 'gegl' failed
> make[2]: *** [gegl] Error 1
> make[2]: Leaving directory '/home/jag/devel/gimp-default-master-/gegl/bin'
> Makefile:634: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/jag/devel/gimp-default-master-/gegl'
> Makefile:541: recipe for target 'all' failed
> make: *** [all] Error 2
> ---
>
> In fact the archives are installed in another directory
>
> '/usr/lib/x86_64-linux-gnu/' instead that '/usr/local/lib/'

Well I'm lost. Are you sure you did a build from a fresh start? No
files at all from a previous build?
You can run `git clean -dfx` to erase every file from the repository
which are not in git (be careful not to run it carelessly and erase
important personal files!).

Other than this, I really have no idea with only this.
But if you still have the error, please run `make V=1`. This will make
the build verbose and tell exactly which command was run. But first,
you should make sure you did a fresh build, really from scratch.

Jehan

-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
___
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] GEGL errors during 'make' process

[Americo Gobbo]

Hi Jehan,

On 03/02/2018 22:06, Jehan Pagès wrote:

Hi!

On Sun, Feb 4, 2018 at 12:59 AM, Americo Gobbo  wrote:

Hi Jehan,
I have used the git repository to build.
config.log is of my traditional environment to gegl
config-new.log is of a ex-novo environment to gegl to test if was making
something wrong in the traditional env.

Both seem fine. pkg-config does not seem to detect any exiv2 in /usr/local/.
Are the build still broken and outputting the same errors?

Jehan

This is final of my 'make' messages:

  CCLD gegl
libtool:   error: cannot find the library '/usr/local/lib/libexiv2.la' 
or unhandled argument '/usr/local/lib/libexiv2.la'

Makefile:571: recipe for target 'gegl' failed
make[2]: *** [gegl] Error 1
make[2]: Leaving directory '/home/jag/devel/gimp-default-master-/gegl/bin'
Makefile:634: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/jag/devel/gimp-default-master-/gegl'
Makefile:541: recipe for target 'all' failed
make: *** [all] Error 2
---

In fact the archives are installed in another directory

'/usr/lib/x86_64-linux-gnu/' instead that '/usr/local/lib/'

___
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] GEGL errors during 'make' process

[Jehan Pagès]

Hi!

On Sun, Feb 4, 2018 at 12:59 AM, Americo Gobbo  wrote:
> Hi Jehan,
> I have used the git repository to build.
> config.log is of my traditional environment to gegl
> config-new.log is of a ex-novo environment to gegl to test if was making
> something wrong in the traditional env.

Both seem fine. pkg-config does not seem to detect any exiv2 in /usr/local/.
Are the build still broken and outputting the same errors?

Jehan

> ciao
> americo
>
>
>
> On 03/02/2018 21:38, Jehan Pagès wrote:
>>
>> Were you building inside the git repository or in a separate
>> directory? In the second case, make sure the build directory is empty.
>> Could you send us the contents of "config.log"? Since gexiv2 and exiv2
>> are looked up with pkg-config, it will allow us to see what was
>> detected too.
>>
>> Since you can't attach a file, just copy-paste its contents somewhere,
>> for instance athttps://paste.gnome.org/
>> Thanks!
>
>



-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
___
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] GEGL errors during 'make' process

[Americo Gobbo]

Hi Tobias,
thanks!

On 03/02/2018 08:40, Tobias Ellinghaus wrote:

Am Samstag, 3. Februar 2018, 03:13:18 CET schrieb Americo Gobbo:

Hi All,
I have upgrade my system to ubuntu gnome 16.04.3 and I have tried again
compile GEGL. The 'autogen.sh' is finished OK, without problems.
The 'make' process have these errors messages:

gcc: error: /usr/local/lib/libexiv2.so: No such file or directory
Makefile:571: recipe for target 'gegl' failed
make[2]: *** [gegl] Error 1
make[2]: Leaving directory '/home/jag/devel/gimp-default-master/gegl/bin'
Makefile:634: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/jag/devel/gimp-default-master/gegl'
Makefile:541: recipe for target 'all' failed
make: *** [all] Error 2

Someone can give some suggestion?

Is that a fresh git clone or did you compile in the directory before? Maybe
you used to have libexiv2 installed in/usr/local/  and that was picked up by
autofoo in the past and now it still remembers the old location.

Yes, because them are in another directory: /usr/lib/x86_64-linux-gnu
So, how is possible resolve this without 'ln -s', also because it does 
not work?


Linking libraries around (using ln -s, not ld) is not the solution and a
terrible idea.


correct.

___
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] GEGL errors during 'make' process

[Tobias Ellinghaus]

Am Samstag, 3. Februar 2018, 03:13:18 CET schrieb Americo Gobbo:
> Hi All,
> I have upgrade my system to ubuntu gnome 16.04.3 and I have tried again
> compile GEGL. The 'autogen.sh' is finished OK, without problems.
> The 'make' process have these errors messages:
> 
> gcc: error: /usr/local/lib/libexiv2.so: No such file or directory
> Makefile:571: recipe for target 'gegl' failed
> make[2]: *** [gegl] Error 1
> make[2]: Leaving directory '/home/jag/devel/gimp-default-master/gegl/bin'
> Makefile:634: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/jag/devel/gimp-default-master/gegl'
> Makefile:541: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> Someone can give some suggestion?

Is that a fresh git clone or did you compile in the directory before? Maybe 
you used to have libexiv2 installed in /usr/local/ and that was picked up by 
autofoo in the past and now it still remembers the old location.

Linking libraries around (using ln -s, not ld) is not the solution and a 
terrible idea.

> Thanks
> americo

Tobias

signature.asc
Description: This is a digitally signed message part.
___
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] GEGL errors during 'make' process

[Partha Bagchi]

Americo,

Just make a symlink to get past the error. Something like:

ln -s /usr/lib/x86_64-linux-gnu/libgexiv2.so /usr/local/lib/libgexiv2.so

etc.

Though, linux systems use the silly "la" files, and so this may not work.
Better to check and see if it does work. Otherwise, yes, modify your
LDFLAGS.


On Fri, Feb 2, 2018 at 10:59 PM, Americo Gobbo 
wrote:

> Hi Partha,
> in my system these libraries are in:
>
> /usr/lib/x86_64-linux-gnu/libgexiv2.a
> /usr/lib/x86_64-linux-gnu/libgexiv2.so
>
> instead that in '/usr/local/lib/libexiv2.la'
>
> On 03/02/2018 01:46, Partha Bagchi wrote:
>
>> Hi Americo,
>>
>> What does
>> find / -name "libgexiv*.so"
>> say?
>>
>> Since I don't know how your ld.conf is setup, I am trying to guess where
>> your shared objects are. Once you find them, instead of relying on the
>> system, you can pass them directly to GIMP/GEGL while making using
>> LDFLAGS="-L/usr/lib/lib64" etc.
>>
> Perhaps I need modify my setup environment?
>
> my setup script is:
>
> less ../setup-master.sh
> PREFIX=/opt/gimp-default-master
> export PATH=$PREFIX/bin:$PATH
> export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH
> export XDG_DATA_DIRS=$PREFIX/share:$XDG_DATA_DIRS
> export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal"
> export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
> export GIO_EXTRA_MODULES=/usr/lib/x86_64-linux-gnu/gio/modules
> export SRC_DIR=$HOME/devel/gimp-default-master/gimp-2.9/build
> export CFLAGS='-std=gnu99 -fPIC'
> export LESS="-F -X -R"
>
>
___
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] GEGL errors during 'make' process

[Americo Gobbo]

Hi Partha,
in my system these libraries are in:

/usr/lib/x86_64-linux-gnu/libgexiv2.a
/usr/lib/x86_64-linux-gnu/libgexiv2.so

instead that in '/usr/local/lib/libexiv2.la'

On 03/02/2018 01:46, Partha Bagchi wrote:

Hi Americo,

What does
find / -name "libgexiv*.so"
say?

Since I don't know how your ld.conf is setup, I am trying to guess where
your shared objects are. Once you find them, instead of relying on the
system, you can pass them directly to GIMP/GEGL while making using
LDFLAGS="-L/usr/lib/lib64" etc.

Perhaps I need modify my setup environment?

my setup script is:

less ../setup-master.sh
PREFIX=/opt/gimp-default-master
export PATH=$PREFIX/bin:$PATH
export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH
export XDG_DATA_DIRS=$PREFIX/share:$XDG_DATA_DIRS
export ACLOCAL_FLAGS="-I $PREFIX/share/aclocal"
export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
export GIO_EXTRA_MODULES=/usr/lib/x86_64-linux-gnu/gio/modules
export SRC_DIR=$HOME/devel/gimp-default-master/gimp-2.9/build
export CFLAGS='-std=gnu99 -fPIC'
export LESS="-F -X -R"

___
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] GEGL errors during 'make' process

[Partha Bagchi]

Hi Americo,

What does
find / -name "libgexiv*.so"
say?

Since I don't know how your ld.conf is setup, I am trying to guess where
your shared objects are. Once you find them, instead of relying on the
system, you can pass them directly to GIMP/GEGL while making using
LDFLAGS="-L/usr/lib/lib64" etc.


On Fri, Feb 2, 2018 at 10:31 PM, Americo Gobbo 
wrote:

> Hi Partha,
>
> ~$ pkg-config --libs exiv2
> -lexiv2
> ~$ pkg-config --libs gexiv2
> -lgexiv2 -lgobject-2.0 -lglib-2.0
>
>
> On 03/02/2018 01:27, Partha Bagchi wrote:
>
>> I see. So what does
>>
>> pkg-config --libs exiv2
>>
>> or
>>
>> pkg-config --libs gexiv2
>>
>>
>> say?
>>
>
>
>
___
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] GEGL errors during 'make' process

[Americo Gobbo]

Hi Partha,

~$ pkg-config --libs exiv2
-lexiv2
~$ pkg-config --libs gexiv2
-lgexiv2 -lgobject-2.0 -lglib-2.0

On 03/02/2018 01:27, Partha Bagchi wrote:

I see. So what does

pkg-config --libs exiv2

or

pkg-config --libs gexiv2


say?



___
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] GEGL errors during 'make' process

[Partha Bagchi]

I see. So what does

pkg-config --libs exiv2

or

pkg-config --libs gexiv2


say?


On Fri, Feb 2, 2018 at 10:11 PM, Americo Gobbo 
wrote:

> Hi Partha,
> thanks!
> So, in my system gexiv2 and exiv2 are installed.
>
> $ sudo apt-get install libexiv2-dev libgexiv2-dev
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> libgexiv2-dev is already the newest version (0.10.3-2).
> libexiv2-dev is already the newest version (0.25-2.1ubuntu16.04.1).
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
> It seems that doesn't find in the folder that the autogen.sh is indicating?
>
> libtool:   error: cannot find the library '/usr/local/lib/libexiv2.la' or
> unhandled argument '/usr/local/lib/libexiv2.la'
> Makefile:571: recipe for target 'gegl' failed
> make[2]: *** [gegl] Error 1
> make[2]: Leaving directory '/home/jag/devel/gimp-default-master/gegl/bin'
> Makefile:634: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/jag/devel/gimp-default-master/gegl'
> Makefile:541: recipe for target 'all' failed
> make: *** [all] Error 2
>
> On 03/02/2018 00:32, Partha Bagchi wrote:
>
>> Americo,
>>
>> I don't know about your system, but you need to make sure that you have
>> gexiv2 and exiv2 (including dev files) installed in your system.
>>
>> Partha
>>
>
>
___
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] GEGL errors during 'make' process

[Americo Gobbo]

Hi Partha,
thanks!
So, in my system gexiv2 and exiv2 are installed.

$ sudo apt-get install libexiv2-dev libgexiv2-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libgexiv2-dev is already the newest version (0.10.3-2).
libexiv2-dev is already the newest version (0.25-2.1ubuntu16.04.1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

It seems that doesn't find in the folder that the autogen.sh is indicating?

libtool:   error: cannot find the library '/usr/local/lib/libexiv2.la' 
or unhandled argument '/usr/local/lib/libexiv2.la'

Makefile:571: recipe for target 'gegl' failed
make[2]: *** [gegl] Error 1
make[2]: Leaving directory '/home/jag/devel/gimp-default-master/gegl/bin'
Makefile:634: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/jag/devel/gimp-default-master/gegl'
Makefile:541: recipe for target 'all' failed
make: *** [all] Error 2

On 03/02/2018 00:32, Partha Bagchi wrote:

Americo,

I don't know about your system, but you need to make sure that you have
gexiv2 and exiv2 (including dev files) installed in your system.

Partha


___
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

[Gimp-developer] GEGL errors during 'make' process

[Americo Gobbo]

Hi All,
I have upgrade my system to ubuntu gnome 16.04.3 and I have tried again compile 
GEGL.
The 'autogen.sh' is finished OK, without problems.
The 'make' process have these errors messages:

gcc: error: /usr/local/lib/libexiv2.so: No such file or directory
Makefile:571: recipe for target 'gegl' failed
make[2]: *** [gegl] Error 1
make[2]: Leaving directory '/home/jag/devel/gimp-default-master/gegl/bin'
Makefile:634: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/jag/devel/gimp-default-master/gegl'
Makefile:541: recipe for target 'all' failed
make: *** [all] Error 2

Someone can give some suggestion?



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

___
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

[Gimp-developer] GEGL compilation in the last git update

[Americo Gobbo]

Hi All,
I am trying to update GIMP devel master and in this moment I have problems to 
update GEGL.
I have resolved the dependencies and mainly gettext.
The final messages that are appearing when I try do 'autogen.sh' are:

Copying file po/remove-potcdate.sin
autoreconf: running: aclocal --force -I m4 ${ACLOCAL_FLAGS}
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
configure.ac:785: error: possibly undefined macro: AC_CHECK_LIB
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
checking whether make supports nested variables... yes
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." 
"./../.."


Someone can help me with some suggestion.

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

___
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

[Gimp-developer] GEGL-0.3.12 and babl-0.1.24

[Øyvind Kolås]

GEGL provides a node/graph based API and framework for cached, interactive
non-destructive image processing. GEGLs data flow image processing graphs are
used by GIMP and other software like gnome-photos, imgflo and iconographer.

Highlights of changes in this release:

Core:
 • less locale dependent serializations/parameters
 • fix local raw file detection of ARW and CR2 files
 • gegl_memset_pattern performance improvement
 • clean up the way we drop references and free memory
 • static caching of some frequently used babl formats/types.
 • mipmap preview render code fixes for the following subset of
operations: point
   operations (filter, and composer subclasses), integer translate, crop.

Operations:
• new ops: edge-neon, image-gradient, slic, wavelet-blur, waterpixels, watershed
• moved from workshop to common: color-warp, component-extract
• text: remove now unneeded work-around, ability to control vertical
   positioning, permit <1.0 font-sizes, handle text-color alpha, other
   improvements.
• lens-distortion: default to transparent background
• crop: bounding box computation simplifications
• noise-rgb: add gamma and distribution properties
• dither: renamed from color-reduction and improved ui/property controls.
• high-pass: do inversion, over and contrast in non-linear RGB
• noise-rgb: new linear and gaussian properties
• transform: added a clip-to-input property
• raw-load: improvements to handling of Sony's ARW files
• exposure: replaced offset with black-level
• moved from common to workshop: bilateral-filter-fast
• new workshop ops: bayer-matrix, linear-sinusoid,
 shadows-highlights, integral-image, segment-kmeans,
• removed ops: gaussian-blur-old

To build gegl-0.3.12 you will also need babl-0.1.24 which has recently been
released with various new performance short-cuts and profiling cache
improvements.

This release of GEGL was brought to you through contributions from:

Piotr Drąg, Marco Ciampa, Sergey "Shnatsel" Davidoff, Ell, Michael Hennig,
Anders Jonsson, Christian Kirbach, Øyvind Kolås, Thomas Manni, Jordi Mas,
Michael Natterer, Jon Nordby, Peter O'Regan, Jehan Pagès, Sebastian Rasmussen,
Debarshi Ray, Dimitris Spingos (Δημήτρης Σπίγγος), Martin Srebotnjak, Elle
Stone and Miroslav Talasek.

Where to get GEGL:

The latest versions of GEGL and it's hard dependencies babl and glib can be
fetched from:

http://download.gimp.org/pub/babl/0.1/babl-0.1.24.tar.bz2
http://download.gimp.org/pub/gegl/0.3/gegl-0.3.12.tar.bz2

SHA256 sums of the released tarballs:

472bf1acdde5bf076e6d86f3004eea4e9b007b1377ab305ebddec4f29d0b
babl-0.1.24.tar.bz2
62eb08d7dd6ac046953a0bf606a71f9d14c9016ffef4ef7273b07b598f14bec7
gegl-0.3.12.tar.bz2

More information about GEGL can be found at the GEGL website, http://gegl.org/
or by joining #gegl and #gimp on the GIMPnet IRC network.

Have fun coding and image processing

Øyvind Kolås -– http://pippin.gimp.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

[Gimp-developer] GEGL-0.3.2

[Øyvind Kolås]

GEGL (Generic Graphics Library) is a graph based image processing framework.

GEGL provides a graph based API and framework to do demand driven, cached, non
destructive image editing of sparse storage of larger than RAM images - using
CPU or GPU processing. Through babl it provides support for a wide, and
extendable, range of color models and pixel storage formats for input and
output.

To build gegl-0.3.2 you will also need babl-0.1.14 and a recent version of glib,
follow see the output of the configure script for details and optional
dependencies.

Changes in this release:

 • Operations:
   • new operations: libraw based raw loading op, tiff-save and
tif-load, maze, sepia
   • ff-load and ff-save revived, with support from thegrid.io
   • apply-lens uses less memory, higher precision computation.
   • disable automatic threading on many ops where it fails
   • force more operations to prefer operating on linear RGB data for more
 accurate/physical processing.
 • Buffer:
   • implement abyss paremeter on gegl_buffer_copy and gegl_buffer_blit
 • Added start of a microraptor gui based image viewer/non destructive editor.
 • Optimizations to scaled blitting (speeds up most GEGL UIs a bit)

This release brought to you through contribution from:

 Alexandre Prokoudine, André Tupinambá, Claude Paroz, Daniel Mustieles,
 Debarshi Ray, Dimitris Spingos, Elle Stone, Jehan, Jordi Mas, Marco Ciampa,
 Martin Blanchard, Martin Srebotnjak, Massimo Valentini, Michael Henning,
 Michael Natterer, Necdet Yücel, Pedro Albuquerque, Piotr Drąg, Roman Lebedev,
 Sven Neumann, Thomas Manni, Vilson Vieira, akash akya and Øyvind Kolås.

Where to get GEGL:

The latest versions of GEGL and it's hard dependencies babl and glib can be
fetched from:

http://download.gimp.org/pub/babl/0.1/babl-0.1.14.tar.bz2
http://download.gimp.org/pub/gegl/0.3/gegl-0.3.2.tar.bz2

SHA-1 sums of the released tarballs:

1e1e27a9a07da95e905d07816701b2efaf5611af  babl-0.1.14.tar.bz2
c308b9994f9649bfbdf1bb63db6fbe0ba19632bd  gegl-0.3.2.tar.bz2

Where to get more information about GEGL

More information about GEGL can be found at the GEGL website,
http://gegl.org/ or by joining #gegl and #gimp on the IRC network
GIMPnet.

Enjoy the goats /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

[Gimp-developer] GEGL-0.3.0 babl-0.1.12

[Øyvind Kolås]

GEGL (Generic Graphics Library) is a graph based image processing framework.

GEGL provides a graph based API and framework to do demand driven, cached, non
destructive image editing of sparse storage of larger than RAM images
- using CPU or GPU
processing. Through babl it provides support for a wide, and extendable, range
of color models and pixel storage formats for input and output.

To build gegl-0.3.0 you will also need babl-0.1.12 and a recent version of glib,
follow see the output of the configure script for details.

Changes in this release:

 • Improvements to thread safety and parallelism.
 • Lower overhead graph travesal due from rewrite of visitors
 • OpenCL support now enabled by default when detected.
 • Experimental multithreading, enable by setting
   GEGL_THREADS=number of threads in the environment.
 • Experimental mipmap rendering, which permits transparent rendering of
   previews on smaller sized versions, enable by setting
   GEGL_MIPMAP_RENDERING=true in the environment.
 • Website/documentation: split website in more pages, added op
gallery and API browser.
 • Operations:
   • new operations: alien-map, antialias, apply-lens, bilateral-filter,
 bump.map, cartoon, channel-mixer, color-enhance, color-exchange,
 color-reduction, color-rotate, convolution-matrix, copy-buffer, cubism,
 deinterlace, diffraction-patterns, distance-transform, displace, edge,
 emboss, engrave, exposure, fractal-trace, high-pass, image-compare,
 illusion, invert-gamma, lens-flare, linear, linear-gradient, mosaic,
 motion-blur-circular, motion-blur-zoom, noise-cell noise-cie-lch,
 noise-hsv, noise-hurl, noise-pick, noise-rgb, noise-simplex, noise-spread,
 n-point deformation ops, oilify, panorama-projection, photocopy, plasma,
 radial-gradient, red-eye-removal, scale-size-keep-aspect, softglow,
 stretch-contrast, texturize-canvas, tile-glass, tile-seamless, tile-paper,
 tile, warp, whirl-pinch, wind, cache, cast-format, lcms-from-profile,
 npy-save, webp-load, webp-save, scale-ratio, scale-size, seamless-clone,
 sinus, supernova, value-propagate, video-degradation
   • reimplementation of gaussian-blur faster and more accurate
   • support for using URIs in image loaders
 • Buffer:
   • New default tile backend, doing disk writes in a separate thread.

This release of GEGL was brought to you through contributions from:

  Albert F, Alexandre Prokoudine, Alexia Death, Akash Akya, Anders Jonsson,
  Andika Triwidada, Andreas Fischer, Angh, Awaw Fumin, Barak Itkin, Bruce
  Cowan, Carlos Zubieta, Cédric Valmary, Chris Leonard, Christian Kirbach,
  Clayton Walker, Daniel Mustieles, Daniel Nylander, Daniel Sabo, Debarshi Ray,
  Denis Knoepfle, Dimitris Papavasiliou, Dimitris Spingos, Djavan Fagundes, Dov
  Grobgeld, Elle Stone, Enrico Nicoletto, Felix Ulber, Florian Klemme,
  Francisco Vila, Fran Diéguez, Georges Basile Stavracas Neto, Hans Lo, Harald
  Korneliussen, Hartmut Kuhse, Inaki Larranaga Murgoitio, Isaac Wagner, Jan
  Vesely, Jan Vesely, Jehan, Jon Nordby, Jordi Mas, Kalev Lember, Kristjan
  Schmidt, Marco Ciampa, Marek Dvoroznak, Maria Mavridou, Martijn van Beers,
  Martin Nordholts, Martin Srebotnjak, Massimo Valentini, Matej Urbančič,
  Maxime Nicco, Michael Henning, Michael Muré, Michael Natterer, Mikael
  Magnusson, Miroslav Talasek, Muhammet Kara, Mukund Sivaraman, Nana Chery,
  Nick Black, Nicolas Robidoux, Nils Philippsen, Norm Murray, Pascal Giessler,
  Piotr Drąg, Quentin Glidic, Rafael Ferreira, Rasmus, RPG, Rūdolfs Mazurs,
  Samir Ribic, Samuel Pitoiset, sebul, Simon Budig, Sven Claussner, Téo Mazars,
  Thomas Manni, Tim Lunn, Tim Mooney, Ting-Wei Lan, Tom Stellard, Ulf-D.
  Ehlert, Vadim Rutkovsky, Victor Oliveira, Ville Sokk, Vincent Untz, Yongjia
  Zhang, Yongjia Zhang, Øyvind Kolås and 周 周.


Where to get GEGL:

The latest versions of GEGL and it's hard dependencies babl and glib can be
fetched from:

http://download.gimp.org/pub/babl/0.1/babl-0.1.12.tar.bz2
http://download.gimp.org/pub/gegl/0.3/gegl-0.3.0.tar.bz2

SHA-1 sums of the released tarballs:

d6b77996740bc885fd42f5c639c9d3fce6211855  gegl-0.3.0.tar.bz2
b9a811d9d05717d66bc107a18447fbd74cff7eea  babl-0.1.12.tar.bz2

Where to get more information about GEGL

More information about GEGL can be found at the GEGL website,
http://gegl.org/ or by joining #gegl and #gimp on the IRC network
GIMPnet.

Have more fun =) /Øyvind Kolås
___
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

[Gimp-developer] gegl bug in git master

[Thorsten Stettin]

Hai,

sorry, but I'm too stupid to use bugzilla. :-[

Here is my bug report:

commit 89775bd29970ca26961b5b5bc49f500f696b4d76
Author: Jon Nordby jono...@gmail.com
Date:   Mon Jan 19 23:51:18 2015 +0100

gegl-init: Split out module directory logic to function

This commit leads to a wrong gegl module search path.
Gimp are unable to find the gegl modules.

Workaround: export GEGL_PATH=/usr/lib/x86_64-linux-gnu/gegl-0.3 before 
starting Gimp 2.9.1


OS: Ubuntu Linux 14.10 64 bit.

Cheers

PS: In my latest PPA build I reverted gegl/gegl-init.c. Now it works.

--
Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die 
Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige 
ist fähig zu herrschen.


___
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] gegl bug in git master

[Thorsten Stettin]

Am 20.01.2015 um 19:46 schrieb Thorsten Stettin:

Am 20.01.2015 um 18:50 schrieb Jon Nordby:

Hi Thorsten,
thanks for reporting. This should be fixed now:

commit 51621f9fb36d37556162ad514dc1492d84270d7e
Author: Jon Nordby jono...@gmail.com mailto:jono...@gmail.com
Date:   Tue Jan 20 18:27:42 2015 +0100

gegl-init: Fix only returning GEGL_PATH for module directories


With glib-json I got a segmentation fault only for the amd64 builds on 
Ubuntu launchpad.net.

I'll try to build gegl at home on my 64 bit machine. :-(

https://launchpadlibrarian.net/195412174/buildlog_ubuntu-trusty-amd64.gegl_1%3A0.2.99.207-0trusty6~ppa_FAILEDTOBUILD.txt.gz





On 20 January 2015 at 17:47, Thorsten Stettin 
thorsten.stet...@gmail.com mailto:thorsten.stet...@gmail.com wrote:


Hai,

sorry, but I'm too stupid to use bugzilla. :-[

Here is my bug report:

commit 89775bd29970ca26961b5b5bc49f500f696b4d76
Author: Jon Nordby jono...@gmail.com mailto:jono...@gmail.com
Date:   Mon Jan 19 23:51:18 2015 +0100

gegl-init: Split out module directory logic to function

This commit leads to a wrong gegl module search path.
Gimp are unable to find the gegl modules.

Workaround: export GEGL_PATH=/usr/lib/x86_64-linux-gnu/gegl-0.3
before starting Gimp 2.9.1

OS: Ubuntu Linux 14.10 64 bit.

Cheers

PS: In my latest PPA build I reverted gegl/gegl-init.c. Now it works.

-- 
Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu

schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der
dritte ist die Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur
der Demütige ist fähig zu herrschen.





--
Jon Nordby - www.jonnor.com http://www.jonnor.com



--
Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die 
Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige 
ist fähig zu herrschen.



--
Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die 
Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige 
ist fähig zu herrschen.

___
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] gegl bug in git master

[Thorsten Stettin]

Am 20.01.2015 um 18:50 schrieb Jon Nordby:

Hi Thorsten,
thanks for reporting. This should be fixed now:

commit 51621f9fb36d37556162ad514dc1492d84270d7e
Author: Jon Nordby jono...@gmail.com mailto:jono...@gmail.com
Date:   Tue Jan 20 18:27:42 2015 +0100

gegl-init: Fix only returning GEGL_PATH for module directories


With glib-json I got a segmentation fault only for the amd64 builds on 
Ubuntu launchpad.net.

I'll try to build gegl at home on my 64 bit machine. :-(




On 20 January 2015 at 17:47, Thorsten Stettin 
thorsten.stet...@gmail.com mailto:thorsten.stet...@gmail.com wrote:


Hai,

sorry, but I'm too stupid to use bugzilla. :-[

Here is my bug report:

commit 89775bd29970ca26961b5b5bc49f500f696b4d76
Author: Jon Nordby jono...@gmail.com mailto:jono...@gmail.com
Date:   Mon Jan 19 23:51:18 2015 +0100

gegl-init: Split out module directory logic to function

This commit leads to a wrong gegl module search path.
Gimp are unable to find the gegl modules.

Workaround: export GEGL_PATH=/usr/lib/x86_64-linux-gnu/gegl-0.3
before starting Gimp 2.9.1

OS: Ubuntu Linux 14.10 64 bit.

Cheers

PS: In my latest PPA build I reverted gegl/gegl-init.c. Now it works.

-- 
Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu

schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der
dritte ist die Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur
der Demütige ist fähig zu herrschen.





--
Jon Nordby - www.jonnor.com http://www.jonnor.com



--
Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die 
Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige 
ist fähig zu herrschen.

___
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] gegl bug in git master

[Jon Nordby]

Hi Thorsten,
thanks for reporting. This should be fixed now:

commit 51621f9fb36d37556162ad514dc1492d84270d7e
Author: Jon Nordby jono...@gmail.com
Date:   Tue Jan 20 18:27:42 2015 +0100

gegl-init: Fix only returning GEGL_PATH for module directories



On 20 January 2015 at 17:47, Thorsten Stettin thorsten.stet...@gmail.com
wrote:

 Hai,

 sorry, but I'm too stupid to use bugzilla. :-[

 Here is my bug report:

 commit 89775bd29970ca26961b5b5bc49f500f696b4d76
 Author: Jon Nordby jono...@gmail.com
 Date:   Mon Jan 19 23:51:18 2015 +0100

 gegl-init: Split out module directory logic to function

 This commit leads to a wrong gegl module search path.
 Gimp are unable to find the gegl modules.

 Workaround: export GEGL_PATH=/usr/lib/x86_64-linux-gnu/gegl-0.3 before
 starting Gimp 2.9.1

 OS: Ubuntu Linux 14.10 64 bit.

 Cheers

 PS: In my latest PPA build I reverted gegl/gegl-init.c. Now it works.

 --
 Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
 Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
 Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist
 die Demut.
 Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der
 Demütige ist fähig zu herrschen.





-- 
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] gegl bug in git master

[Thorsten Stettin]

Am 20.01.2015 um 18:50 schrieb Jon Nordby:

Hi Thorsten,
thanks for reporting. This should be fixed now:


Great! I'll check ist out in few minutes.



commit 51621f9fb36d37556162ad514dc1492d84270d7e
Author: Jon Nordby jono...@gmail.com mailto:jono...@gmail.com
Date:   Tue Jan 20 18:27:42 2015 +0100

gegl-init: Fix only returning GEGL_PATH for module directories



On 20 January 2015 at 17:47, Thorsten Stettin 
thorsten.stet...@gmail.com mailto:thorsten.stet...@gmail.com wrote:


Hai,

sorry, but I'm too stupid to use bugzilla. :-[

Here is my bug report:

commit 89775bd29970ca26961b5b5bc49f500f696b4d76
Author: Jon Nordby jono...@gmail.com mailto:jono...@gmail.com
Date:   Mon Jan 19 23:51:18 2015 +0100

gegl-init: Split out module directory logic to function

This commit leads to a wrong gegl module search path.
Gimp are unable to find the gegl modules.

Workaround: export GEGL_PATH=/usr/lib/x86_64-linux-gnu/gegl-0.3
before starting Gimp 2.9.1

OS: Ubuntu Linux 14.10 64 bit.

Cheers

PS: In my latest PPA build I reverted gegl/gegl-init.c. Now it works.

-- 
Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu

schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der
dritte ist die Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur
der Demütige ist fähig zu herrschen.





--
Jon Nordby - www.jonnor.com http://www.jonnor.com



--
Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die 
Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige 
ist fähig zu herrschen.

___
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] gegl bug in git master

[Thorsten Stettin]

Hi,

I could build the 64 bit gegl packages wihout any problem.

I hope this is a temporary problem at launchpad.net.

Cheers

___
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] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/16/2014 03:37 PM, Øyvind Kolås wrote:

On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

Is there in fact general agreement among the devs that the criteria for
deciding when to use sRGB primaries instead of UserRGB primaries is
approximately as follows?


the first thing we should do is to
annotate all the operations which are broken when done with sRGB
primaries


In other words, you will make a list of all operations that don't work 
in unbounded sRGB, and then you will convert from unbounded sRGB to 
UserRGB for those operations, and then back to unbounded sRGB. Good luck 
with that.



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.


As a maxim for guiding GIMP development, consistent results for the 
same property values / slider positions reflects a profound failure to 
understand the nature of RGB image editing and can only lead to bad code.


With respect,
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] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/14/2014 08:50 AM, Simon Budig wrote:

for conversions between RGB working spaces there is no fundamental
distinction between XYZ and unbounded linear gamma sRGB.


There is one fundamental difference between XYZ as the real PCS and 
sRGB as PCS (those are scare quotes; the terminology sRGB as PCS is 
misleading at best):


Worked out step by step:

It takes one matrix multiplication to get from UserRGB to XYZ. The 
required matrix A is contained in the UsrRGB ICC profile colorants.


It takes a second matrix multiplication to get from XYZ to sRGB. The 
required matrix C is the inverse of the matrix contained in the sRGB 
ICC profile colorants.


A and C are both defined in terms of XYZ.

Once you have matrix A for getting from UserRGB to XYZ and matrix C for 
getting from XYZ to sRGB, you can concantenate the two multiplications 
into one matrix multiplication. This is because matrix multiplication is 
associative:


C*(A*B) = (C*A)*B, where B is the UserRGB RGB values that will be 
converted to sRGB (linearized RGB data is assumed).


One matrix multiplication or two, you still get to the same place.

But the required one matrix to multiply first has to be *calculated* 
using *two* matrices, both of which are defined in terms of the real 
PCS, which is XYZ.


Then you have to store the result of C*A in memory for future use.

Pippin wants to go through sRGB as PCS to get to XYZ.

In a sane color-managed editing application, it takes one matrix 
multiplication to get from UserRGB to XYZ, using matrix A.


In Pippin's sRGB as PCS, first you convert from UserRGB to sRGB using 
the matrix that's the product of C*A, that you've previously stored 
somewhere in memory.


Then you convert from sRGB to XYZ using the inverse of C. Two 
conversions. Which of course can in turn be concantenated into one 
multiplication and also stored in memory for future use.


Kind 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] [Gegl-developer] babl roadmap

[Øyvind Kolås]

On Fri, Oct 17, 2014 at 12:01 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 On 10/16/2014 03:37 PM, Øyvind Kolås wrote:

 On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone
 ellest...@ninedegreesbelow.com wrote:

 Is there in fact general agreement among the devs that the criteria for
 deciding when to use sRGB primaries instead of UserRGB primaries is
 approximately as follows?


 the first thing we should do is to
 annotate all the operations which are broken when done with sRGB
 primaries


 In other words, you will make a list of all operations that don't work in
 unbounded sRGB, and then you will convert from unbounded sRGB to UserRGB for
 those operations, and then back to unbounded sRGB. Good luck with that.

 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.


 As a maxim for guiding GIMP development, consistent results for the same
 property values / slider positions reflects a profound failure to
 understand the nature of RGB image editing and can only lead to bad code.

No I am explaining how we will start out making these changes for
engineering reasons. How to follow a process that doesn't destabilize
and destroy what we already have. While your back-seat driving, asking
about detailed choices of side-roads 4 weeks from now on our road-trip
is not very productive when we're not even sure we'll be in the
country of those roads you want us to take – or if we will have
swapped the hummer for a jeep.
___
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] [Gegl-developer] babl roadmap

[Elle Stone]

In the current babl/GEGL/GIMP code base, I counted five files that 
contain functions that require a conversion from RGB to XYZ:


1. gimp/plug-ins/common/decompose.c
2. gimp/plug-ins/common/compose.c
3. gimp/app/core/gimpimage-convert-type.c
4. gegl/operations/common/image-compare.c
5. gegl/operations/common/noise-cie-lch.c

These five files use the babl file: babl/extensions/CIE.c

The babl/extensions/CIE.c code calculates the sRGB to XYZ matrix M, 
starting from the D65 unadapted sRGB color space red, green, blue, and 
white xy values.


Calculating M from xy values is a fairly complicated process. Study 
the equations on 
http://brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html and make 
sure to read note 2, which says Be careful that reference whites are 
used consistently. For example, sRGB is defined relative to a D65 
reference white and ICC profiles are defined relative to a D50 reference 
white. Mismatched reference whites must be accounted for elsewhere, 
typically by using a chromatic adaptation algorithm.


In an ICC profile D50-adapted color-managed workflow, you don't use the 
unadapted D65 sRGB M (that the babl code calculates) to get from sRGB 
to XYZ.


In an ICC profile color-managed workflow, you don't need to calculate 
the D50-adapted M for a matrix RGB working space, because you can read 
M directly from the ICC profile colorants.


There are two ways to fix the conversion to XYZ code in 
babl/extensions/CIE.c:


1. babl/extensions/CIE.c can be rewritten to use D50-adapted M 
retrieved directly from the UserRGB ICC profile colorants. Then convert 
to XYZ.


2. Or else you can use sRGB as PCS, which allows you to rewrite the 
code in babl/extensions/CIE.c to use hard-coded D50-adapted sRGB M. In 
this case:


i. Upon opening an image, first retrieve M from UserRGB (call this 
matrix A).
ii. Then retrieve M from sRGB and calculate the inverse (call this 
matrix C).

iii. Then calculate C*A and store this information in memory as D.
iv. Then convert from UserRGB to unbounded sRGB using the matrix D.
v. Then convert from unbounded sRGB to XYZ using the hard-coded 
D50-adapted sRGB M.


In an ICC profile color-managed workflow, sRGB is just another ICC 
working space profile. It doesn't need special treatment.


The right way to fix the babl conversion to XYZ is to rewrite 
babl/extensions/CIE.c to use M taken from the UserRGB ICC profile 
colorants. And forget about sRGB as PCS.


There may be a problem somewhere in the GIMP code for which sRGB as 
PCS might be a solution. Converting to XYZ is not one of those problems.


Kind 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] [Gegl-developer] babl roadmap

[Elle Stone]

Unfortunately for hard-coded sRGB as PCS, the ICC profile 
specifications are a moving target. Right now the ICC profile illuminant 
is always D50. But in the next planned release of new specifications, 
things will change:


//begin quote from http://color.org/DevCon/devcon14.xalter

While this fixed PCS is capable of delivering unambiguous color 
transforms, it cannot support the increasing demand for spectrally-based 
reproduction. iccMAX is a radically different approach which builds on 
ICC v4 but enables a far more flexible means of connecting devices, 
data, materials, observers and illuminants.


//end quote

I would ask every babl/GEGL/GIMP developer who cares about GIMP as a 
high end ICC profile color-managed image editor to read the rest of the 
page that I just linked to, and maybe think long and hard about whether 
you really want to limit yourself to babl color management based on 
hard-coded D50-adapted sRGB as PCS.


D65 unadapted sRGB is based on CRT technology that is no longer in 
widespread use. Rec.2020 is the up and coming new display device standard.


D50-adapted ICC profiles are based on profile specifications that 
revolve around increasing outdated print-based technologies. 
Print-making technologies have changed, and today the output device is 
just as (or more) likely to be a display screen.


The ICC is moving forward (and let's hope they also fix a few issues 
that V4 introduced).


Tying GIMP to sRGB as PCS is a dead-end move.

Kind 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] [Gegl-developer] babl roadmap

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 //begin quote from http://color.org/DevCon/devcon14.xalter
 
 While this fixed PCS is capable of delivering unambiguous color transforms,
 it cannot support the increasing demand for spectrally-based reproduction.
[...] 
 Tying GIMP to sRGB as PCS is a dead-end move.

If you take spectrally based reproduction as an argument against sRGB
as PCS you should be at least be so fair to also mention that *any* RGB
based image editing is bound to fail for this.

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] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/17/2014 06:39 AM, Simon Budig wrote:

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

//begin quote from http://color.org/DevCon/devcon14.xalter

While this fixed PCS is capable of delivering unambiguous color transforms,
it cannot support the increasing demand for spectrally-based reproduction.

[...]

Tying GIMP to sRGB as PCS is a dead-end move.


If you take spectrally based reproduction as an argument against sRGB
as PCS you should be at least be so fair to also mention that *any* RGB
based image editing is bound to fail for this.


In point of fact, I've already said thist. But I'm happy to say it 
again. RGB data is not spectral data.


Kind 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] [Gegl-developer] babl roadmap

[Øyvind Kolås]

On Fri, Oct 17, 2014 at 12:47 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

 Tying GIMP to sRGB as PCS is a dead-end move.

 If you take spectrally based reproduction as an argument against sRGB
 as PCS you should be at least be so fair to also mention that *any* RGB
 based image editing is bound to fail for this.

 In point of fact, I've already said thist. But I'm happy to say it again.
 RGB data is not spectral data.

As a former researcher at a national color science laboratory, and a
major contributor to babl and GEGL; I probably have no idea about
these things – and how the spectral data in named color ICCv4 profiles
might be used.

https://www.youtube.com/watch?v=vKpaXu87Coo

/Ø
___
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] [Gegl-developer] babl roadmap

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 On 10/17/2014 06:39 AM, Simon Budig wrote:
 Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 //begin quote from http://color.org/DevCon/devcon14.xalter
 
 While this fixed PCS is capable of delivering unambiguous color transforms,
 it cannot support the increasing demand for spectrally-based reproduction.
 [...]
 Tying GIMP to sRGB as PCS is a dead-end move.
 
 If you take spectrally based reproduction as an argument against sRGB
 as PCS you should be at least be so fair to also mention that *any* RGB
 based image editing is bound to fail for this.
 
 In point of fact, I've already said thist. But I'm happy to say it again.
 RGB data is not spectral data.

I know. Which is why your previous mail could have had the very same
text and the following sentence as the conclusion:

Tying GIMP to RGB based editing is a dead-end move.

Which is exactly the dead end you have been advocating a lot in the
recent discussion.

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] [Gegl-developer] babl roadmap

[Øyvind Kolås]

On Fri, Oct 17, 2014 at 1:06 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 On 10/17/2014 06:59 AM, Øyvind Kolås wrote:

 As a former researcher at a national color science laboratory, and a
 major contributor to babl and GEGL; I probably have no idea about
 these things – and how the spectral data in named color ICCv4 profiles
 might be used.

 https://www.youtube.com/watch?v=vKpaXu87Coo

 /Ø

 Nobody doubts your intelligence, acumen, or accomplishments. Not even me.

Then what is the purpose of continuing to endlessly perpetuate this
discussion, asking people to read about spectral color management,
when our roadmaps barely have good colorimetric management in scope?
For the sake of argument alone?
___
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] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/17/2014 07:08 AM, Øyvind Kolås wrote:

On Fri, Oct 17, 2014 at 1:06 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

On 10/17/2014 06:59 AM, Øyvind Kolås wrote:


As a former researcher at a national color science laboratory, and a
major contributor to babl and GEGL; I probably have no idea about
these things – and how the spectral data in named color ICCv4 profiles
might be used.

https://www.youtube.com/watch?v=vKpaXu87Coo

/Ø


Nobody doubts your intelligence, acumen, or accomplishments. Not even me.


Then what is the purpose of continuing to endlessly perpetuate this
discussion, asking people to read about spectral color management,
when our roadmaps barely have good colorimetric management in scope?
For the sake of argument alone?




I did not ask people to study spectral color management. I did ask 
people to realize that the ICC profile specs are changing. In 
particular, D50 will no longer be the only profile illuminant.


The point of this endless discussion is that unbounded sRGB is a 
singularly bad way to forcibly recast the user's RGB data for RGB image 
editing.


The code for converting to unbounded sRGB isn't yet in place.

At present, to get right results from babl/GEGL/GIMP, it would suffice 
to replace hard-coded sRGB Y and XYZ with UserRGB's Y and XYZ, and 
correct the babl code that converts to XYZ.


And of course it should be easy for the artist to switch at will between 
perceptually uniform and linear RGB.


For the very few RGB editing operations that really must be done using 
the sRGB primaries, write special code as appropriate and label the 
operations in the UI as sRGB only so the user knows what's happening.


The babl roadmap lays out a plan to complicate the existing code, 
apparently only to turn around and straighten it out again.


With respect,
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] [Gegl-developer] babl roadmap

[Øyvind Kolås]

On Fri, Oct 17, 2014 at 1:39 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 On 10/17/2014 07:08 AM, Øyvind Kolås wrote:

 On Fri, Oct 17, 2014 at 1:06 PM, Elle Stone
 ellest...@ninedegreesbelow.com wrote:

 On 10/17/2014 06:59 AM, Øyvind Kolås wrote:


 As a former researcher at a national color science laboratory, and a
 major contributor to babl and GEGL; I probably have no idea about
 these things – and how the spectral data in named color ICCv4 profiles
 might be used.

 https://www.youtube.com/watch?v=vKpaXu87Coo

 /Ø

 Nobody doubts your intelligence, acumen, or accomplishments. Not even me.


 Then what is the purpose of continuing to endlessly perpetuate this
 discussion, asking people to read about spectral color management,
 when our roadmaps barely have good colorimetric management in scope?
 For the sake of argument alone?

 The point of this endless discussion is that unbounded sRGB is a
 singularly bad way to forcibly recast the user's RGB data for RGB image
 editing.

 The code for converting to unbounded sRGB isn't yet in place.

 The babl roadmap lays out a plan to complicate the existing code, apparently
 only to turn around and straighten it out again.

What you see as complicating the existing code is normal when one does
something known as refactoring, the roadmap documents the road towards
the goal – and isn't even a complete roadmap since we don't know all
we will know when we are further along on it.

http://en.wikipedia.org/wiki/Code_refactoring

GIMP is not the only project using GEGL; nor is it the only user
interface on top of GEGL. GEGL pipelines need to be able to deal with
arbitrary counts of RGB spaces; which also GIMP need for having
multiple project use open and doing cross project copy-paste, clone
etc. One of the other GEGL UIs is this
http://libregraphicsworld.org/blog/entry/artificial-intelligence-designs-websites-uses-open-technology-stack

/Ø
___
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] [Gegl-developer] babl roadmap: How do you know which images are sRGB images?

[Elle Stone]

On 10/14/2014 07:16 AM, Øyvind Kolås wrote:

On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

On 10/13/2014 06:36 PM, Elle Stone wrote:
So again, upon opening an image, how do you plan to detect whether the image
is an sRGB image or not?



Will you compare MD5 checksums?
Will you consult the profile descriptions?
Will you examine the profile colorants and TRCs?


Most likely examination of profile colorants/TRCs since that is
what ICC or other color profile meta-data aware image loaders needs to
provide down to babl anyways.


You did pick the only plausible answer: check the colorants and TRCs.


In many
circumstances it is desirable to to treat almost sRGB as sRGB and
consider deviance from the real standard a mistake in labeling; for
instance if it is a low bitdepth image containing dithering - at other
times assuming that the slight off profile has been applied as is
earlier in the production pipeline might be desirable.


For most users, for most purposes, you as developer can probably decide 
for the user that slight off means close enough. The trouble is you 
don't know whether slight off is a mistake or intentional.


The profile maker might have used something other than Bradford 
adaptation to make the profile. This is allowed by the ICC specs, and 
would result in slightly different colorants.


The artist might be fully aware that the profile is not exactly like the 
GIMP built-in profile, and nonetheless intend to use the embedded sRGB 
profile instead of the GIMP built-in sRGB profile. Perhaps the existing 
gray axis needs to be preserved.


And so on. You think it's OK to second-guess and decide for the artist 
what happens to the artist's RGB data. But it's really not OK.


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] [Gegl-developer] babl roadmap: How do you know which images are sRGB images?

[Ed .]

Elle,

It is not the critic who counts; not the man who points out how the strong 
man stumbles, or where the doer of deeds could have done them better. The 
credit belongs to the man who is actually in the arena, whose face is marred 
by dust and sweat and blood; who strives valiantly; who errs, who comes 
short again and again, because there is no effort without error and 
shortcoming; but who does actually strive to do the deeds; who knows great 
enthusiasms, the great devotions; who spends himself in a worthy cause; who 
at the best knows in the end the triumph of high achievement, and who at the 
worst, if he fails, at least fails while daring greatly, so that his place 
shall never be with those cold and timid souls who neither know victory nor 
defeat.

 - Theodore Roosevelt

Time for you to stop making vaguely patronising remarks and make an 
actionable suggestion, or leave this.


Hugs and positivity,
Ed

-Original Message- 
From: Elle Stone

Sent: Friday, October 17, 2014 4:43 PM
Cc: gegl-developer-list ; Gimp-developer
Subject: Re: [Gimp-developer] [Gegl-developer] babl roadmap: How do you know 
which images are sRGB images?


On 10/14/2014 07:16 AM, Øyvind Kolås wrote:

On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone
ellest...@ninedegreesbelow.com wrote:

On 10/13/2014 06:36 PM, Elle Stone wrote:
So again, upon opening an image, how do you plan to detect whether the 
image

is an sRGB image or not?



Will you compare MD5 checksums?
Will you consult the profile descriptions?
Will you examine the profile colorants and TRCs?


Most likely examination of profile colorants/TRCs since that is
what ICC or other color profile meta-data aware image loaders needs to
provide down to babl anyways.


You did pick the only plausible answer: check the colorants and TRCs.


In many
circumstances it is desirable to to treat almost sRGB as sRGB and
consider deviance from the real standard a mistake in labeling; for
instance if it is a low bitdepth image containing dithering - at other
times assuming that the slight off profile has been applied as is
earlier in the production pipeline might be desirable.


For most users, for most purposes, you as developer can probably decide
for the user that slight off means close enough. The trouble is you
don't know whether slight off is a mistake or intentional.

The profile maker might have used something other than Bradford
adaptation to make the profile. This is allowed by the ICC specs, and
would result in slightly different colorants.

The artist might be fully aware that the profile is not exactly like the
GIMP built-in profile, and nonetheless intend to use the embedded sRGB
profile instead of the GIMP built-in sRGB profile. Perhaps the existing
gray axis needs to be preserved.

And so on. You think it's OK to second-guess and decide for the artist
what happens to the artist's RGB data. But it's really not OK.

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 


___
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] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/15/2014 01:46 PM, Simon Budig wrote:

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

On 10/15/2014 08:30 AM, Øyvind Kolås wrote:

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone

When the user opens a color-managed fooRGB image, for which *specific*
editing operations will the image be converted to unbounded sRGB?




As you very well know we don't *have* the specific list of editing
operations you ask for. I don't know why you keep repeating the
question. You seem to think that not getting an answer to that question
proves a point, but I definitely have no idea what the point is.


You make a very fair point. A better way to ask my question would have 
been By what criteria will the devs decide whether an RGB operation 
should use sRGB primaries instead of UserRGB primaries?


The babl roadmap says gamma slider and multiply compositing will be done 
using UserRGB. The roadmap's implied criteria for which RGB operations 
use sRGB primaries seems to be If it works in unbounded sRGB, use sRGB 
primaries; otherwise use UserRGB primaries.


If I understand them correctly, Michael Henning and Jon Norby are saying 
that the criteria is something along the lines of: For RGB editing 
operations, use UserRGB primaries *unless* there's a really, really good 
reason why only sRGB primaries will work.


Is there in fact general agreement among the devs that the criteria for 
deciding when to use sRGB primaries instead of UserRGB primaries is 
approximately as follows?


For RGB editing operations, use UserRGB primaries except in the rare 
cases for which only sRGB primaries will work.


Kind 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] [Gegl-developer] babl roadmap

[Øyvind Kolås]

On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 On 10/15/2014 01:46 PM, Simon Budig wrote:
 If I understand them correctly, Michael Henning and Jon Norby are saying
 that the criteria is something along the lines of: For RGB editing
 operations, use UserRGB primaries *unless* there's a really, really good
 reason why only sRGB primaries will work.

 Is there in fact general agreement among the devs that the criteria for
 deciding when to use sRGB primaries instead of UserRGB primaries is
 approximately as follows?

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.

/Ø
___
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] [Gegl-developer] babl roadmap

[Jon Nordby]

On 16 October 2014 21:37, Øyvind Kolås pip...@gimp.org wrote:

 On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone
 ellest...@ninedegreesbelow.com wrote:
  On 10/15/2014 01:46 PM, Simon Budig wrote:
  If I understand them correctly, Michael Henning and Jon Norby are saying
  that the criteria is something along the lines of: For RGB editing
  operations, use UserRGB primaries *unless* there's a really, really good
  reason why only sRGB primaries will work.
 
  Is there in fact general agreement among the devs that the criteria for
  deciding when to use sRGB primaries instead of UserRGB primaries is
  approximately as follows?

 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.


Hi pippin,
you are answering in detail 'how we will get there' but Elle (as I see
it) is asking more 'do you agree that we want to go there'. This leaves
me unsure if you are implicitly agreeing, if you disagree and have a
different there in mind, or if you think it is too early to decide this.

There being the goal that *eventually* in GEGL 'For RGB editing
operations, use UserRGB primaries *unless* there's a really, really good
reason why only sRGB primaries will work.'


-- 
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] [Gegl-developer] babl roadmap

[Øyvind Kolås]

On Fri, Oct 17, 2014 at 12:49 AM, Jon Nordby jono...@gmail.com wrote:
 you are answering in detail 'how we will get there' but Elle (as I see it)
 is asking more 'do you agree that we want to go there'. This leaves me
 unsure if you are implicitly agreeing, if you disagree and have a different
 there in mind, or if you think it is too early to decide this.

 There being the goal that *eventually* in GEGL 'For RGB editing
 operations, use UserRGB primaries *unless* there's a really, really good
 reason why only sRGB primaries will work.'

All of the above. I'm stating in detail how we will get as far as I
can see into the future; which will bring us closer to there. As
well as reasons it probably will not a be binary choice when we have
more knowledge of the capabilities and constraints. The level of
detail of the roadmap is in places already too high as it both tries
to document an intermediate state as well as hint at where we possibly
want to go from there - and bits of what it documents will probably
already be invalid by the time much of it is in place.

/Ø
___
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] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/14/2014 08:50 AM, Simon Budig wrote:

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



Are you planning on converting non-sRGB images to unbounded linear gamma
sRGB? Yes or no?


For pixel storage we will use whatever fits our needs, it does not make
sense at this point to specify this.


Whether or not the roadmap calls for converting non-sRGB images to 
unbounded sRGB will determine what kind of code is written going forward.


In an ICC profile color-managed workflow, sRGB is just another RGB 
working space, requiring no special treatment.


The babl roadmap sRGB as PCS/fooRGB is a proposed solution to 
perceived problems. The problems for which sRGB as PCS/fooRGB might be 
a solution are things like:


*Reducing computing overhead for 8-bit sRGB image editing.
*Accomodating legacy sRGB XCF files.
*Accomodating legacy sRGB only file formats.

Solving legacy and 8-bit sRGB overhead problems does not require 
converting ICC profile color-managed images from fooRGB to unbounded sRGB.



If yes, are you intending that at least some editing will be done on the
image while it's encoded using sRGB primaries? Yes or no?


That totally depends on the editing-operation in question


When the user opens a color-managed fooRGB image, for which *specific* 
editing operations will the image be converted to unbounded sRGB?


This isn't just an implementation detail. The answer to this question 
will determine the path for writing code going forward. To restate the 
question yet again:


Will all color-managed image editing be done using the user's chosen 
primaries, with absolutely no conversions to unbounded sRGB for image 
editing?


Or are the developers committing themselves to maintaining lists of 
which operations should be done using fooRGB primaries and which should 
be done using sRGB primaries?


With respect,
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] [Gegl-developer] babl roadmap

[Øyvind Kolås]

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone
 When the user opens a color-managed fooRGB image, for which *specific*
 editing operations will the image be converted to unbounded sRGB?

 This isn't just an implementation detail. The answer to this question will
 determine the path for writing code going forward. To restate the question
 yet again:

If the user is putting a text-layer, which has been rendered using
cairo and is in 8bit sRGB premultiplied alpha. The compositing of this
with preceding data in the layer stack the babl-format of the output
buffer of the over/normal compositing operation, as well as the data
fetched from both buffer inputs - would likely be RaGaBaA float - if
the two linear inputs differ.

At all points we know the CIE Lab or XYZ coordinates of all involved
pixels – and we aim to do as few conversions as possible (never
converting the actual data to either bablRGB or XYZ, even temporarily
- unless requested.)

 Will all color-managed image editing be done using the user's chosen
 primaries, with absolutely no conversions to unbounded sRGB for image
 editing?

 Or are the developers committing themselves to maintaining lists of which
 operations should be done using fooRGB primaries and which should be done
 using sRGB primaries?

There is no plan to maintain lists in the end, this information would
be self-contained within each individual operation, like whether the
operation needs CIE Lab, pre-multiplied alpha or not or even an 16bit
linear grayscale. This automatic data representation conversion is an
inherent abstraction and property both of GeglBuffer and the services
provided for op authors to make implementing consistently behaving
operations easy.

/Ø
___
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] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/15/2014 08:30 AM, Øyvind Kolås wrote:

On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone  wrote:



Will all color-managed image editing be done using the user's chosen
primaries, with absolutely no conversions to unbounded sRGB for image
editing?

Or are the developers committing themselves to maintaining lists of which
operations should be done using fooRGB primaries and which should be done
using sRGB primaries?


There is no plan to maintain lists in the end, this information would
be self-contained within each individual operation,


If each individual operation will carry information about whether the 
operation should use fooRGB primaries or sRGB primaries, then at some 
point someone must compile a list for the devs to consult.


Unless you really mean to say:

*DevA working on Op1 decides whether to use fooRGB primaries or sRGB 
primaries for Op1.


*DevB working on Op2 decides whether to use fooRGB primaries or sRGB 
primaries for Op2.


*DevC can decide DevA and DevB were both wrong and change the code.

And so on.

Consider the following:

1. RGB editing operations performed on fooRGB images using fooRGB 
primaries are *always* correct.


2. More than half of all operations on linear RGB are 
chromaticity-dependent. Many more than half of all operations on 
perceptually encoded RGB are chromaticity-dependent. *All* of these 
operations WILL produce *wrong* results after the image is converted to 
unbounded sRGB.


So the developer choices are:

1. Either don't convert fooRGB images to unbounded sRGB for *any* RGB 
editing operations. Results will *always* be right.


2. Or else compile a list of all editing operations that do work and 
don't work in unbounded sRGB, and only convert the image to unbounded 
sRGB for the operations that do work in unbounded sRGB. And hope you 
get the list right, because you are messing with the user's RGB data for 
no good reason.


I will ask again:

For which specific RGB editing operations do you plan to convert the 
image from fooRGB to unbounded sRGB before performing the operation?


Either the answer is None. For color-managed fooRGB images, all RGB 
operations will be done on data encoded using fooRGB primaries.


Or you are committing the devs to maintaining a formal or ad hoc list of 
operations on fooRGB data vs operations on unbounded sRGB data. And then 
you are committing the devs to writing per op code to implement entirely 
pointless conversions from fooRGB to unbounded sRGB and back again.


With respect,
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] [Gegl-developer] babl roadmap

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 On 10/15/2014 08:30 AM, Øyvind Kolås wrote:
 On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone
 When the user opens a color-managed fooRGB image, for which *specific*
 editing operations will the image be converted to unbounded sRGB?
 
 
 If the user is putting a text-layer, which has been rendered using
 cairo and is in 8bit sRGB premultiplied alpha. The compositing of this
 with preceding data in the layer stack the babl-format of the output
 buffer of the over/normal compositing operation, as well as the data
 fetched from both buffer inputs - would likely be RaGaBaA float - if
 the two linear inputs differ.
 
 I'm not sure why your text-layer stack example is relevant to my very direct
 and still unanswered question.

As you very well know we don't *have* the specific list of editing
operations you ask for. I don't know why you keep repeating the
question. You seem to think that not getting an answer to that question
proves a point, but I definitely have no idea what the point is.

What would be the benefit of having such a list?

If the implementor of an operation thinks, that an operation needs to
work in unbounded bablRGB then it will request bablRGB input and gegl/babl
will do its work to provide that.

An example *could* be an operation that does change the warmth of an
image by simulating lighting by a different illuminant. The operation
could request bablRGB input data, convert that to XYZ internally, do the
shift, convert back to bablRGB and provide that as output.

But then the author might be better off with requesting the data in XYZ
directly, saving him from the work of doing the bablRGB to XYZ conversion:
Gegl/Babl does that for him.

Both ways are fine, Gegl/Babl can do this today. It is up to the author
to choose and it will be *completely* transparent to the user of the
operation.

This is completely independent from how the image pixels are stored in
memory, even when they are stored with a different set of RGB primaries.

Gegl/babl in that case will know how to transform the stored pixels into
bablRGB the operation requests, and they'll know what to do with the
output.

The text example from pippin is supposed to illustrate that Gegl in real
world situations has to deal with external sources which are beyond the
control of Gimp. And Gegl/Babl provide the facilities to deal with that.

 At all points we know the CIE Lab or XYZ coordinates of all involved
 pixels
 
 You don't know the XYZ coordinates until you actually convert from fooRGB
 to XYZ. Likewise with CIELAB. So it's not clear what the above sentence
 really means.

If you know the pixel values of a pixel and know how to convert fooRGB
to XYZ there is absolutely no need to do the actual conversion. You can
still claim that you know the XYZ as well as CIELAB coordinates. You
just don't bother to do the conversion until you really need it.

If you know that x is 5 and you know how to calculate the square of a
given value you don't need to do the actual calculation. Yet you still
know in the sense that the specific value is available to you as soon
as you need it.

 But here's a maxim for *RGB* image editing:
 
 For RGB editing operations, don't ever, ever, ever convert color-managed
 fooRGB to unbounded sRGB.

I assume that by RGB editing operations you're referring to the
math-centric ones which bluntly apply a mathematical formula to the
pixel data, not caring if the operation makes sense from a
colorimetric/physics based viewpoint. (Examples would be multiply or
even levels on the RGB channels).

We now have operations who utterly need to know the colorimetric values
of a pixel, because they are based on color theory. Shifting the color
temperature of an image might be a good example.

We have to be able to mix these operations, because Future Gimp (TM)
will head towards non-destructive editing, where the user uses the UI to
construct a graph of operations to combine all the image sources to get
to the desired result. We don't intend to stick to the have-an-image,
do-an-operation, have-a-new-image, repeat paradigm.

So we need infrastructure that can mix both, the colorimetric and the
math-centric approach. Your proposal of never-ever-converting will make
real colorimetric operations a pain, since the color-temperature
operation has to accept the fooRGB data, convert it to XYZ, do its
operation and convert back to fooRGB, because fooRGB is ultimately what
is needed for a potential next math-centric operation.

With the infrastructure proposed by pippin the math-centric operations
will ask for fooRGB data as input and provide fooRGB data as output.
That means that chaining them together will neatly avoid colorspace
conversions.

If the user then decides to put a color-temperature change in the mix
(lets assume it requests bablRGB as input and provides bablRGB as
output, since the author decided against XYZ for some reason) Gegl/Babl
will put a fooRGB-bablRGB conversion into the 

Re: [Gimp-developer] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/15/2014 01:58 PM, Michael Henning wrote:

Yes, the majority of operations will operate in myfavoriteRGB space,
but you seem to be operating under the premise that absolutely *no*
filters can possibly exist that require a specific color space to
function properly. This isn't the case.


Actually, I did go through the code base as thoroughly as possible, and 
I did identify various editing operations that depend on the data being 
in specific color spaces (not always D50-adapted sRGB). See 
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html




Take, for example, the color blindness simulation in gimp. This filter
tries to simulate color blindness so that artists can create images
that look good to people who are color blind. An operation like this
should not change based on which working space you choose to edit in;
it must always try to be as faithful to colorblindness as possible.
For an operation like this, being able to specify the working space on
the developer's side is a must. Otherwise, it can't work properly.


This is one of the operations that I identified. I also noted that ALL 
such operations should be clearly identified as such in the UI.



While operations like that might not be too common, it should still be
physically possible to create them. Before you say okay, so a proper
icc color managed editor will convert between icc profiles, what's the
big deal?, realize this: babl is exactly the mechanism that we are
using to make that happen.
These background conversions that you
seem to hate so passionately


The background conversions that I was objecting to two years ago convert 
between perceptually uniform and linear gamma RGB data, using the sRGB 
TRC as a stand-in for true perceptual uniformity. Those are the 
babl/babl/base/util.h TRC flips.


I do recognize (now, but not two years ago) the point of the TRC flips. 
The point is to be able to flip instantly between linear gamma and 
perceptually uniform RGB. See 
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html#best-solution


In my working copies of babl/GEGL/GIMP I have the babl TRC flips 
disabled because the ways in which the user can choose perceptual vs 
linear encoding are not transparent and also subject to change. But I'm 
looking forward to having the UI make it easy for the user to be able to 
switch at will. Assuming the devs will allow the user the freedom to 
make such choices.



are exactly the same conversions that you
already admitted were necessary when copying and pasting between
images. Just because conversions shouldn't be common does not mean
they should be impossible, or removed altogether.


I've already said elsewhere in this thread that how you get from RGB to 
XYZ/LAB/etc is really irrelevant as long as the end result is correct. 
The same thing applies to conversions from one set of RGB primaries to 
another set of RGB primaries.


Also, given a bug in current LCMS conversions between RGB matrix 
profiles, I would rather babl did the conversions. See 
http://sourceforge.net/p/lcms/mailman/message/32834352/


But even when that particular LCMS bug is fixed, there doesn't seem to 
be any advantage to calling on LCMS to do simple matrix conversions.


The only real drawback to all of the above is I can't see any way a GIMP 
user can edit their images in an RGB *LUT* color space. From my own 
point of view, that would never be a concern. But it should be noted 
that babl/GEGL/GIMP does seem to have this one requirement.


It should be noted that such cases as the colorblind filter and the old 
device-based code should be treated as explicit exceptions, labelled in 
the UI.


The guiding principle should be that except in these carefully bracketed 
and clearly identified cases, the *user* controls the RGB working space, 
and all RGB editing operations should use the user's chosen primaries.


Kind 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] [Gegl-developer] babl roadmap

[Tobias Ellinghaus]

Am Mittwoch, 15. Oktober 2014, 15:37:01 schrieb Elle Stone:

[...]

 The guiding principle should be that except in these carefully bracketed
 and clearly identified cases, the *user* controls the RGB working space,
 and all RGB editing operations should use the user's chosen primaries.

It seems this is the central point. The choice of bablRGB (or linear sRGB or 
linear Rec709) is merely an implementation detail and only works as the base 
transformation matrices are calculated on. Think of it as bablXYZ. It's the 
common ground babl does its color transformations on, just like ICC uses XYZ. 
This however is not the working space used in the gegl tree and therefore in 
GIMP. Just as applications using ICC internally don't work on XYZ data.

The reason why babl uses bablRGB instead of XYZ is just so that the common 
case of using sRGB data that is coming from the outside world (pippin gave the 
example of text rendered by cairo) can be used directly and doesn't need a 
conversion step. Code making use of the babl functions is free to keep every 
imported buffer in its native color space (probably linearized) and the system 
will make sure that the data is treated the right way when a conversion is 
required (for example when merging layers -- which format would win is 
probably a point to be discussed later).

At least that's how I understood the situation.

 Kind regards,
 Elle Stone

Tobias

signature.asc
Description: This is a digitally signed message part.
___
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] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/14/2014 06:54 AM, Øyvind Kolås wrote:



So now all chromaticity-dependent editing operations will require a brand
new special specifying, unless the image is already an sRGB image.

If you didn't intend to convert all images to unbounded sRGB for editing,
there wouldn't be any reason to special specify roughly half of all the
editing operations that you offer through the GIMP UI.

Just like in an ICC based workflow images are converted to unbounded
XYZ for editing? (they are not)


My apologies, I don't have a clue what you mean by what you just said.

But no, XYZ isn't a good color space for image editing, if that is what 
you are asking.



The PCS used by a CMS is an
implementation detail; where choices might have been XYZ, linear sRGB
or some other linear RGB; of the preceding linear sRGB has nicer
properties than any of the others.


The above sentence confuses concepts: The babl architecture might 
require that images to be converted to and from unbounded linear gamma 
sRGB. That doesn't mean babl is a CMS. And it doesn't mean unbounded 
linear gamma sRGB has been turned into a PCS.


To convert images to and from unbounded linear gamma sRGB, you MUST pass 
through XYZ. XYZ is the PCS.


Let's cut to the chase:

Are you planning on converting non-sRGB images to unbounded linear gamma 
sRGB? Yes or no?


If yes, are you intending that at least some editing will be done on the 
image while it's encoded using sRGB primaries? Yes or no?



With respect,
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] [Gegl-developer] babl roadmap

[Øyvind Kolås]

On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 The above sentence confuses concepts: The babl architecture might require
 that images to be converted to and from unbounded linear gamma sRGB. That
 doesn't mean babl is a CMS. And it doesn't mean unbounded linear gamma sRGB
 has been turned into a PCS.

Babls role in the GEGL and thus GIMP architecture is to be the
internal CMS; this remains unchanged since babl was split out of a
non-linear video editor/compositing system.


 To convert images to and from unbounded linear gamma sRGB, you MUST pass
 through XYZ. XYZ is the PCS.

I remind you that linear RGB spaces are a single matrix multiplication
away from other linear RGB spaces and XYZ.

 Let's cut to the chase:

 Are you planning on converting non-sRGB images to unbounded linear gamma
 sRGB? Yes or no?

Foo or bar? Do you have any idea what implementation detail means?

/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] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/14/2014 07:52 AM, Øyvind Kolås wrote:

On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:



To convert images to and from unbounded linear gamma sRGB, you MUST pass
through XYZ. XYZ is the PCS.


I remind you that linear RGB spaces are a single matrix multiplication
away from other linear RGB spaces and XYZ.


Matrix conversions between RGB working spaces can be concantenated. That 
concantenation goes through XYZ. It almost sounds like you want to 
obscure this fundamental distinction between XYZ and unbounded linear 
gamma sRGB.





Let's cut to the chase:

Are you planning on converting non-sRGB images to unbounded linear gamma
sRGB? Yes or no?


Foo or bar? Do you have any idea what implementation detail means?



I do know what implementation detail means.

You didn't the question, so I'll try again:

Are you planning on converting non-sRGB images to unbounded linear gamma 
sRGB? Yes or no?


If yes, are you intending that at least some editing will be done on the 
image while it's encoded using sRGB primaries? Yes or no?


With respect,
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] [Gegl-developer] babl roadmap

[Simon Budig]

Elle Stone (ellest...@ninedegreesbelow.com) wrote:
 On 10/14/2014 07:52 AM, Øyvind Kolås wrote:
 On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone
 ellest...@ninedegreesbelow.com wrote:
 
 To convert images to and from unbounded linear gamma sRGB, you MUST pass
 through XYZ. XYZ is the PCS.
 
 I remind you that linear RGB spaces are a single matrix multiplication
 away from other linear RGB spaces and XYZ.
 
 Matrix conversions between RGB working spaces can be concantenated. That
 concantenation goes through XYZ. It almost sounds like you want to obscure
 this fundamental distinction between XYZ and unbounded linear gamma sRGB.

for conversions between RGB working spaces there is no fundamental
distinction between XYZ and unbounded linear gamma sRGB.

In mathematical terms both of these span up a three dimensional vector
space (describing color) and the only difference is that they use
different basis vectors.

You can *easily* describe conversions between different RGB primaries
with ulgsRGB as the connecting space (completely replacing XYZ). You
would get a different set of transformation matrices of course.

XYZ is something that has a special role for all of the non-RGB color
spaces Lab, xyY, Luv etc, as well as operations like chromatic
adaptation. Hence it makes sense to use it also as the connecting space
for the different RGB primaries.

 Are you planning on converting non-sRGB images to unbounded linear gamma
 sRGB? Yes or no?

For pixel storage we will use whatever fits our needs, it does not make
sense at this point to specify this.

This might be a Lab-buffer with a cache in front of it that has the
pixels converted to sRGB. Or a Adobe-RGB-Buffer without a cache. Or
unbounded linear gamma sRGB. Or whatever.

The important thing is, that gegl/babl provides the means to access these
data in whatever format is needed by the operation that is happening. A
brightness-invert function might request the data in Lab, do the
inversion on the L channel and feed the results back as Lab to the
gegl/babl infrastructure, which will process it to provide the next
operation in the graph with the input format the next operation needs.

 If yes, are you intending that at least some editing will be done on the
 image while it's encoded using sRGB primaries? Yes or no?

That totally depends on the editing-operation in question and is
orthogonal to the pixel memory storage format.

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] [Gegl-developer] babl roadmap

[Simon Budig]

Hi Thorsten.

Thorsten Stettin (thorsten.stet...@gmail.com) wrote:
 with all due respect to you, I think you should contribute instead to
 babble.

If you perceive Elles texts as babbling it seems that this discussion
is way over your head and you might want to consider staying out of it.

Thanks,
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] [Gegl-developer] babl roadmap

[Christopher Curtis]

On Tue, Oct 14, 2014 at 9:04 AM, Simon Budig si...@budig.de wrote:

 If you perceive Elles texts as babbling it seems that this discussion
 is way over your head and you might want to consider staying out of it.


+1.

I'll admit that this discussion is way over my head, but as it seems to
involve only two people would it be better handled over a phone call? It
appears that there are some basic assumptions that aren't in alignment.

Chris
___
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] [Gegl-developer] babl roadmap

[Simon Budig]

Christopher Curtis (ccurt...@gmail.com) wrote:
 I'll admit that this discussion is way over my head, but as it seems to
 involve only two people would it be better handled over a phone call? It
 appears that there are some basic assumptions that aren't in alignment.

While it certainly could be more concise, the discussion has helped me
tremendously with my glimpse into gegl/babl. So while the
misunderstandings might be easier to overcome within a phone call
keeping the discussion on the list helps with potentially getting the
concepts out there to more people.

That having said, meeting people in person *is* tremendously helpful and
I'd like to extend pippins invitation to the LGM (next year in Toronto)
to everybody who is interested in discussing these topics with e.g.
pippin and me. There will be funds available to help bring people
together.

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] [Gegl-developer] babl roadmap

[Thorsten Stettin]

Am 14.10.2014 um 15:04 schrieb Simon Budig:

Hi Thorsten.

Thorsten Stettin (thorsten.stet...@gmail.com) wrote:

with all due respect to you, I think you should contribute instead to
babble.

If you perceive Elles texts as babbling it seems that this discussion
is way over your head and you might want to consider staying out of it.

Thanks,
 Simon


Ok, It pisses me off though. I didn't mean to hurt anybody.
But we don't need any academic discussion.
We need contribution.
Ok, I'm just a packager, sorry for that.

Cheers

Thorsten




--
Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die 
Demut.
Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige 
ist fähig zu herrschen.

___
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] [Gegl-developer] babl roadmap

[Nicolas Robidoux]

+1

On 14 October 2014 15:54, Simon Budig si...@budig.de wrote:

 While it certainly could be more concise, the discussion has helped me
 tremendously with my glimpse into gegl/babl. So while the
 misunderstandings might be easier to overcome within a phone call
 keeping the discussion on the list helps with potentially getting the
 concepts out there to more people.
___
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] [Gegl-developer] babl roadmap

[Christopher Curtis]

On Tue, Oct 14, 2014 at 9:54 AM, Simon Budig si...@budig.de wrote:

While it certainly could be more concise, the discussion has helped me
 tremendously with my glimpse into gegl/babl. So while the
 misunderstandings might be easier to overcome within a phone call
 keeping the discussion on the list helps with potentially getting the
 concepts out there to more people.


People seem to be getting frustrated and I don't think that helps anybody.
It seems to me that realigning the conversation in a more appropriate
medium would help to make the mailing list discussion more productive. A
summary of the phone call would then either bring everyone back together,
or continue the dispute on clearer terms.

Of course, folks are free to do whatever...

$0.02,
Chris
___
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] [Gegl-developer] babl roadmap

[Jehan Pagès]

Hi,

On Tue, Oct 14, 2014 at 3:58 PM, Thorsten Stettin
thorsten.stet...@gmail.com wrote:
 Am 14.10.2014 um 15:04 schrieb Simon Budig:

 Hi Thorsten.

 Thorsten Stettin (thorsten.stet...@gmail.com) wrote:

 with all due respect to you, I think you should contribute instead to
 babble.

 If you perceive Elles texts as babbling it seems that this discussion
 is way over your head and you might want to consider staying out of it.

 Thanks,
  Simon

 Ok, It pisses me off though. I didn't mean to hurt anybody.
 But we don't need any academic discussion.

Of course we do!
These kind of discussions are really helpful to understand things.
Most of these are also over my head (though I wish I understood more
of these!) but I am very grateful that they are done in the open! This
is also part of what makes a sane Free Software.

Now of course, meeting people in LGM or elsewhere is also very good,
but that should not prevent the results of these discussions to also
be discussed publicly here.
Same if it were by phone, I would still always appreciate discussions
to be summarized or continued on the mailing list.

 We need contribution.

Seriously if you don't consider these extremely important
contributions for GIMP (discussion on a good architecture for what is
essentially the core of GIMP!), I wonder what will be!
Of course code contributions *too* is nice, but these happen after
the discussions in such cases.

Anyway please, this is the gimp-developer@ mailing list. If you don't
like these discussions about improving the core of GIMP, maybe you are
on the wrong list. Also you don't have to read them all! (there are a
lot which I don't find interesting just by reading the title, I don't
ask people to not write them!).
As long as everybody stays polite and remembers we are on a written
medium (hence misunderstandings and annoyed feelings are easier to
get; when that happens, just breath), please don't interrupt
completely on-topic discussions.
Thanks.

Jehan

 Ok, I'm just a packager, sorry for that.

 Cheers

 Thorsten




 --
 Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen.
 Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege.
 Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die
 Demut.
 Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der
 Demütige ist fähig zu herrschen.

 ___
 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
___
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] [Gegl-developer] babl roadmap

[Øyvind Kolås]

On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 The sRGB as PCS architecture outline in babl/docs/roadmap.txt will likely
 collapse under its own weight. The roadmap should be amended to reflect a
 more accurate assessment of the amount of work the planned architecture will
 entail.

 The babl roadmap says:

 Babl currently only supports formats using the sRGB primaries, quite a few
 editing operations including gamma adjustments and multiply compositing
 relies on the chromaticities of the space used, permitting at least linear
 formats with other chromaticities is highly desirable

 As the purpose of the roadmap seems to be guiding future development, the
 list of editing operations that rely on the chromaticities of the RGB
 working space needs to be expanded. The following list is not complete, but
 it's a start:

The place for this would be in the GIMP wiki; where the state of
migration from old type gimp plug-ins to GEGL ops, as well as other
tracking state of ops are maintained.
http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL

 The roadmap says permitting at least linear formats with other
 chromaticities is highly desirable. It is unclear why permitting should
 be limited to linear formats. All of the operations listed above depend on
 the working space chromaticities, regardless of whether the RGB values are
 linear or perceptually uniform.

This has to do with which capabilities one chooses to implement early,
since it would bring a functional system, the non sRGB TRC are nice to
have but not as fundamental as custom chromaticities. Not having
custom TRCs for custom formats; means that those formats would be
using the sRGB TRC until such support would be added.

 Indeed, some (and probably many) operations, that work just fine on linear
 unbounded sRGB values, are *very* dependent on the chromaticities when
 performed on perceptually uniform RGB values (for example drawing a
 gradient).

 Someone should check all editing operations for perceptually encoded RGB to
 figure out which operations depend on the chromaticities, and then add these
 operations to the list of operations that need to be special-cased in the
 planned sRGB as PCS architecture.

The per-op working pixel representation are part of GEGLs design, thus
it isn't really special casing - but specifying.

/Ø
___
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] [Gegl-developer] babl roadmap

[Elle Stone]

On 10/13/2014 03:25 PM, Øyvind Kolås wrote:

On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:



As the purpose of the roadmap seems to be guiding future development, the
list of editing operations that rely on the chromaticities of the RGB
working space needs to be expanded. The following list is not complete, but
it's a start:


The place for this would be in the GIMP wiki; where the state of
migration from old type gimp plug-ins to GEGL ops, as well as other
tracking state of ops are maintained.
http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL


It's OK with me if you put the information in the GIMP wiki. But if you 
attribute the information to me, please include the disclaimer that I 
think your architecture will eventually collapse under its own weight.



Someone should check all editing operations for perceptually encoded RGB to
figure out which operations depend on the chromaticities, and then add these
operations to the list of operations that need to be special-cased in the
planned sRGB as PCS architecture.


The per-op working pixel representation are part of GEGLs design, thus
it isn't really special casing - but specifying.


You designed an architecture around converting images to unbounded sRGB 
for editing.


After 6 months of trying to show you that your architecture has serious 
built-in problems, you finally believe me, or at least you believe 
Mansencal and Sayre. But you want to keep the architecture anyway.


So now all chromaticity-dependent editing operations will require a 
brand new special specifying, unless the image is already an sRGB image.


If you didn't intend to convert all images to unbounded sRGB for 
editing, there wouldn't be any reason to special specify roughly 
half of all the editing operations that you offer through the GIMP UI.


With respect,
Elle Stone
--
Some operations that require special specifiying, assuming linear 
encoding:

Channel data used as a blending layer
Channel data used for making selections
Colors/Alien Map HSL
Colors/Alien Map RGB
Colors/Auto stretch contrast
Colors/Auto stretch contrast HSV
Colors/Channel Mixer (try Margulis' enhance green formula)
Colors/Desaturate average
Colors/Desaturate lightness
Colors/Mono Mixer (except Luminosity-based BW conversions)
Colors/Posterize
Colors/Threshold
Colors/Levels Gamma slider operations
Colors/Levels Red, Green, and Blue Input/Output sliders
Colors/Levels Auto Pick (used for white balancing images)
Filters/Artistic/Cartoon
Filters/Edge Detect/Sobel
Filters/Enhance/Red Eye Removal
Filters/Noise/HSV Noise
Filters/Noise/RGB Noise
Filters/Artistic/Soft glow
Filters/Artistic/Vignette (any color except gray, white, black)
Layer blend Mode/Burn
Layer blend Mode/Color
Layer blend Mode/Darken only
Layer blend Mode/Difference
Layer blend Mode/Divide
Layer blend Mode/Dodge
Layer blend Mode/Hard light
Layer blend Mode/Hue
Layer blend Mode/Lighten only
Layer blend Mode/Multiply
Layer blend Mode/Overlay
Layer blend Mode/Screen
Layer blend Mode/Saturation
Layer blend Mode/Value
Paint tools depend on the working space chromaticities when using the 
following blend Modes: Burn, Color, Darken only, Difference, Divide, 
Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, 
Screen, Soft light, Value.

___
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] [Gegl-developer] Don't make an architectural mistake based on a groundless premise

[Simone Karin Lehmann]

 Am 12.10.2014 um 12:46 schrieb Øyvind Kolås pip...@gimp.org:
 
 On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone
 ellest...@ninedegreesbelow.com wrote:
 On 10/11/2014 08:52 PM, Jon Nordby wrote:
 Please correct me if I misunderstood what you are saying. I think you are
 saying:
 
 GIMP uses GTK+.
 
 GTK+ uses Cairo APIs for rendering to the screen.
 
 Cairo APIs assume 8-bit sRGB.
 
 Therefore in GTK+ applications such as GIMP, images must be converted to
 sRGB before they can be displayed on the screen.
 

 Cairo is just one part of our eco-system which is following the
 guidelines of how to integrate with color management even if you do it
 badly; assume sRGB.

so that means, that specifying a monitor profile in GIMP’s preferences other 
than sRGB will result in displaying wrong colors. Or am I wrong?

I didn’t know that.

On systems with builtin desktop CM, like OS X, wouldn’t it be better to disable 
the choice of a monitor profile in GIMP at all, as long as cairo assumes SRGB? 

Simone
___
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] [Gegl-developer] Don't make an architectural mistake based on a groundless premise

[Elle Stone]

On 10/12/2014 06:46 AM, Øyvind Kolås wrote:

Applications
like GIMP, image viewers and similar - should be requesting that
rectangular parts of the UI (image viewing areas and similar) be
excepted from these conversions.


Exactly.

People with wide gamut monitors would be pretty upset if their images 
were squeezed through sRGB before being sent to the screen.


Converting to sRGB before converting to the monitor's profile would 
limit what is seen on the screen to the *overlap* between the sRGB color 
gamut and the LCD monitor profile's color gamut.


Many LCDs, even many widegamut LCDs, can't display all of sRGB. See Can 
the entire sRGB color gamut be displayed on today's LCD monitors? 
http://ninedegreesbelow.com/photography/srgb-bad-working-space-profile.html


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] [Gegl-developer] Don't make an architectural mistake based on a groundless premise

[Elle Stone]

On 10/10/2014 07:49 PM, Øyvind Kolås wrote:

On Sat, Oct 11, 2014 at 1:18 AM, Elle Stone
ellest...@ninedegreesbelow.com wrote:



So I have two specific questions. The first question is about
converting to LAB. The second question (which I haven't asked yet) has to do
with Y.


We will try to do what makes sense and helps us achieve what we need
to achieve efficiently; while keeping what works well, working well.


The above statement is devoid of content. It serves to dismiss my 
specific questions about why you want to keep hard-coded sRGB XYZ and Y 
in a color-managed workflow.





sRGB as PCS is linear gamma unbounded sRGB. I think it's reasonable to ask
why a conversion to unbounded sRGB should be involved in a conversion from
User_RGB to LAB.


For the same reason XYZ is involved (or not, depending on how the CMM
does it) in an ICC workflow.


Please provide a specific example of an actual CMM in an ICC profile 
workflow that doesn't use XYZ for converting between RGB working spaces.





Existing code written with assumptions of sRGB, whether in GIMP and
GEGL that we control or in XPM, GTK, GDK, or elsewhere that has sRGB
assumed will continue to work. We take the existing architecture which
is following general guidelines of assuming sRGB where none is
specified.


A guideline for dealing with images that don't have embedded ICC 
profiles makes an appalling bad guideline for writing a color-managed 
image editor.


This is not about how images with no embedded profile are handled.
sRGB derived 8bit (and to a lesser degree 16bit) formats are used for
many other things than images with no embedded profile.


You falsely assume that 8-bit images are always sRGB images and that 
16-bit integer images are probably sRGB images.



These pixel
formats are crucical for integrating with existing file formats and
libraries;


File formats that only work with sRGB images should not impact 
color-managed image editing. Advise the user to convert to sRGB.


Accurate UI colors is a desktop color management issue, entirely 
irrelevant to programming a color-managed image editor.



and we want these conversions to be as fast as possible -
even if it might have an impact on the conversion speed for CIE Lab,
though that does not have to be the case either. Choosing any PCS
*but* linear sRGB into a PCS  would tend to make these important
conversions slower.


Unbounded linear gamma sRGB is not a Profile Connection Space.

Idiosyncratic redefinitions of well-established color management terms 
confuses people who don't understand ICC profile color management.


Idiosyncratic redefinitions of well-established color management terms 
makes it difficult for people who do understand ICC profile color 
management to communicate with the babl/GEGL devs.




I can move on to my question about Y and unbounded sRGB. But I still don't
understand why unbounded sRGB should be involved in a conversion from
User_RGB to LAB.


We will do what makes most sense and is neccesary when we get there, I
suspect each RGB model with have an associated Y and YA model. Due to
how the existing BablModels interact with components and vocabulary
used to address them in babl; potential support for different TRCs is
even vaguer; we'll know when we have more code.


Is there any point in my demonstrating how convoluted and unworkable it 
will be to convert to unbounded sRGB whenever Y is involved? Because if 
there isn't, I don't want to waste my time.




Maybe we have more code by the time of LGM, if not that would be an
excellent place to elaborate;


As I have indicated before, the invitation is very kind. But not 
everyone is able to drop other obligations and go to LGM.



until then I prefer IRC.


Twice I tried to discuss problems with unbounded sRGB on IRC. It was 
neither pleasant nor productive.


For a moment it seemed that perhaps unbounded sRGB was going to be 
dropped and we could move on to generalizing the code to use Y and XYZ 
taken from the user's chosen RGB working space 
(http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html).


However, given Pippin's latest explanations of how things will be done, 
I'm not sure there's any point in my continued involvement with GIMP 
development.


Kindest 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] [Gegl-developer] Don't make an architectural mistake based on a groundless premise

[Øyvind Kolås]

On Sat, Oct 11, 2014 at 1:41 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 As I have indicated before, the invitation is very kind. But not everyone is
 able to drop other obligations and go to LGM.
 until then I prefer IRC.

 Twice I tried to discuss problems with unbounded sRGB on IRC. It was neither
 pleasant nor productive.

That is an apt summary of this email exhange as well, neither pleasant
nor productive - sorry. At least on IRC there is the chance of
correcting misunderstanding before they've been published as books.
The only reason I have responded in this thread is that someone is
wrong on the internet and was spreading fundamental misunderstandings
about how babl works as well as how we intended it to be used in GEGL
in the future, I wish that time had been spent implementing it
instead.

Many of the questions in your later e-mail have been responded to in
other emails preceding your emails.

I find it ironic that the architecture that you question is the
architectural foundation that ICC also is using. With similar
constraints and performance characteristics.

/Øyvind
___
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] [Gegl-developer] Don't make an architectural mistake based on a groundless premise

[Øyvind Kolås]

 Please provide a specific example of an actual CMM in an ICC profile
 workflow that doesn't use XYZ for converting between RGB working spaces.

Please read simons post about matrix multiplication, in his camera
example the data never exists as XYZ.

 You falsely assume that 8-bit images are always sRGB images and that 16-bit
 integer images are probably sRGB images.

This is not being assumed, but it is a matter of fact that a lot of
buffers are in these formats and we want to deal well with them.

 formats are crucical for integrating with existing file formats and
 libraries;

 File formats that only work with sRGB images should not impact color-managed
 image editing. Advise the user to convert to sRGB.

The data needs to be loaded into a GeglBuffer with a BablFormat that
uniqely describes the color content. For 8bit sRGB with babl that has
traditionally been R'G'B' u8, in the roadmap in babl I even
suggested that the buffers data is loaded into should be changed to be
sRGB:R'G'B' u8 for clarity even if it will continue to mean the same
as R'G'B' u8. And the chromaticity/working/target space should also
be set to sRGB:R'G'B'.

 Unbounded linear gamma sRGB is not a Profile Connection Space.

 Idiosyncratic redefinitions of well-established color management terms
 confuses people who don't understand ICC profile color management.

 Idiosyncratic redefinitions of well-established color management terms makes
 it difficult for people who do understand ICC profile color management to
 communicate with the babl/GEGL devs.

There are differences between the internal implementation of a system
and the public API. Calling the bablRGB a PCS, since that is the role
it has in the internal implementation was an attempt at making you
understand the architecture, and I guessed you did understand since
you have been using the term as well. I thought you would understand
how XYZ  fills the same role in ICC. It is never called either XYZ nor
PCS in the babl code. It is better if we call it bablRGB than linear
sRGB which is an oxymoron.

 Is there any point in my demonstrating how convoluted and unworkable it will
 be to convert to unbounded sRGB whenever Y is involved? Because if there
 isn't, I don't want to waste my time.

 For a moment it seemed that perhaps unbounded sRGB was going to be dropped
 and we could move on to generalizing the code to use Y and XYZ taken from
 the user's chosen RGB working space
 (http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html).

I was hinting at how a given set of chromaticities wouldn't be
affecting single babl formats but change interpretation of also other
formats when given a prefix.

You seem to challenge mention of sRGB to the extent that people have
been championing linear workflows. While bablRGB will end up being an
implementation detail that is an optimization. Babl will end up having
_many_ different RGB spaces with associated grayscale format; at some
point probably also associated non-linear spaces but that will have
lower priority. Among these spaces will be a space called sRGB which
behaves like the unprefixed formats. When we have these spaces. When
we have these additional spaces - what I have suggested is that we
then mark the operations which _are_ chromaticity dependent to operate
in this space. I have also hinted at what we might want to do, or at
least which things would be possible to do - including getting rid of
all unprefixed formats, as well as the possibility that such things
could be decided dynamically. There is a lot of code in GIMP that we
intend to keep working as we move forward, the only way is by small
incremental changes while keeping things working, changing as few
assumptions as possible as move move along.

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