> 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
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
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 (
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
> 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 (
> 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 (
> especially see
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
> 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
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
>> 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
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:
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
>> 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.
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.
> 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
Note also up to 64bit precision now.
gimp-developer-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list