* mailreader@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.org    openSUSE Community Member    facebook/ptilopteri
http://wahoo.no-ip.org        Photo Album: http://wahoo.no-ip.org/gallery2
Registered Linux User #207535                    @ http://linuxcounter.net

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:

* mailreader@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.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo 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

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

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:

* mailreader@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.org openSUSE Community Member facebook/ptilopteri
http://wahoo.no-ip.org Photo 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

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

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

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

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

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&tstart=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

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

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 producing anything worth looking. Ditto for working in larger RGB working spaces.

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

There is a batch processor for GIMP. It's not quite as nice as Photoshop's actions dialog, but gets the job done. I personally prefer to use imagemagick and "open terminal here" feature in nautilus. It's much faster than Photoshop's batch processor for my purposes.

I'm not talking about batch processing. I'm talking about things like "open image convert precision add small amount of RGB noise", "drag out as separate layer resize convert to output color space", "pull out R, G, B channels as layers make duplicate of original layer and make luminance conversion to black and white". In other words, macros for replaying repetitive steps in a mask-and-layers workflow.

If you require Photoshop's action dialog, use Photoshop. (Or write a better one for GIMP)

For me not having the ability to record/replay steps is a relatively minor issue. But I don't have anything like a high volume output.

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

I gotta say, that doesn't come up very often in my graphics workflows. Would it be nice to have? Sure, it would. Hardly a deal-breaker though...

For you the lack of adjustment layers is not a deal breaker. For me it's not a deal-breaker. For some people's workflow, it's a bit of a deal breaker, though based on feedback I get, much less so than the inability to edit in working spaces other than sRGB, and even less so than the ability to record/replay a set of editing steps.

I get plenty of non-destructive editing with GIMP's layer blending modes and masks. So it's not like there isn't *anything*.

Sure, it could be way better. It does not make GIMP unusable to do graphics or photo work.

I haven't said that at all. For example, see my tutorial on using high bit depth GIMP's unbounded Levels for shadow recovery/tone-mapping: http://ninedegreesbelow.com/photography/gimp-tone-map-with-levels.html

There is a whole lot one can do in the direction of non-destructive editing using GIMP exactly as it is. This is part of why I don't understand why non-destructive editing seems to have a much higher priority for being implemented in GIMP than editing in working spaces other than sRGB.

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:

My workflows require both in-house photography, photo editing and graphics production, but sure, let's have a look...

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

What do I care? I can do anything with GIMP. I can produce any visual effect I want.
Do you really care how I get there?

But you see, obviously you don't want to produce visual effects that require colors outside the sRGB color gamut. The fact that sRGB works for all the things you want to do is completely irrelevant to the fact that sRGB *doesn't* work for all editing tasks and goals that other people have.

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

It would be considerably more efficient if someone would fix the damn transform preview so it gets rid of the original, and gets the (useless) guides out of your way so you can see what you're doing. :)

Here here! Yes! That dialog is painful.

LOTS of things in GIMP could use efficiency tweaks, however they are minor annoyances compared to the all the benefits of using GIMP, imho.

I agree 100%, other than the inability to edit in color spaces other than sRGB. For me and for many people the inability to edit in working spaces other than sRGB is a complete *100%* deal-breaker.

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.

It's not perfect, but there is a lot to love about it. I've been very successful at getting professional results out of it. ymmv of course.

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.

I recommend letting new users try out GIMP and see how it works for them, rather than confronting them with all the criticisms the whole world has for it. I heard the criticisms from day 1, but I'm a bit different. I love to explore, and when someone tells me I can't do something, my first reaction is to try and see if can anyway. I didn't set out to replace Photoshop with GIMP, I just liked having graphics tools that worked in Linux. It was an extension of my graphics toolset, and then eventually replaced it entirely.

On the other hand, I DID start out to replace PhotoShop with something better, though at the time I wasn't thinking about GIMP. PhotoShop did not suit my editing style and goals particularly well. High bit depth GIMP, or rather my patched version of high bit depth GIMP, does. Perhaps my perspective is a bit different, but unless PhotoShop has changed a lot in the last ten years I would have a *very* difficult time trying to replace GIMP with PhotoShop.

Learning new tools should never be an issue for artists, and the idea of a free and open source tool for doing pro graphics work should be exciting enough to try. It paid off a lot for me, so I'm happy to recommend people try it.

I don't suppose you've noticed that quite a few articles on my website are about using GIMP and getting acquainted with the rather amazing editing possibilities that high bit depth GIMP brings to the table?

Now if we just had the capability to edit in RGB working spaces other than sRGB without having to patch GIMP . . .

The GIMP team is doing an excellent job. Keep up the awesome work! :)

Yes, they really are doing awesome work. Yesterday I dredged up and compiled a copy of babl/GEGL/GIMP from May of 2014 and I am AMAZED at the progress since then.

On another note: Nice work on the new layer blending modes to GIMP (and the linear light stuff as well). I really like them, and everything else you've done with the project. So keep pushing, challenging, etc. :)

Thanks! But I'm not sure what you mean by the linear light stuff, and I'm only one of a whole bunch of people who worked really hard on the LCH layer blending modes. The original idea was proposed a long time ago, and Massimo and Thomas Manni did all the hard parts of the coding.

Best, Elle

http://ninedegreesbelow.com
Color management and free/libre photography

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 pictures. You can compensate a little with expensive camera equipment, but generally it's worth just learning how to light a scene properly before snapping the picture (and bracketing if necessary).

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.

I have a 500GB hard drive full of RAW images. I may get around to processing them someday.
Fortunately I shot RAW+jpeg, so I've gotten good use out of most of the pictures anyway. ;)

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. That said, I'd like to see more RAW editing features in GIMP. maybe I'll get time again some day. :)

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

I love reading your articles, even if some of them are a bit over my head. You should publish a book. It would be wonderful to include in a well-rounded graphics education at university level.

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 producing anything worth looking. Ditto for working in larger RGB working spaces.

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

There is a batch processor for GIMP. It's not quite as nice as Photoshop's actions dialog, but gets the job done. I personally prefer to use imagemagick and "open terminal here" feature in nautilus. It's much faster than Photoshop's batch processor for my purposes.

I'm not talking about batch processing. I'm talking about things like "open image convert precision add small amount of RGB noise", "drag out as separate layer resize convert to output color space", "pull out R, G, B channels as layers make duplicate of original layer and make luminance conversion to black and white". In other words, macros for replaying repetitive steps in a mask-and-layers workflow.

What you are describing is batch processing. :) Performing predefined actions on one (or more) images is batch processing. Photoshop's method of defining the batch actions by hitting a record button is very nice, of course.
It's not as easy with GIMP, but it's also not impossible. I'd welcome an action editor, and may have occasion to use it. I've used scripts for similar things.

If you require Photoshop's action dialog, use Photoshop. (Or write a better one for GIMP)

For me not having the ability to record/replay steps is a relatively minor issue. But I don't have anything like a high volume output.

Me neither, but for high volume output, Photoshop might not cut it either. It's really slow compared to imagemagick, for example. :)

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

I gotta say, that doesn't come up very often in my graphics workflows. Would it be nice to have? Sure, it would. Hardly a deal-breaker though...

For you the lack of adjustment layers is not a deal breaker. For me it's not a deal-breaker. For some people's workflow, it's a bit of a deal breaker, though based on feedback I get, much less so than the inability to edit in working spaces other than sRGB, and even less so than the ability to record/replay a set of editing steps.

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.

Of course, people with deals that are Photoshop-specific deals will only be happy with Photoshop.

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

I get plenty of non-destructive editing with GIMP's layer blending modes

and masks. So it's not like there isn't *anything*.

Sure, it could be way better. It does not make GIMP unusable to do

graphics or photo work.

I haven't said that at all. For example, see my tutorial on using high bit depth GIMP's unbounded Levels for shadow recovery/tone-mapping: http://ninedegreesbelow.com/photography/gimp-tone-map-with-levels.html

Bookmarked. Thanks for the tutorial!

There is a whole lot one can do in the direction of non-destructive editing

using GIMP exactly as it is. This is part of why I don't understand why non-destructive editing seems to have a much higher priority for being implemented in GIMP than editing in working spaces other than sRGB.

Well, with community software, I think people work on what they want to mostly. Or at least that's the impression I get. I have no insider information though. :) I'm happy to play with all the new toys added to GIMP when stuff gets added.

But you see, obviously you don't want to produce visual effects that require colors outside the sRGB color gamut. The fact that sRGB works for all the things you want to do is completely irrelevant to the fact that sRGB *doesn't* work for all editing tasks and goals that other people have.

It's not that I don't want to, it's that it's not necessary to produce my professional work, so I don't care as much. If it's something people care enough about, it will get implemented (maybe). :) It's a hard sell to most designers though, since we work heavily in web and advertisements in print, and neither typically require the fine colour detail your article highlights. I'm not saying it isn't useful, but I understand why it's not priority over GEGL integration...

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

It would be considerably more efficient if someone would fix the damn transform preview so it gets rid of the original, and gets the (useless) guides out of your way so you can see what you're doing. :)

Here here! Yes! That dialog is painful.

The best I could get was to wheedle someone into fixing it so we can again hide the layer while transforming without having it break. I can't, for the life of me, understand why it's not auto-hidden during the transform. It's the very first thing everyone complains about when I show them GIMP transform tools. I just have to grit my teeth and be like, "yea, it's annoying, but at least you can get around it."

LOTS of things in GIMP could use efficiency tweaks, however they are minor annoyances compared to the all the benefits of using GIMP, imho.

I agree 100%, other than the inability to edit in color spaces other than sRGB. For me and for many people the inability to edit in working spaces other than sRGB is a complete *100%* deal-breaker.

Gotcha. :)

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?

It's not perfect, but there is a lot to love about it. I've been very

successful at getting professional results out of it. ymmv of course.

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?

On the other hand, I DID start out to replace PhotoShop with something better, though at the time I wasn't thinking about GIMP. PhotoShop did not suit my editing style and goals particularly well. High bit depth GIMP, or rather my patched version of high bit depth GIMP, does. Perhaps my perspective is a bit different, but unless PhotoShop has changed a lot in the last ten years I would have a *very* difficult time trying to replace GIMP with PhotoShop.

Nice!

Learning new tools should never be an issue for artists, and the idea of

a free and open source tool for doing pro graphics work should be exciting enough to try. It paid off a lot for me, so I'm happy to recommend people try it.

I don't suppose you've noticed that quite a few articles on my website are about using GIMP and getting acquainted with the rather amazing editing possibilities that high bit depth GIMP brings to the table?

Oh yes, which is why your comments confused me a bit. :)

Now if we just had the capability to edit in RGB working spaces other than sRGB without having to patch GIMP . . .

On another note: Nice work on the new layer blending modes to GIMP (and

the linear light stuff as well). I really like them, and everything else you've done with the project. So keep pushing, challenging, etc. :)

Thanks! But I'm not sure what you mean by the linear light stuff, and I'm only one of a whole bunch of people who worked really hard on the LCH layer blending modes. The original idea was proposed a long time ago, and Massimo and Thomas Manni did all the hard parts of the coding.

In development build (gimp-edge)

Image > Precision > Linear Light

The other option is "Perceptual Gamma (sRGB)"

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.

Respect, -C

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

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

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

timeline for past GIMP releases:

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

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

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

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

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

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

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 waaaaay down.

Best,
Elle

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

On 04/05/2016 01:06 PM, Elle Stone wrote:

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.

It was suggested that I start a new thread on this topic, so I did:

https://mail.gnome.org/archives/gimp-developer-list/2016-April/msg00053.html

Best, Elle