Re: [Gimp-developer] suggestions

[Sven Claussner]

Hi Elle,

On  5.4.2016 at 10:55 PM Elle Stone wrote:

On 04/05/2016 02:10 PM, Sven Claussner wrote:

Hi,

On  4.4.2016 at 3:56 PM Elle Stone wrote:

On 03/27/2016 02:44 PM, C R wrote:
* The ability to edit in RGB working color spaces other than sRGB.


I'm for this, too.
sRGB is from the 1990's and made for the web.
Life goes on. Modern monitors aim to get as much AdobeRGB coverage
as possible and that's not the end yet.
If we aim to provide state-of-the-art technology we should not stick to
sRGB, but be open for flexible solutions.
See https://bugzilla.gnome.org/show_bug.cgi?id=737778 for instance.
As Alex says, it takes just one developer to work on it. I think we
can start with the above mentioned bug report and go on from that.


Some of the specific code-related information in that particular bug
report is out of date, not surprising as I posted the bug report in
December 2014. The general issues remain. The specific locations of the
hard-coded parameters haven't changed too much (GEGL has fewer such
locations). But the specific functions that call on the hard-coded
parameters have changed a bit.


@Pippin, Mitch: what are your thoughts on this topic?



I started a branch of this current thread to ask some specific questions
regarding a couple of babl functions that might be useful for conveying
RGB color space information from GIMP to babl, and also about the idea
of coding in a selection of well-behaved RGB working spaces:
https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00049.html


I've seen it. It looks like it accidentally landed in the suggestions
thread by just using the 'Answer' function of your mail client.
As it has now evolved too far from the original poster's topic I
suggest to have it as a new top level topic. But please
- do not repeat what was already said in one of those many sRGB postings
before
- stay brief or add a short summary to your postings.
I hope you don't get me wrong. Well-thought postings are welcome,
but the longer the text the less people read it.
Developers love coding ;-)

Greetings

Sven
___
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] suggestions

[Elle Stone]

On 04/05/2016 02:10 PM, Sven Claussner wrote:

Hi,

On  4.4.2016 at 3:56 PM Elle Stone wrote:

On 03/27/2016 02:44 PM, C R wrote:
* The ability to edit in RGB working color spaces other than sRGB.


I'm for this, too.
sRGB is from the 1990's and made for the web.
Life goes on. Modern monitors aim to get as much AdobeRGB coverage
as possible and that's not the end yet.
If we aim to provide state-of-the-art technology we should not stick to
sRGB, but be open for flexible solutions.
See https://bugzilla.gnome.org/show_bug.cgi?id=737778 for instance.
As Alex says, it takes just one developer to work on it. I think we
can start with the above mentioned bug report and go on from that.


Some of the specific code-related information in that particular bug 
report is out of date, not surprising as I posted the bug report in 
December 2014. The general issues remain. The specific locations of the 
hard-coded parameters haven't changed too much (GEGL has fewer such 
locations). But the specific functions that call on the hard-coded 
parameters have changed a bit.


I started a branch of this current thread to ask some specific questions 
regarding a couple of babl functions that might be useful for conveying 
RGB color space information from GIMP to babl, and also about the idea 
of coding in a selection of well-behaved RGB working spaces: 
https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00049.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] suggestions

[Sven Claussner]

Hi,

On  4.4.2016 at 3:56 PM Elle Stone wrote:

On 03/27/2016 02:44 PM, C R wrote:
* The ability to edit in RGB working color spaces other than sRGB.


I'm for this, too.
sRGB is from the 1990's and made for the web.
Life goes on. Modern monitors aim to get as much AdobeRGB coverage
as possible and that's not the end yet.
If we aim to provide state-of-the-art technology we should not stick to
sRGB, but be open for flexible solutions.
See https://bugzilla.gnome.org/show_bug.cgi?id=737778 for instance.
As Alex says, it takes just one developer to work on it. I think we
can start with the above mentioned bug report and go on from that.



* The ability to easily record and replay repetitive steps ("macros").


Yes, that's already part of the roadmap and part of our product vision.


* The ability to use adjustment layers.


Yes, that's already part of the roadmap.

I'm wondering why so many people stick with adjustments layers, nodes
and smart objects as if they were the only possible ways for
non-destructive editing. I sometimes think because they know nothing else,
it's so common, looks cool or because 'PS does it so.'
Let's not stick to what Adobe did because it was suitable for PS.
I might be wrong, but to me adjustment layers and smart objects seem an
attempt to get nondestructive editing into a software that wasn't
designed for that while keeping backwards compatibility.
Let's find better ways that suit GIMP and support intense users'
workflows best. Think of filter brushes, intelligent masks or masks
like in Darktable etc. For such a crucial function we won't get out of
doing UI testing with users.
But one thing we really have to keep in mind with adjustment layers
and smart objects is to find an appropriate conversion in the PSD
importer and exporter.

Greetings

Sven

___
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] Code for editing in non-sRGB color spaces (was Re: suggestions)

[Elle Stone]

On 04/05/2016 12:17 PM, Alexandre Prokoudine wrote:

Anything in that section can be moved to e.g. 3.2 provided there is a
developer working on any of the features listed there. At some point, the
unified transform tool was there too. Then Mikael came, and now it's a
v2.10 feature.


Two years ago I spent a lot of time trying to figure out how to pass RGB 
colorant information around GIMP and back to babl, but failed to make 
any progress.


I've been taking another look at the relevant babl/GEGL/GIMP code, but 
the task still seems to be way above my coding level. I suppose I should 
ask for help. So here are two questions:



1. Code for retrieving colorant information from an ICC RGB working 
space profile embedded in an image is already in 
https://github.com/GNOME/gimp/blob/master/libgimpcolor/gimpcolorprofile.c


Can the following babl functions from 
https://github.com/GNOME/babl/blob/master/babl/babl.h be used to send 
RGB colorant information (a 3x3 matrix) from GIMP to various babl 
functions that use Y and XYZ information?


/**
 * babl_set_user_data: (skip)
 *
 * associate a data pointer with a format/model, this data can be 
accessed and

 * used from the conversion functions, encoding color profiles, palettes or
 * similar with the data, perhaps this should be made internal API, not
 * accesible at all from
 */
void   babl_set_user_data (const Babl *babl, void *data);

/**
 * babl_get_user_data: (skip)
 *
 * Get data set with babl_set_user_data
 */
void * babl_get_user_data (const Babl *babl);


2. Instead of full-blown support for editing in all RGB working spaces, 
would it be easier and maybe even better to start with hard-coding into 
babl/GEGL/GIMP an assortment of commonly-used RGB working space 
chromaticities, including:


sRGB
Rec.2020
ACEScg
ACES
AdobeRGB
ProPhotoRGB

and then pass a numerical identifier from GIMP to babl as the user 
switches from one image to another, so babl knows what chromaticities to 
use? This option of course would require that the user make an ICC 
profile conversion to one of the hard-coded RGB working spaces. But 
given the many ICC RGB profiles floating around that are not 
well-behaved and/or have odd TRCs, maybe this is the better option. 
Though support for "random RGB chromaticities" would be nice to 
eventually add in.


I don't think I understand the relevant portions of 
https://github.com/GNOME/babl/blob/master/docs/roadmap.txt. If I do 
understand, the plan in the roadmap seems to require rewriting major 
portions of babl/GEGL/GIMP.


If it were possible to use babl_set_user_data and babl_get_user_data to 
pass along colorant information, or else a numerical reference to a 
selection of hard-coded chromaticities for commonly-used RGB working 
spaces, this approach would seem to be a lot less invasive of the 
existing code.


Very likely I've overlooked major coding obstacles. And as I already 
noted, it's very likely that I simply don't have sufficient coding 
skills to add the ability to edit in non-sRGB color spaces to GIMP.


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] suggestions

[Alexandre Prokoudine]

5 апр. 2016 г. 18:57 пользователь "Elle Stone" написал:

> I do appreciate that editing in color spaces other than sRGB is now on
the official Roadmap. However, it's on the Roadmap for "Future GIMP".

Anything in that section can be moved to e.g. 3.2 provided there is a
developer working on any of the features listed there. At some point, the
unified transform tool was there too. Then Mikael came, and now it's a
v2.10 feature.

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] suggestions

[Elle Stone]

On 04/05/2016 11:59 AM, Elle Stone wrote:

timeline for past GIMP releases:

https://en.wikipedia.org/wiki/GIMP_version_history

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

[Elle Stone]

On 04/05/2016 04:07 AM, Alexandre Prokoudine wrote:

4 апр. 2016 г. 20:10 пользователь "Elle Stone" написал:


But what about the ability to edit in color spaces other than sRGB? Is

this less or more of a priority than nondestructive editing?

We've had this conversation before. This is how
http://wiki.gimp.org/wiki/Roadmap got adjusted to specifically mention
that. At your request :)



I do appreciate that editing in color spaces other than sRGB is now on 
the official Roadmap. However, it's on the Roadmap for "Future GIMP".


GIMP 2.10 will be an "sRGB only image editor".

GIMP 3.0 is mostly about porting to GTK3 and I understand why porting to 
GTK3 is a high-priority task.


As for GIMP 3.2, quoting from the Roadmap: "The focus of this release is 
going to be on non-destructive editing. Note that both adjustment layers 
and layer effects/styles are the terminology currently used in requests 
by users. We haven't yet assessed, how exactly non-destructive editing 
is going to be implemented."


"Future GIMP" is some indefinite version of GIMP that come after the 
release of GIMP 2.10, GIMP 3.0, and GIMP 3.2.



Looking at the timeline for past GIMP releases:

1.2:  Dec 2000
2.0:  Mar 2004
2.2:  Dec 2004
2.4:  Oct 2007
2.6:  Oct 2008
2.8:  May 2012
2.10: ? (high bit depth editing)
3.0:  ? (port to GTK3)
3.2:  ? (nondestructive editing)
Future GIMP: ??? (support for editing in working spaces other than sRGB)

If the past is predictive of the future, it could be several or many 
years before "Future GIMP" gets here and GIMP finally provides for 
editing in RGB working spaces other than sRGB.


sRGB was invented in the 1990s to fit the color gamut of consumer-grade 
monitors.


sRGB has the same primaries as Rec.709, which dates back to 1990 
(https://en.wikipedia.org/wiki/Rec._709).


Unless the devs give a higher priority to support for editing in RGB 
working spaces other than sRGB, it looks like Rec.2020 devices 
(https://en.wikipedia.org/wiki/Rec._2020) will hit the shelves before 
GIMP supports editing in RGB working spaces other than sRGB.


It's already the case that photographic printers and various high-end 
display devices (televisions and monitors) have color gamuts that exceed 
the sRGB color gamut.


When shooting raw, it's already the case that digital cameras produce 
reasonably accurate colors that exceed the sRGB color gamut.


Even when shooting jpegs, most digital cameras allow to save in the 
AdobeRGB color space, and if you think those extra greens and 
blue-greens don't make a difference, you are just kidding yourself.


Color-producing/reproducing technology has moved past sRGB. This is a 
major reason why editing in RGB working spaces other than sRGB should be 
a high-priority item instead of being deferred to some indefinite 
"Future GIMP".


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] [Gimp-web] Gitlab as a replacement for registry.gimp.org

[Jehan Pagès]

Hi,

I said I would not answer anymore, but I will (hopefully a last time)
because I am weak and can't control my fingers! :P
Anyway this discussion is very frustrating because my emails are not
fully read. I'm sorry to say so Akkana, but your answer below is
either off-topic, or actually going in my direction, and shows that
you have not read my previous emails before saying you disagree.
Now I know I write too long texts (and I'm sorry for this, I'm not
good at this). But then don't read and ask me to get more concise
rather than reading half and disagreeing on things I already answered
(or said the opposite).

Or if you (not you specifically) don't want to read my opinion and
have your own plans that will go on whatever I think, please don't
ask. But don't ask the opinion, to not read it but contradict it after
the first words. This is extremely annoying. I hope you can
understand.

On Tue, Apr 5, 2016 at 4:17 AM, Akkana Peck  wrote:
> Jehan Pagès writes:
> [on one repo per asset vs. one repo containing many assets]
>> Really I don't understand this point which Akkana is raising. Has
>> anyone ever made plugins for various software? I have, for a bunch,
>> many dead now, some still living. And never have I ever thought "oh
>> let's put all my completely unrelated plugins into the same
>> repository"! This is like the base of code organization, you just have
>> separate items. I have a bunch of repositories of my own, and have a
>> few dozens of repositories from various projects which I have needed
>> at some point.
>
> In the current GIMP source tree, circuit.scm,clothify.scm,
> coffee.scm, line-nova.scm, old-photo.scm, spinning-globe.scm and
> spyrogimp.scm (I just picked a random set) are all completely
> unrelated scripts. Yet there they all are, 53 different .scm files
> in the GIMP source repository in the plug-ins/script-fu/scripts/
> directory, and similar unrelated collections in
> plug-ins/pygimp/plug-ins/ and plug-ins/ itself.

So that's the part which is either off-topic or actually going in my direction.

1/ Off-topic because these are the official released plugins. These
are not user-made plugins delivered through a plugin interface. This
is just completely different to what we are talking about! Of course
we deliver GIMP with a minimum set of plugins (because without these,
bare GIMP would be very limited. Well less now thanks to GEGL which
replaced most filters into operations). So yes, that's a single
release, together with GIMP, so this is one repository.

2/ Now let's say that we just absolutely want to consider the default
plugins the same as user-contributed plugins, this is when it goes in
my direction. They are delivered as a single-release? Then it is one
single extension/asset, so yes that's a single repository. As simple
as this. I said it previously: you can propose collection of
plugins/scripts (you don't get one without the others.). Everybody is
free. I said it before (so that's also a part where you did not read
my previous emails).

But actually if we had a good plugin management system, where it is
easy to install and update plugins, it may even be worth it to thin
out our default provided plugins/scripts. There was this discussion
the other day on the GIMP user mailing list when people noted that
GIMP was slow to launch and that plugin startup were part of the
cause. Elle was even saying that there are many plugins that she
barely ever used so she cleaned out her GIMP installation from many of
the default plugins.
The fact is that right now, as we all know, installing plugins is so
old-fashioned (get some zip somewhere, uncompress it in some hidden
directory, maybe play with file permissions…) that few people install
any. The consequences is that if the default installation has to be
released with a wide range of plugins, otherwise GIMP will look dumb.
But with a plugin management system, we could push many of the rarely
used plugins into the plugin directory, allowing people to easily
install them on a whim, yet keeping a default GIMP quite light.
And if we do this, this would not be a single release anymore.
Probably every unrelated plugin could be on its own for people to
choose which one they want.

> You are arguing that it's easier/better to maintain unrelated assets
> each in its own repository. But evidently the GIMP development team
> agrees with me: they have and a bunch of unrelated script files
> together within one directory within one big repository. That's how
> I organize my GIMP plug-ins too, and it's the model used in every
> other software project I've been involved with.
>
> Maybe I'm just being old fashioned because "many files in one big
> repo" is the only model I've seen in action. From what you say, I
> guess I should look at Wordpress to see a project that uses "one
> repo per file" successfully?

Wordpress uses one repo per plugin (well for plugins which want to be
hosted by Wordpress. Once again this is not mandatory. 

Re: [Gimp-developer] suggestions

[Alexandre Prokoudine]

4 апр. 2016 г. 20:10 пользователь "Elle Stone" написал:

> But what about the ability to edit in color spaces other than sRGB? Is
this less or more of a priority than nondestructive editing?

We've had this conversation before. This is how
http://wiki.gimp.org/wiki/Roadmap got adjusted to specifically mention
that. At your request :)

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