Re: [Gimp-developer] suggestions

[Elle Stone]

On 04/06/2016 12:30 AM, Sven Claussner wrote:

Hi Elle,


Hi Sven,


On  5.4.2016 at 10:55 PM Elle Stone wrote:

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.


I started a new thread per your suggestion: 
https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00053.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

[Elle Stone]

On 04/04/2016 05:36 PM, C R wrote:


Only so many hours in the day. For RAW processing Darktable works fine.
Back when I switched from Photoshop, RAW editing was still done via
plugin, and if you were serious about it, you'd do it in Adobe Lightroom.


Back when I switched from PhotoShop, I had already realized that the 
free/libre dcraw from the command line did a better job than ACR. As my 
workflow starts with a scene-referred rendition, whatever extras 
Lightroom might have provided were irrelevant.


Of course today's free/libre interpolation algorithms are considerably 
advanced beyond what dcraw provides.



When the deal is "free" it's hard to take such opinions seriously. Yes,
I've heard a lot of ranting too. It sounds more and more like noise when
they show you pretty grim portfolio pieces done in Photoshop. As if
doing something in their editor of choice automatically made them more
professional somehow.


As the GIMP vision statement seems to imply that supporting advanced 
workflows is central to the goals for GIMP, it's hard for me to 
understand why the ability to edit in GIMP using RGB working spaces 
other than sRGB isn't already part of the code.



On the topic of nodes though, have you tried Natron?


No. I haven't had the time, though it's on the "to do" list.

Have you tried PhotoFlow? I believe PhotoFlow uses nodes. It's a 
non-destructive raw processor/image editor that also runs as a GIMP plug-in.



I can (and do) patch and build versions of GIMP that work in
Rec.2020 or other working space(s) of my choice. Most people can't
or won't do this.


How hard was the patching? Is it really one or the other only?


Keeping the patches up to date with babl/GEGL/GIMP from git is tedious.

Yes, it's really one or the other because in babl/GEGL/GIMP code the RGB 
values for Y and XYZ are hard-coded to sRGB instead of using colorant 
values from a user-chosen RGB working space.


Partha very kindly provides builds for my patched GIMP for Windows 
(http://www.partha.com/). But for Linux you have to compile it yourself 
(http://ninedegreesbelow.com/photography/patch-gimp-in-prefix-for-artists.html).




I've been using my patched high bit depth GIMP a lot in the last
year. So obviously I enjoy using GIMP, and also I like the results
I'm getting. Otherwise I wouldn't be here pestering the devs (yet
again) about adding full support for editing in working spaces other
than sRGB.


Have you tried the development build?


I keep up with babl/GEGL/GIMP from git in a "default GIMP" prefix that I 
use for filing bug reports. For actual editing I use my patched version 
of babl/GEGL/GIMP compiled in a separate prefix. I update the patches 
every month or so.




In development build (gimp-edge)

Image > Precision > Linear Light

The other option is "Perceptual Gamma (sRGB)"


Those would be the "babl flips" that allow the devs to decide whether 
any given editing operation should be done on linear gamma RGB or on 
perceptually uniform RGB, with "perceptually uniform" hard-coded to be 
the only approximately perceptually uniform sRGB TRC.


The babl flips really could be very useful, especially if all editing 
operations provided the user with a choice between linearized and 
perceptually uniform RGB.


But for now the babl flips are still a bit of an impediment as sometimes 
the default "linear vs perceptual" choice is not radiometrically 
correct. For example Curves and Levels by default are done on 
perceptually uniform RGB, which unfortunately produces radiometrically 
*in*correct results.




Not sure if this is what you are after, but I thought of you when I saw
the feature. :)
Note also up to 64bit precision now.


GIMP's 64-bit precision option is to allow for importing from/exporting 
to 64-bit precision files such as FITS files.


All internal GEGL processing is done at 32-bit floating point precision.

The only thing you accomplish by choosing to *edit* at 64-bit precision 
is that you'll very quickly fill your available RAM and GIMP will slow 
way down.


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

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

Re: [Gimp-developer] suggestions

[C R]

>
> I'm sure if they require something other than sRGB, they will want
>> Photoshop (at the moment).
>> Of course, that is a self-imposed limitation. Suggesting that
>> professional results can only be gotten outside sRGB is untrue.
>>
>
> "Professional results" and "self-imposed limitation" are two very
> different concepts here. Yes, people can and do acheive professional
> results editing in sRGB. That doesn't mean *all* professional and personal
> goals that a photographer might have can be met using sRGB.
>
>
In particular, if their professional goal mandated using something other
than sRGB gamut (or linear light), then yes I guess so. To me that's a bit
like saying I can't work in a 32bit OS because my professional goals
include 64bit machine instructions. ;)

I'm sure there's a difference, I'm also sure I couldn't tell you what the
difference is unless they were side-by-side.
I'm also certain other people care way more than I do. :)
Let me be clear: I look forward to having the extra features in GIMP,
available to those who want/need them. When Photoshop switched to 16bit
colour, I stayed with the default 8bit. To this day I'm glad, because I the
extra space it takes wasn't worth it for me. ymmv. :) 16 bit/channel colour
is a big deal to some people. I'm happy to say that GIMP will support the
feature for those who care more than I do about it.


I have never once had anyone squint at my model photos and say
>> "Heeeyyy... that's JUST sRGB, how unprofessional!" Maybe they were just
>> being polite though...
>>
>
> Many people produce fantastic and professional results using sRGB for all
> their editing. The fact remains that the adequacy of sRGB depends entirely
> on one's editing goals and style:
>
>

> 1. For someone editing mostly for CMYK reproduction for mass printing, I
> suspect sRGB is usually a good color space to work in, though this area is
> completely outside my own experience. Likewise for digital artists whose
> intended display space is sRGB, I suspect sRGB is a good color space to
> paint in (and when the Rec.2020 devices start hitting the market?).
>

This plus web is *most* of the graphics industry. CMYK is often not what's
required. I never once had a printing company tell me they wanted a FOGRA27
document. As sad as it is, most people just stick with what the default is.
:)

2. Someone making "as close as possible" photographs of artwork will need
> to use a larger color space than sRGB unless they only photographs very
> low-gamut artwork. If the artwork photographs are to be made into prints on
> fine art photographic paper, again, sRGB is too small except for low-gamut
> artwork.
>

This is where my experience falls right off the edge. I have no such
special requirements, but again would be happy to have them in GIMP for
those people who do need them.


> 3. If someone wants to prepare camera images for a Rec.2020 or other
> display device with a color gamut larger than sRGB, then sRGB is too small
> unless the photographer only photographs low-gamut scenes. Of course the
> alternative is photographing more colorful scenes and then throwing all the
> lovely colors that exceed sRGB right out the window.
>

Again, not sure I could tell the difference unless I saw the results
side-by-side on the speciality hardware it takes to display them.


> 4. Likewise with preparing camera images for printing on high end printers
> using high quality photographic paper - you either throw printable colors
> away or you edit in an RGB working space large enough to adequately hold
> the colors you captured with your camera. Yes there are still
> camera-captured colors that will be problematic, but that's part of dealing
> with camera input profiles and part of dealing with soft proofing.
>

I mean, it will never be perfect. At some point you have to draw a line and
say "this is good enough". For my purposes, GIMP well exceeds that line. I
have pretty high demands as well, they just don't involve swapping colour
spaces all that much. :)


> 5. Even when editing low-gamut images or else sRGB images produced
> in-camera, depending on your editing goals switching to a larger color
> space can be advantageous as anything other than mild edits sends RGB
> colors to the edge of the very small sRGB color gamut.
>

True. I've also seen some really wicked things done in Krita with HDR
painting. I can see there are advantages to working in a larger colour
space as well. It's nothing I need to be subscribing to Photoshop for
though.

6. White balancing an sRGB camera jpeg that was shot with the wrong
> in-camera white balance is much easier to do in a larger RGB color space (
> http://ninedegreesbelow.com/photography/white-balancing-camera-jpegs.html
> ).
>

Also true. I tend to just take time to get my exposure correct, so there is
very little editing to do. I used to process RAW files, these days I can't
be bothered as no one notices the difference (including myself). Good
lighting is a must for good 

Re: [Gimp-developer] suggestions

[Elle Stone]

On 04/04/2016 01:54 PM, C R wrote:


On Mon, Apr 4, 2016 at 2:56 PM, Elle Stone
>
wrote:



Putting the serious limitations of 8-bit editing to one side, even
high bit depth GIMP 2.9/2.10 lacks critically important components
of the workflows of (lacking statistics, at least some) professional
photographers currently using PhotoShop.

Hi Elle. :) I feel like we've had this discussion before... but, well if
that's true, here goes again. ;)

For example, for at least some professional photographers, their
workflow depends on:

* The ability to edit in RGB working color spaces other than sRGB.


I'm sure if they require something other than sRGB, they will want
Photoshop (at the moment).
Of course, that is a self-imposed limitation. Suggesting that
professional results can only be gotten outside sRGB is untrue.


"Professional results" and "self-imposed limitation" are two very 
different concepts here. Yes, people can and do acheive professional 
results editing in sRGB. That doesn't mean *all* professional and 
personal goals that a photographer might have can be met using sRGB.



I have never once had anyone squint at my model photos and say
"Heeeyyy... that's JUST sRGB, how unprofessional!" Maybe they were just
being polite though...


Many people produce fantastic and professional results using sRGB for 
all their editing. The fact remains that the adequacy of sRGB depends 
entirely on one's editing goals and style:


1. For someone editing mostly for CMYK reproduction for mass printing, I 
suspect sRGB is usually a good color space to work in, though this area 
is completely outside my own experience. Likewise for digital artists 
whose intended display space is sRGB, I suspect sRGB is a good color 
space to paint in (and when the Rec.2020 devices start hitting the market?).


2. Someone making "as close as possible" photographs of artwork will 
need to use a larger color space than sRGB unless they only photographs 
very low-gamut artwork. If the artwork photographs are to be made into 
prints on fine art photographic paper, again, sRGB is too small except 
for low-gamut artwork.


3. If someone wants to prepare camera images for a Rec.2020 or other 
display device with a color gamut larger than sRGB, then sRGB is too 
small unless the photographer only photographs low-gamut scenes. Of 
course the alternative is photographing more colorful scenes and then 
throwing all the lovely colors that exceed sRGB right out the window.


4. Likewise with preparing camera images for printing on high end 
printers using high quality photographic paper - you either throw 
printable colors away or you edit in an RGB working space large enough 
to adequately hold the colors you captured with your camera. Yes there 
are still camera-captured colors that will be problematic, but that's 
part of dealing with camera input profiles and part of dealing with soft 
proofing.


5. Even when editing low-gamut images or else sRGB images produced 
in-camera, depending on your editing goals switching to a larger color 
space can be advantageous as anything other than mild edits sends RGB 
colors to the edge of the very small sRGB color gamut.


6. White balancing an sRGB camera jpeg that was shot with the wrong 
in-camera white balance is much easier to do in a larger RGB color space 
(http://ninedegreesbelow.com/photography/white-balancing-camera-jpegs.html).


7. Of course if you only shoot sRGB camera jpegs that were properly 
color-balanced "in camera", and you process them "gently", you aren't 
going to have a problem with out of gamut colors. But if you only shoot 
sRGB camera jpegs, there's a whole realm of image editing possibilities 
that you can't easily perform on this kind of image, that instead 
require starting with the raw file. Personally I prefer to begin editing 
with a scene-referred image rendered from a raw file, and for most 
scenes (unless I only point my camera at low-gamut scenes) this requires 
using an RGB working space that is larger than sRGB.


The problem with sRGB is that the sRGB color gamut is very small 
(http://ninedegreesbelow.com/photography/srgb-versus-photographic-colors.html). 
I once made some sample photographs to see what real world colors are 
outside the sRGB color gamut and was surprised to find that even crayons 
scribbled somewhat heavily on white paper produce colors outside the 
sRGB color gamut. A nice bright yellow or red flower? completely outside 
the sRGB color gamut 
(http://ninedegreesbelow.com/photography/icc-profile-conversion-clipped-colors-examples.html, 
especially see 
http://ninedegreesbelow.com/photography/icc-profiles/clipped-colors/red-flower-clipping-prophoto-to-srgb.jpg).


Having said all of the above, of course where you point the camera is 
every bit as (or more) important as what you do with the resulting 
image, and shooting raw is not a guarantee of 

Re: [Gimp-developer] suggestions

[Andrew Pullins]

I will say that it would be nice to have a recommended hardware to run
GIMP.  I know this is Free and Open Source Software and you can pretty much
run it one anything as well as we are not Photoshop and are not worried
about sails and making sure that the customer is running the best hardware
to run GIMP on.  But GIMP is getting bigger, more complicated, able to
perform harder tasks and therefore does have hardware requirements. I was
on a old netbook testing out my theme I was making to make sure it worked
OK in Windows, and just changing the theme was a nightmare. I have been on
other computers that were a bit nicer trying to do other things and GIMP
was running sluggish. I don't think that GIMP has to be a conservative as
Photoshop and recommend at least two/three year old hardware. But there is
a logical limit to the hardware people can run and still use GIMP
relatively smoothly.  Maybe there could be a note saying something like:
GIMP can run on pretty much all hardware but here are our recommendations.
That way people who have never used GIMP understand that they might be able
to run it but they might not have the best experience and it's their
hardwares fault not GIMP's.  I don't know what hardware to recommend but I
do think that we should recommend something.
On Apr 4, 2016 12:28 PM, "Øyvind Kolås"  wrote:

On Mon, Apr 4, 2016 at 4:19 PM, Partha Bagchi  wrote:
> Also, I would think that nondestructive
> editing would be high on the list (Photoshop's "Smart Objects").
>
> If I am not mistaken, Alex has already mentioned adjustment layers
numerous
> times in past as a requirement/missing feature in GIMP.

One of the primary reason some of us have has as motivation for
working on GEGL and its integration in GIMP for more than a decade is
not high bit depth support, but non-destructive editing features like
"adjustment layers" and "smart objects". As has been communicated
repeatedly; GIMP-2.10 and 3.0 are planned to have feature parity with
GIMP-2.8, and let the integration of GEGL as well as GEGL itself
mature with that - before experimenting with more non-destructive
features; non destructive user experiences with GEGL are - and have
been - experimented with outside the GIMP code base.

/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-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/04/2016 12:28 PM, Øyvind Kolås wrote:

One of the primary reason some of us have has as motivation for
working on GEGL and its integration in GIMP for more than a decade is
not high bit depth support, but non-destructive editing features like
"adjustment layers" and "smart objects".  As has been communicated
repeatedly; GIMP-2.10 and 3.0 are planned to have feature parity with
GIMP-2.8, and let the integration of GEGL as well as GEGL itself
mature with that - before experimenting with more non-destructive
features; non destructive user experiences with GEGL are - and have
been - experimented with outside the GIMP code base.


This is a very interesting statement.

Nondestructive editing is important.

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


Perhaps most of the people who currently use GIMP are satisfied with sRGB.

I rather suspect there's a lot of people who would love to use high bit 
depth GIMP, who absolutely have no intention of doing all their editing 
the sRGB color space.


What is a necessary feature in an image editor of course varies from 
person to person. Given a choice between PhotoShop and today's high bit 
depth GIMP, I choose GIMP, no hesitation. But that's because:


1. I get around the "sRGB only" issue by patching and building a 
modified copy of GIMP that is "Rec2020 only".


2. PhotoShop wasn't (and I'm told still isn't) really equipped to handle 
linear gamma image editing because of the quantization used for the 
Curves and Levels UI (this applies to 16-bit integer editing, I'm not 
sure what's going on with 32f editing in PhotoShop).


3. PhotoShop doesn't have GIMP's incredibly useful LCH blend modes.

4. I'm not a professional and don't have a high volume workflow. So not 
having macros and adjustment layers doesn't stand nearly as much in my 
way as it would if I had deadlines to meet.


5. Any chance that I would ever switch back to PhotoShop ended with 
Adobe's Creative Cloud:


* I find the idea that the artist's own work should be locked into 
a proprietary file format such as PhotoShop's PSD to be extremely 
distasteful. Adobe's move to the cloud has made this issue of who 
controls access to the artist's work crucially important.


* The Creative Cloud license agreement is onerous and one-sided 
(http://macperformanceguide.com/blog/2013/20130508_1a-Adobe-legal-agreement.html). 



* Once the artist stops paying the subscription fee, she loses 
access to the software that unlocks the proprietary PSD format that 
contains her creative work 
(https://forums.adobe.com/thread/1206477?start=0=0).


Reason number 5 above is why it seems to me that it's very important 
that GIMP be a viable alternative for would-be PhotoShop Creative Cloud 
refugees.


I understand that there are not enough GIMP developers to make changes 
in GIMP happen quickly.


I understand that it might be years before GIMP has macros and 
adjustment layers.


What I don't understand is why the ability to edit images in the RGB 
working space of the user's choice seems to be a low-priority item.


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

[Øyvind Kolås]

On Mon, Apr 4, 2016 at 4:19 PM, Partha Bagchi  wrote:
> Also, I would think that nondestructive
> editing would be high on the list (Photoshop's "Smart Objects").
>
> If I am not mistaken, Alex has already mentioned adjustment layers numerous
> times in past as a requirement/missing feature in GIMP.

One of the primary reason some of us have has as motivation for
working on GEGL and its integration in GIMP for more than a decade is
not high bit depth support, but non-destructive editing features like
"adjustment layers" and "smart objects". As has been communicated
repeatedly; GIMP-2.10 and 3.0 are planned to have feature parity with
GIMP-2.8, and let the integration of GEGL as well as GEGL itself
mature with that - before experimenting with more non-destructive
features; non destructive user experiences with GEGL are - and have
been - experimented with outside the GIMP code base.

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

[Partha Bagchi]

Totally agree with you. Color management would definitely be a priority for
high-end photo editing software. Also, I would think that nondestructive
editing would be high on the list (Photoshop's "Smart Objects").

If I am not mistaken, Alex has already mentioned adjustment layers numerous
times in past as a requirement/missing feature in GIMP.

On Mon, Apr 4, 2016 at 9:56 AM, Elle Stone 
wrote:

> On 03/27/2016 02:44 PM, C R wrote:
>
>> I've found that anything else would be a waste of
>> (everyone's) time. For some, nothing but Photoshop will work for their
>> graphics needs. It's no use arguing with them, because they have already
>> made up their mind, and it's more important to think they are correct than
>> it is to learn new things and expand your graphics tool-set.
>>
>
> Putting the serious limitations of 8-bit editing to one side, even high
> bit depth GIMP 2.9/2.10 lacks critically important components of the
> workflows of (lacking statistics, at least some) professional photographers
> currently using PhotoShop.
>
> For example, for at least some professional photographers, their workflow
> depends on:
>
> * The ability to edit in RGB working color spaces other than sRGB.
>
> * The ability to easily record and replay repetitive steps ("macros").
>  Without this ability, any degree of complexity in a high volume
> workflows means "high volume" isn't a realistic possibility unless you can
> figure out how to make the workday longer, in which case you are facing
> repetitive stress syndrome from typing in the same steps over and over, no
> doubt accompanied by mind-boggling amounts of tedious boredom.
>
> * The ability to use adjustment layers.
>  Without adjustment layers (or nodes which might even be better) for
> operations like Curves, Levels, Channel Mixer, etc the user canNOT go back
> and tweak intermediate results.
>
> However if you
>> can post a tutorial or links to show how the same effects can be done in
>> GIMP, it will go a long way to get others around to seeing what an
>> excellent tool GIMP is for pro-grade graphics work.
>>
>
> I am speaking specifically of photographic editing. I can't speak to
> graphics editing. In your estimation, is it the case that a pro-grade
> graphics workflow:
>
> * Doesn't ever require editing in RGB working spaces other than sRGB?
>
> * Doesn't ever require involve performing the same sequence of steps over
> and over again.
>
> * Wouldn't be made considerably more efficient by having adjustment layers?
>
> 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] suggestions

[Elle Stone]

On 03/27/2016 02:44 PM, C R wrote:

I've found that anything else would be a waste of
(everyone's) time. For some, nothing but Photoshop will work for their
graphics needs. It's no use arguing with them, because they have already
made up their mind, and it's more important to think they are correct than
it is to learn new things and expand your graphics tool-set.


Putting the serious limitations of 8-bit editing to one side, even high 
bit depth GIMP 2.9/2.10 lacks critically important components of the 
workflows of (lacking statistics, at least some) professional 
photographers currently using PhotoShop.


For example, for at least some professional photographers, their 
workflow depends on:


* The ability to edit in RGB working color spaces other than sRGB.

* The ability to easily record and replay repetitive steps ("macros").
 Without this ability, any degree of complexity in a high volume 
workflows means "high volume" isn't a realistic possibility unless you 
can figure out how to make the workday longer, in which case you are 
facing repetitive stress syndrome from typing in the same steps over and 
over, no doubt accompanied by mind-boggling amounts of tedious boredom.


* The ability to use adjustment layers.
 Without adjustment layers (or nodes which might even be better) 
for operations like Curves, Levels, Channel Mixer, etc the user canNOT 
go back and tweak intermediate results.



However if you
can post a tutorial or links to show how the same effects can be done in
GIMP, it will go a long way to get others around to seeing what an
excellent tool GIMP is for pro-grade graphics work.


I am speaking specifically of photographic editing. I can't speak to 
graphics editing. In your estimation, is it the case that a pro-grade 
graphics workflow:


* Doesn't ever require editing in RGB working spaces other than sRGB?

* Doesn't ever require involve performing the same sequence of steps 
over and over again.


* Wouldn't be made considerably more efficient by having adjustment layers?

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

[C R]

> > It would also be nice if people could see good reasons not to comment,
> > as one user has posted online (I think at answers.yahoo.com), that GIMP
> > is "not as good as Photoshop".
>
> What do you expect us to do about it?
>
> Alex
>

On answers.yahoo.com, it seems to me that anyone from the community could
just post a better answer. ;)
It's not really something to bother devs about though. More a community
outreach sort of thing. :)

-C





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

[Alexandre Prokoudine]

On Sun, Mar 27, 2016 at 8:22 PM, mailreader wrote:

> It would also be nice if people could see good reasons not to comment,
> as one user has posted online (I think at answers.yahoo.com), that GIMP
> is "not as good as Photoshop".

What do you expect us to do about it?

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

[C R]

I recommend this small change to the current download page:
www.opendesignstudio.org/gimp/samples/gimp_download_file_size.png

On Sun, Mar 27, 2016 at 7:44 PM, C R  wrote:

> Actually, I'm on Linux, and I don't see the file size listed either.
> I don't personally care much, because I know that GIMP is damn small
> compared to most high-powered graphics applications, but still I can see
> that some folks may care the first time they download from the website.
>
> If anything, the file size should be listed as a benefit to using GIMP. :)
>
> > It would also be nice if people could see good reasons not to comment,
> > as one user has posted online (I think at answers.yahoo.com), that GIMP
> > is "not as good as Photoshop".
>
> We're not anti-Photoshop, we are pro-GIMP. :) People can have their
> opinions, and we should either cheerfully accept them, or post friendly
> suggestions on how to do the Photoshop-like things they desire in GIMP to
> convince them otherwise. I've found that anything else would be a waste of
> (everyone's) time. For some, nothing but Photoshop will work for their
> graphics needs. It's no use arguing with them, because they have already
> made up their mind, and it's more important to think they are correct than
> it is to learn new things and expand your graphics tool-set. However if you
> can post a tutorial or links to show how the same effects can be done in
> GIMP, it will go a long way to get others around to seeing what an
> excellent tool GIMP is for pro-grade graphics work.
>
> My 2p.
> -C
>
> -
>
>
>
> On Sun, Mar 27, 2016 at 6:55 PM, Paka  wrote:
>
>> * mailrea...@juno.com  [03-27-16 13:30]:
>> > It would be nice if the website said how much free space is required to
>> > download the program and to run it, and what other things might be
>> > useful to use with it and where they can be found and how big they are.
>>
>> They are but you apparently are not familiar enough with your chosen
>> system to determine them.  You don't even mention what operating system
>> you use, but one might hazard a pretty accurate guess.
>>
>> > It would also be nice if people could see good reasons not to comment,
>> > as one user has posted online (I think at answers.yahoo.com), that GIMP
>> > is "not as good as Photoshop".
>>
>> But "nice" is unreasonable :)
>>
>> --
>> (paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
>> http://en.opensuse.orgopenSUSE Community Member
>> facebook/ptilopteri
>> http://wahoo.no-ip.orgPhoto Album:
>> http://wahoo.no-ip.org/gallery2
>> Registered Linux User #207535@
>> http://linuxcounter.net
>> ___
>> gimp-developer-list mailing list
>> List address:gimp-developer-list@gnome.org
>> List membership:
>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
>> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>>
>
>
___
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

[C R]

Actually, I'm on Linux, and I don't see the file size listed either.
I don't personally care much, because I know that GIMP is damn small
compared to most high-powered graphics applications, but still I can see
that some folks may care the first time they download from the website.

If anything, the file size should be listed as a benefit to using GIMP. :)

> It would also be nice if people could see good reasons not to comment,
> as one user has posted online (I think at answers.yahoo.com), that GIMP
> is "not as good as Photoshop".

We're not anti-Photoshop, we are pro-GIMP. :) People can have their
opinions, and we should either cheerfully accept them, or post friendly
suggestions on how to do the Photoshop-like things they desire in GIMP to
convince them otherwise. I've found that anything else would be a waste of
(everyone's) time. For some, nothing but Photoshop will work for their
graphics needs. It's no use arguing with them, because they have already
made up their mind, and it's more important to think they are correct than
it is to learn new things and expand your graphics tool-set. However if you
can post a tutorial or links to show how the same effects can be done in
GIMP, it will go a long way to get others around to seeing what an
excellent tool GIMP is for pro-grade graphics work.

My 2p.
-C

-



On Sun, Mar 27, 2016 at 6:55 PM, Paka  wrote:

> * mailrea...@juno.com  [03-27-16 13:30]:
> > It would be nice if the website said how much free space is required to
> > download the program and to run it, and what other things might be
> > useful to use with it and where they can be found and how big they are.
>
> They are but you apparently are not familiar enough with your chosen
> system to determine them.  You don't even mention what operating system
> you use, but one might hazard a pretty accurate guess.
>
> > It would also be nice if people could see good reasons not to comment,
> > as one user has posted online (I think at answers.yahoo.com), that GIMP
> > is "not as good as Photoshop".
>
> But "nice" is unreasonable :)
>
> --
> (paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
> http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
> http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2
> Registered Linux User #207535@ http://linuxcounter.net
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
>
___
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

[Paka]

* mailrea...@juno.com  [03-27-16 13:30]:
> It would be nice if the website said how much free space is required to
> download the program and to run it, and what other things might be
> useful to use with it and where they can be found and how big they are.

They are but you apparently are not familiar enough with your chosen
system to determine them.  You don't even mention what operating system
you use, but one might hazard a pretty accurate guess.

> It would also be nice if people could see good reasons not to comment,
> as one user has posted online (I think at answers.yahoo.com), that GIMP
> is "not as good as Photoshop".

But "nice" is unreasonable :)

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2
Registered Linux User #207535@ http://linuxcounter.net
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] suggestions

[mailrea...@juno.com]

It would be nice if the website said how much free space is required to 
download the program and to run it, and what other things might be useful to 
use with it and where they can be found and how big they are.
It would also be nice if people could see good reasons not to comment, as one 
user has posted online (I think at answers.yahoo.com), that GIMP is "not as 
good as Photoshop".

nowbuzzing
Horsing Around: Insane Photos of Ideas Gone Wrong
http://thirdpartyoffers.juno.com/TGL3131/56f816f71fbc616f61ec9st01vuc
___
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] suggestions

[wanderer]

Hello!

I'm new here, so first of all I would like to say it's a wonderful job 
that has been done in 2.8. Knowing a little bit of programming, I 
thought I might help with minor improvements to the software.


So, I came up with these little improvements to Gimp that would make it 
better, in my own point of view. I would like to share these suggestions 
to you, to see if they are really relevant. And I ask for your pardon if 
I am writing things that have already been discussed.


Here are the suggestions:

1- When you are using the scale or rotate tool and try to insert a 
guide, it doesn't close the tool.


2- add the option to snap guides at the border and/or center of layers 
bounds.


3 - add the option to autocrop layers to their limits (the same thing 
like when you do 'alpha to selection' then 'layers - crop to 
selection') whenever you change it.


4 - add a checkbox button in the scale tool for scale from center. Maybe 
add also a keyboard shortcut for it.


For the fourth suggestion I saw an entry in bug list, where a complete 
system of anchor for scale was intended to be made. So this could be an 
temporary fix for something I think it's important. I know that you can 
scale from center using layer-scale layer, but I though why scale tool 
don't do it?


Also, as I said before, if you think any of the suggestions are good 
ones I could try to implement them myself. But I am really new here, so 
I think I would have to understand the code and the development proccess 
first. I could make it a plug-in or script, but if I am going to code it 
and it's relevant, I thought I might do it directly to the source code 
of the program. And, of course, it would be a great honor to contribute 
with a software and philosophy that I admire.


Thanks for the attention!

freewanderer
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list