GNOME.org
 

Re: [Gimp-developer] suggestions

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


On Mon, Apr 4, 2016 at 2:56 PM, Elle Stone
<ellestone ninedegreesbelow com <mailto:ellestone ninedegreesbelow com>>
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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]