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.



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

Reply via email to