Sign up now! · Forgot password?
RSS/Atom feed identi.ca Twitter

Soft proofing and the GIMP Display Filters and Color Management settings

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

28 of 29 messages available
Toggle history

Please log in to manage your subscriptions.

Soft proofing and the GIMP Display Filters and Color Management settings Elle Stone 02 Mar 17:51
  Soft proofing and the GIMP Display Filters and Color Management settings Alexandre Prokoudine 03 Mar 08:16
   Soft proofing and the GIMP Display Filters and Color Management settings Elle Stone 10 Mar 12:55
    Soft proofing and the GIMP Display Filters and Color Management settings Liam R E Quin 10 Mar 20:06
     Soft proofing and the GIMP Display Filters and Color Management settings Gez 11 Mar 01:03
      Soft proofing and the GIMP Display Filters and Color Management settings Liam R E Quin 11 Mar 01:30
     Soft proofing and the GIMP Display Filters and Color Management settings Elle Stone 11 Mar 11:16
      Soft proofing and the GIMP Display Filters and Color Management settings Omari Stephens 11 Mar 18:39
       Soft proofing and the GIMP Display Filters and Color Management settings Elle Stone 12 Mar 21:27
        Soft proofing and the GIMP Display Filters and Color Management settings Alexandre Prokoudine 12 Mar 22:00
        Soft proofing and the GIMP Display Filters and Color Management settings Gez 13 Mar 02:42
        Soft proofing and the GIMP Display Filters and Color Management settings Øyvind Kolås 14 Mar 02:37
         Soft proofing and the GIMP Display Filters and Color Management settings Elle Stone 14 Mar 13:21
          Soft proofing and the GIMP Display Filters and Color Management settings Øyvind Kolås 14 Mar 14:34
           Soft proofing and the GIMP Display Filters and Color Management settings Elle Stone 16 Mar 21:22
            Soft proofing and the GIMP Display Filters and Color Management settings Øyvind Kolås 17 Mar 16:44
      Soft proofing and the GIMP Display Filters and Color Management settings Gez 11 Mar 18:45
       Soft proofing and the GIMP Display Filters and Color Management settings Liam R E Quin 12 Mar 06:19
        1394657032.8484.55.camel@oh... 13 Mar 04:02
         Soft proofing and the GIMP Display Filters and Color Management settings Liam R E Quin 13 Mar 03:35
          Soft proofing and the GIMP Display Filters and Color Management settings Gez 13 Mar 04:19
           Soft proofing and the GIMP Display Filters and Color Management settings Liam R E Quin 13 Mar 06:36
            Soft proofing and the GIMP Display Filters and Color Management settings Gez 13 Mar 19:45
             Soft proofing and the GIMP Display Filters and Color Management settings Liam R E Quin 13 Mar 19:54
        Soft proofing and the GIMP Display Filters and Color Management settings Gez 13 Mar 04:05
         Soft proofing and the GIMP Display Filters and Color Management settings Omari Stephens 13 Mar 06:43
          Soft proofing and the GIMP Display Filters and Color Management settings Gez 13 Mar 15:53
           Soft proofing and the GIMP Display Filters and Color Management settings Gez 13 Mar 16:24
  Soft proofing and the GIMP Display Filters and Color Management settings Omari Stephens 05 Mar 09:26
Elle Stone
2014-03-02 17:51:23 UTC (10 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

I've been reading through the various sections of the online GIMP documentation that relate to color management, which prompted me to take a closer look at the Display Filters.

Most of the observations below are related to the Color Management and Color Proof ("Soft Proof") Display filters. As background for people who haven't used soft proofing, soft proofing isn't just for preparing an image to be printed on paper. Rather it's useful any time an image is destined for display on a device other than the one on which it was created (eg a digital photo frame on a wall). It's also useful when an image is to be converted from one ICC profile to another (eg when converting from ProPhoto or a camera or scanner input profile to sRGB).

"Edit/Preferences/Color Management" settings are global, affecting all open images. Choices made in "View/Color Display Filters" are applied on a per image basis. At present "View/Color Display Filters" and "Edit/Preferences/Color Management" interact in sometimes very unexpected ways, especially when the user sends multiple copies of the various Display filters over to the Active filter list. Some expected and unexpected results of using the Display Filters are:

a. If "Edit/Preferences/Color Management" is set to "Color managed display" and "View/Color Display Filters" has the Color Management Filter active (which it is by default), then unchecking the Color Management Display filter disables color management for the image for which the "View/Color Display Filters" dialog was opened. This makes sense and is an example of using the per image Display Filters to override the Color Management Settings global settings.

b. If "Edit/Preferences/Color Management" is set to "No color management" and "View/Color Display Filters" has the Color Management Filter active, then "View/Color Display Filters" Active Color Management filter doesn't override the "No color management" choice made in the Preference/Color Management dialog. In this case the per image choice doesn't override the global choice.

c. The Color Proof Display Filter works when color management is disabled. This provides accurate results if (and only if) the monitor is calibrated to exactly match sRGB - not too likely given today's LCD monitors, but still theoretically possible.

d. The Color Proof Display Filter doesn't provide the option to enable and disable marking out of gamut colors.

e. If the "Mode of operation" is set to "Print simulation" in the globally applied "Edit/Preferences/Color Management" settings dialog, and if the user also chooses to activate the per image "Color Proof" display filter, then the global choices made in the Color Management settings are applied on top of the per image choices made in the Color Proof Display filter, and the results are wrong.

f. Multiple active copies of the Color Proof Display Filter in turn apply each copy's soft proofing choices, with increasingly wrong results.

g. One active copy of the Color Management display filter acts as expected. But multiple active copies of the Color Management display filter each in turn apply the conversion from the image ICC profile to the monitor ICC profile. If the monitor ICC profile is "none" or is sRGB, the multiple active Color Management filters make no difference. But when using an actual monitor profile (sRGB doesn't adequately describe LCD monitors), successively applying multiple copies of the Color Management filter results in increasingly noticeable and wrong color and tonality changes.

h. Multiple active copies of the Contrast and Gamma filters also are applied successively. This seems unlikely to be useful.

i. Multiple active copies of the Color Deficient Vision filter also add one to the other, but only if different Color deficiency types are chosen. Once one each of insensitivity to red, green, and blue are chosen, additional active Color Deficient Vision filters make no difference in what's shown on the screen (for example, removing green twice doesn't make magenta).

I don't know how difficult it would be to change the way the per image Display Filters currently interact with the global Color Management settings, but I put together some suggestions in hope of starting a discussion:

1. In the Display Filters dialog, the user should only be able to send one copy of the Available Filters over to the Active Filters panel. To compensate, the Active Color Deficient Vision filter should have a list with check boxes rather than a drop-down menu, so the user could check one, two, or all three types at the same time.

2. The Color Management and Color Proof display filters should both be in the Active Filter list by default, with Color Management checked by default and Color Proofing unchecked by default.

3. If the user has already chosen to be in "Print Simulation Mode of operation" in the "Preferences/Color Management" dialog, then that choice affects all open images. But for those images for which the user has also activated the Color Proof display filter, choices made in the display filter should completely override choices made in the Color Management Preferences dialog. This includes not only the proofing profile but also the rendering intent and whether or not to use black point compensation. In no case should a choice made in the display filter "add to" the effect of a choice made in the "Preferences/Color Management" dialog.

4. The Color Proof display filter should include the option to enable and disable marking out of gamut colors, overriding any choice made in "Preferences/Color Management".

5. Currently the Active Color Proof display filter opens with no choices having been preselected. Instead the Color Proof display filter settings should default to showing the soft proofing choices that were already made in the global Color Management Preferences. That way, if the user wants to change all of the global settings for just the one image, the same number of clicks are required, but if the user only wants to change one or two settings, fewer clicks are required.

6. The "Color Proof" display filter should be labelled "Soft Proof" to be consistent with terminology used in the global Color Management Settings. And the Color Management Settings "Print simulation" Mode of operation should read "Device/Profile simulation", to provide a hint to the user that soft proofing covers more than just preparing an image for printing.

7. Users who have color management disabled in "Preferences/Color Management" should have the option to enable color management on a per image basis using the Color Management display filter dialog, parallel to the current option to use the display filters to disable color management on a per image basis.

8. At present, when Color Management is activated, which rendering intent to use and whether or not to use black point compensation are only controllable via the "Preferences/Color Management" dialog, which affects all open images. These same options should also be available in the Active Color Management display filter (defaulting to the same choices that were made in the Preferences/Color Management dialog), so they can be changed on a per image basis.

9. Some people have more than one monitor profile, for example a matrix profile for image editing and one or more LUT profiles for soft proofing. So it would be useful to be able to use the Active Color Management display filter to override the globally set monitor profile on a per image basis.

10. Because the Display Filters apply on a per image basis, the user needs to be able to tell at a glance which open image is affected by which Display Filter dialog. Perhaps the Display Filter title bar could display the image file name so the user knows exactly which image which be affected by a change in an open Display Filter dialog. Or perhaps clicking on an image could also highlight the corresponding Display Filter dialog. Or perhaps the Display Filter dialog really should be in an Image drop-down menu rather than a separately opened, stand-alone dialog box.

11. I'm not clear on the intended use cases for the Contrast, Gamma, and Color deficiency Display Filters (emulation? compensation?). But if there are users who need these Filters applied routinely for all images, then these Filters should also be in the global Preferences/Color Management Settings dialog.

Cheers, Elle

Alexandre Prokoudine
2014-03-03 08:16:32 UTC (10 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

02 2014 . 21:46 "Elle Stone" <
ellestone@ninedegreesbelow.com> :

4. The Color Proof display filter should include the option to enable and

disable marking out of gamut colors, overriding any choice made in "Preferences/Color Management".

IMO, it's worth having a look how much we can salvage from http://registry.gimp.org/node/24944.

Alexandre

Omari Stephens
2014-03-05 09:26:44 UTC (10 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

First and foremost, it's nice to see someone working on GIMP color management again, so yay :o)

All of the suggestions seem reasonable for me. That said, additionally, I think it'd be really useful to be able to enable or disable soft-proofing quickly. It would be independently useful to be able to enable or disable out-of-gamut color marking quickly.

The usecase here is that, suppose I'm working up an image for print. Let's say I want to adjust the curves of the image so that I get a reasonable amount of shadow detail, but not so much that I get shadow banding (as from running out of dynamic range in the shadows). I'll want out-of-gamut colors enabled in order to judge how much shadow detail will actually show up in print. But I'll want it _disabled_ to judge banding, since the contrasting "out-of-gamut" color tends to make gradients really difficult to evaluate.

--xsdg doppler-photo.net

Elle Stone
2014-03-10 12:55:20 UTC (10 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On 03/03/2014 03:16 AM, Alexandre Prokoudine wrote:

02 2014 . 21:46 "Elle Stone" <
ellestone@ninedegreesbelow.com> :

4. The Color Proof display filter should include the option to enable and

disable marking out of gamut colors, overriding any choice made in "Preferences/Color Management".

IMO, it's worth having a look how much we can salvage from http://registry.gimp.org/node/24944.

Alexandre

I downloaded the Color Management+ display filter plugin code. It does use lcms1. So I'm reading through the CM+ code and the LCMS2 documentation, the goal being to match LCMS2 functions up with the lcms1 functions used by the the plugin.

Soft proofing of course is used for more than just converting an RGB image to a CMYK color space. But probably the very useful CM+ plugin features (gray scale channel displays, for example) could be generalized.

On 03/05/2014 04:26 AM, Omari Stephens wrote:

First and foremost, it's nice to see someone working on GIMP color management again, so yay :o)

The odd behavior of the display filters came to my attention because I've been working on rewriting some of the GIMP color management documentation and so took a closer look at what all the display filters do.

As the display filters currently can be used to do strange and completely wrong things, it seemed better to try to fix the filters than write documentation about what not to do when using them! Feedback, requests, observations, etc are very welcome. I'll collect everything into a bug report/enhancement request and also keep looking at the code to see where/how to make changes.

All of the suggestions seem reasonable for me. That said, additionally, I think it'd be really useful to be able to enable or disable soft-proofing quickly. It would be independently useful to be able to enable or disable out-of-gamut color marking quickly.

The usecase here is that, suppose I'm working up an image for print. Let's say I want to adjust the curves of the image so that I get a reasonable amount of shadow detail, but not so much that I get shadow banding (as from running out of dynamic range in the shadows). I'll want out-of-gamut colors enabled in order to judge how much shadow detail will actually show up in print. But I'll want it _disabled_ to judge banding, since the contrasting "out-of-gamut" color tends to make gradients really difficult to evaluate.

--xsdg doppler-photo.net

I agree 100% that soft proofing requires the ability to quickly switch gamut checks on and off, and also quickly enable/disable soft proofing.

Another question:

A common way to soft proof requires having the image open twice to compare the original with the soft proofed version.

The current GIMP preferences allow you to choose "Print Simulation" in "Preferences/Color Management/Mode of operation". But that sets *all* open images to Print Simulation mode, for which I can't think of any use cases.

So perhaps the option to choose Print Simulation mode should be removed from "Preferences/Color Management/Mode of operation", but leave the ability to choose soft proofing presets for those people who routinely softproof to a particular output profile. Any thoughts? Does anyone have an actual use case for putting all open images in Printer Simulation mode?

Elle

Liam R E Quin
2014-03-10 20:06:07 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On Mon, 2014-03-10 at 08:55 -0400, Elle Stone wrote:

The odd behavior of the display filters came to my attention because I've been working on rewriting some of the GIMP color management documentation and so took a closer look at what all the display filters do.

Documenting (briefly) the wrongness might help demonstrate what needs to be done, too.

I agree 100% that soft proofing requires the ability to quickly switch gamut checks on and off, and also quickly enable/disable soft proofing.

+1 although for print work at this point you have to move to Krita or Photoshop, most likely photoShop with a "preflight" plugin, so that you can adjust individual plates (e.g. with dodge) for the different ink colours (CMYK at the most basic, or two plates for a duotone).

The decision is (as I understand it) for GIMP to stay out of the print shop so this all gets a little fuzzy for me.

But there are plenty of non-print use cases for soft proofing, of course, including e.g. targeting a specific mobile device (even though there's huge variation between individuals, there are basic limits on the colour you can usefully work with) or for projection at a conference or in an art gallery.

A common way to soft proof requires having the image open twice to compare the original with the soft proofed version.

Yes. It's unfortunate that Single Window Mode makes this hard.

The current GIMP preferences allow you to choose "Print Simulation" in "Preferences/Color Management/Mode of operation". But that sets *all* open images to Print Simulation mode, for which I can't think of any use cases.

No - a display filter makes more sense, agreed. Then you could maybe make the filter apply be default to all images if you really wanted?

There should be (is??) a way to include something in the title bar and/or status bar to show which display filters are active.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Gez
2014-03-11 01:03:34 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

El lun, 10-03-2014 a las 16:06 -0400, Liam R E Quin escribió:

+1 although for print work at this point you have to move to Krita or Photoshop, most likely photoShop with a "preflight" plugin, so that you can adjust individual plates (e.g. with dodge) for the different ink colours (CMYK at the most basic, or two plates for a duotone).

That's not entirely true.
You could use an intermediate or late binding workflow, do the creative part in RGB and convert to CMYK later. IMO, although early binding has a couple of advantages, tweaking the CMYK plates individually gives you the false illusion that you have extra control, and you can easily end up screwing your output unless you know exactly what you're doing (for instance exceeding the recommended TAC for your output).
I've been working for print using free software for the last 6 or 7 years, and GIMP is part of my pipe. I have some tricks for duotones/tri-tones that I had to develop out of necessity (it's true that GIMP's UI doesn't offer a handy way to create them, but combining the decompose tool with the Separate+ plugin you can get very good results).
I think it's just matter of workflows, and although GIMP isn't suited for early binding, it can provide a reasonable set of tools for intermediate and late binding.
And because of this, soft proofing is extremely important. You can use RGB for print, but you need a reliable set of tools to proof colors against the desired output, and you need them to be handy.

Gez.

Liam R E Quin
2014-03-11 01:30:00 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On Mon, 2014-03-10 at 22:03 -0300, Gez wrote:

El lun, 10-03-2014 a las 16:06 -0400, Liam R E Quin escribi:

+1 although for print work at this point you have to move to Krita or Photoshop, most likely photoShop with a "preflight" plugin, so that you can adjust individual plates (e.g. with dodge) for the different ink colours (CMYK at the most basic, or two plates for a duotone).

That's not entirely true.
You could use an intermediate or late binding workflow, do the creative part in RGB and convert to CMYK later. IMO, although early binding has a couple of advantages, tweaking the CMYK plates individually gives you the false illusion that you have extra control, and you can easily end up screwing your output unless you know exactly what you're doing (for instance exceeding the recommended TAC for your output).

Yes, totally agree, I think I wasn't clear - when I said "the print shop" I meant the pressroom, the chapel ;), and was not referring to an agency that sends things off out-of-house to printers. GIMP is certainly central to a workflow in which the person editing the image isn't the person who will have to worry about ink coverage and trapping and bleed...

Pippin also kindly reminded me on IRC of a talk by Peter Sikking, which I had forgotten, and which showed that he had moderated his position to be more accommodating of needs of people preparing for print...

[...]

soft proofing is extremely important. You can use RGB for print, but you need a reliable set of tools to proof colors against the desired output, and you need them to be handy.

+1

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Elle Stone
2014-03-11 11:16:07 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On 03/10/2014 04:06 PM, Liam R E Quin wrote:

On Mon, 2014-03-10 at 08:55 -0400, Elle Stone wrote:

The odd behavior of the display filters came to my attention because I've been working on rewriting some of the GIMP color management documentation and so took a closer look at what all the display filters do.

Documenting (briefly) the wrongness might help demonstrate what needs to be done, too.

In the original post, e - i and especially e, f, g describe odd and wrong results:

On 03/02/2014 12:51 PM, Elle Stone wrote:

e. If the "Mode of operation" is set to "Print simulation" in the globally applied "Edit/Preferences/Color Management" settings dialog, and if the user also chooses to activate the per image "Color Proof" display filter, then the global choices made in the Color Management settings are applied on top of the per image choices made in the Color Proof Display filter, and the results are wrong.

f. Multiple active copies of the Color Proof Display Filter in turn apply each copy's soft proofing choices, with increasingly wrong results.

g. One active copy of the Color Management display filter acts as expected. But multiple active copies of the Color Management display filter each in turn apply the conversion from the image ICC profile to the monitor ICC profile. . . .
when using an actual monitor profile (sRGB doesn't adequately describe LCD monitors), successively applying multiple copies of the Color Management filter results in increasingly noticeable and wrong color and tonality changes.

e is just wrong behavior.

f and g could be considered the result of users not thinking about what they are doing. But the display filter gui shouldn't allow dragging multiple copies of the Color Management or Soft Proofing display filters over to the active pane as doing so makes no sense at all.

I agree 100% that soft proofing requires the ability to quickly switch gamut checks on and off, and also quickly enable/disable soft proofing.

+1 although for print work at this point you have to move to Krita or Photoshop, most likely photoShop with a "preflight" plugin, so that you can adjust individual plates (e.g. with dodge) for the different ink colours (CMYK at the most basic, or two plates for a duotone).

The decision is (as I understand it) for GIMP to stay out of the print shop so this all gets a little fuzzy for me.

I don't know anything about CMYK printing and I've never used the CM+ plugin, so please bear with me while I ask a couple of questions:

Putting *editing* CMYK channels to one side, is it useful to modifythe RGB channels while soft proofing to a CMYK profile (or even n-channel profile whether color or black and white)? I thought that was what the CM+ plugin made possible? Is this an example of what Gez calls "late binding"?

But there are plenty of non-print use cases for soft proofing, of course, including e.g. targeting a specific mobile device (even though there's huge variation between individuals, there are basic limits on the colour you can usefully work with) or for projection at a conference or in an art gallery.

There's also converting from a camera input profile to an RGB working space, and from one RGB working space to another, and from a larger RGB working space to sRGB for display on the web. Also, some commercial printers (for example, some print shops with Chromira and Frontier printers) provide RGB printer profiles to customers to use when soft proofing.

A common way to soft proof requires having the image open twice to compare the original with the soft proofed version.

Yes. It's unfortunate that Single Window Mode makes this hard.

The current GIMP preferences allow you to choose "Print Simulation" in "Preferences/Color Management/Mode of operation". But that sets *all* open images to Print Simulation mode, for which I can't think of any use cases.

No - a display filter makes more sense, agreed. Then you could maybe make the filter apply be default to all images if you really wanted? There should be (is??) a way to include something in the title bar and/or status bar to show which display filters are active.

Having the title/status bar(s) show which display filters are active would be very useful, especially given that if you close the display filter window, any activated filters (or deactivated, in the case of the Color Management filter) are still applied to the image.

Elle

Omari Stephens
2014-03-11 18:39:57 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On 03/11/2014 11:16 AM, Elle Stone wrote:

On 03/10/2014 04:06 PM, Liam R E Quin wrote:

On Mon, 2014-03-10 at 08:55 -0400, Elle Stone wrote:

::snip? SNIP!::

I agree 100% that soft proofing requires the ability to quickly switch gamut checks on and off, and also quickly enable/disable soft proofing.

+1 although for print work at this point you have to move to Krita or Photoshop, most likely photoShop with a "preflight" plugin, so that you can adjust individual plates (e.g. with dodge) for the different ink colours (CMYK at the most basic, or two plates for a duotone).

The decision is (as I understand it) for GIMP to stay out of the print shop so this all gets a little fuzzy for me.

I don't know anything about CMYK printing and I've never used the CM+ plugin, so please bear with me while I ask a couple of questions:

Putting *editing* CMYK channels to one side, is it useful to modifythe RGB channels while soft proofing to a CMYK profile (or even n-channel profile whether color or black and white)? I thought that was what the CM+ plugin made possible? Is this an example of what Gez calls "late binding"?

early binding == "you send CMYK to the person who prints your work" late binding == "you send RGB to the person who prints your work, and they convert to CMYK"

You are correct that CM+ supports "separations" (which is the word for looking at each channel individually). But in that case, this would be part of an early-binding workflow, because you're touching CMYK rather than just RGB.

That said, I think your question touches on something that I'm pretty ignorant about, which is how color profiles deal with different numbers and types of channels. I know there is a thing called a GRAY profile, but I have no idea what makes it special or different than a standard profile. Is it basically an RGB profile with R==G==B?

In the New GEGL World, converting between different channel layouts is going to be a reality, and we should at least put _some_ thought into what that means for color management. Of course, this is way out of my depth, and I have no idea.

But there are plenty of non-print use cases for soft proofing, of course, including e.g. targeting a specific mobile device (even though there's huge variation between individuals, there are basic limits on the colour you can usefully work with) or for projection at a conference or in an art gallery.

There's also converting from a camera input profile to an RGB working space, and from one RGB working space to another, and from a larger RGB working space to sRGB for display on the web. Also, some commercial printers (for example, some print shops with Chromira and Frontier printers) provide RGB printer profiles to customers to use when soft proofing.

These are the usecases that matter to me, so yes :o)

A common way to soft proof requires having the image open twice to compare the original with the soft proofed version.

Yes. It's unfortunate that Single Window Mode makes this hard.

The current GIMP preferences allow you to choose "Print Simulation" in "Preferences/Color Management/Mode of operation". But that sets *all* open images to Print Simulation mode, for which I can't think of any use cases.

No - a display filter makes more sense, agreed. Then you could maybe make the filter apply be default to all images if you really wanted? There should be (is??) a way to include something in the title bar and/or status bar to show which display filters are active.

Having the title/status bar(s) show which display filters are active would be very useful, especially given that if you close the display filter window, any activated filters (or deactivated, in the case of the Color Management filter) are still applied to the image.

Sounds reasonable.

--xsdg

Gez
2014-03-11 18:45:41 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

El mar, 11-03-2014 a las 07:16 -0400, Elle Stone escribió:

I don't know anything about CMYK printing and I've never used the CM+ plugin, so please bear with me while I ask a couple of questions:

Putting *editing* CMYK channels to one side, is it useful to modifythe RGB channels while soft proofing to a CMYK profile (or even n-channel profile whether color or black and white)? I thought that was what the CM+ plugin made possible? Is this an example of what Gez calls "late binding"?

Not exactly, but related.
There are three possible workflows for print: Early binding: All the assets are converted to CMYK and editing is done in CMYK. The files you send to the print shop are CMYK. Late Binding: Everything is worked in RGB. The print shop converts to CMYK.
Intermediate Binding: Creative work is done in RGB, the files are converted to CMYK prior sending them to the print shop.

GIMP can't edit CMYK directly, but it can serve to the other two possible workflows.
soft proofing to a CMYK profile is useful because you can work in RGB with all the freedom it allows, but at the same time you can "preview" how the target gamut and rendering intent will affect your image. I think this is specially useful when using colorimetric intents, where all the out-of-gamut values get clamped.

CM+ allowed that. Iirc, it did more or less the same than the current color proof filter with some extra goodies (individual CMYK channels preview, black ink/paper white simulation, etc.)

Check this video from 1:40 https://www.youtube.com/watch?v=Q99MeymK7wA&feature=youtu.be&hd=1 (if you can endure the disturbing music, it shows the filter in action).

Having the title/status bar(s) show which display filters are active would be very useful, especially given that if you close the display filter window, any activated filters (or deactivated, in the case of the Color Management filter) are still applied to the image.

That would be an interesting addition, but I wonder if the current model of having multiple "working profiles" can't be replaced by something more useful.
This is probably off-topic, but having to worry about the file profile, a working profile, a print preview profile and a print profile in the preferences as global settings seems messy and inefficient. And in GIMP 2.9 it probably doesn't make so much sense as it used to. From a user point of view having all the imported stuff converted automatically to a high quality internal model (high bit depth linear scRGB?) and having per-image output/proof settings seems more straightforward and less error prone than the current mixture of profiles.
It may or may not be a problem for keeping legacy compatibility, but I can imagine how simplified the UI and common workflows would be (no bit-depth "modes", no assign/convert to profile, no profile-mismatch warnings, simplified CM preferences, etc).

Gez.

Liam R E Quin
2014-03-12 06:19:42 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On Tue, 2014-03-11 at 15:45 -0300, Gez wrote:

There are three possible workflows for print: Early binding: All the assets are converted to CMYK and editing is done in CMYK. The files you send to the print shop are CMYK. Late Binding: Everything is worked in RGB. The print shop converts to CMYK.
Intermediate Binding: Creative work is done in RGB, the files are converted to CMYK prior sending them to the print shop.

GIMP can't edit CMYK directly, but it can serve to the other two possible workflows.

Note that the case I mentioned the other day as seeming to be out of scope is when you *are* the print shop, and you (sometimes) receive the cmyk files, or need to edit them. E.g. remove an impression number from the imprint page and then send to imposition... but it seems it's in scope and just not there yet.

[...]

Having the title/status bar(s) show which display filters are active would be very useful, especially given that if you close the display filter window, any activated filters (or deactivated, in the case of the Color Management filter) are still applied to the image.

That would be an interesting addition, but I wonder if the current model of having multiple "working profiles" can't be replaced by something more useful.
This is probably off-topic, but having to worry about the file profile, a working profile, a print preview profile and a print profile in the preferences as global settings seems messy and inefficient. And in GIMP 2.9 it probably doesn't make so much sense as it used to.

The world is messy, I'm afraid.

From a user point of view having all the imported stuff converted automatically to a high quality internal model (high bit depth linear scRGB?) and having per-image output/proof settings seems more straightforward and less error prone than the current mixture of profiles.

Are you going to pay for the extra memory I'll need? I only have 32G and already with 2.9 I sometimes am swapping.

It may or may not be a problem for keeping legacy compatibility, but I can imagine how simplified the UI and common workflows would be (no bit-depth "modes", no assign/convert to profile, no profile-mismatch warnings, simplified CM preferences, etc).

You might not always be able to do round-tripping, because a colour in the input image's colour model might be out of gamut for the working profile. I don't know how big an issue that would be. Similarly you'd end up using colours that wouldn't come out at all right on your output device. The warnings are there for a reason...

Best,

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Elle Stone
2014-03-12 21:27:20 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On 03/11/2014 02:39 PM, Omari Stephens wrote:

That said, I think your question touches on something that I'm pretty ignorant about, which is how color profiles deal with different numbers and types of channels.

How monitors can use more than three channels (some already do) to make colors is easy to visualize:
http://ninedegreesbelow.com/photography/all-the-colors.html#some

Some cameras also use more than three colors (sensor lens cap colors) to capture colors.

Hopefully the printer people will correct me if I'm speaking nonsense here. CMYK printer profiles have four channels because ink produces color subtractively, but not perfectly, as inks are not as "narrow pass reflective" as one might like. So using C+M+Y to make black produces a muddy black and uses a lot of ink, which is sloppy to print. So the fourth color is black.

More than four colors of ink gives smoother color reproduction and also may extend the available color gamut, depending on the inks. The corresponding ICC profile is a Lookup Table profile, which basically says "r% ink-1 + s% ink-2 + t% ink-3 + u% ink-4 + . . . + z% ink-n" (where r, s, t, u, . . . z are arbitrary percentages) equals a particular location in the CIELAB reference color space, for all possible combinations of various percentages of the n available inks.

I know there is a thing called a GRAY profile, but I have no idea what makes it special or different than a standard profile. Is it basically an RGB profile with R==G==B?

Yes in effect, no as far as the actual grayscale profile goes. A grayscale profile only has a single channel that holds luminance information in the form of a curve that goes from 0 to max white. Any RGB matrix profile with an equivalent tone reproduction curve will "match" the grayscale profile as long as R=G=B for all pixels in the RGB image. Each channel in the RGB image will match the single channel in the grayscale image.

I've never seen a LUT grayscale profile. But for matrix grayscale profiles, the only information needed to define the profile is the white point, the black point (which is zero for all the matrix Grayscale profiles I've ever seen), and the tone reproduction curve (aka tone response curve). RGB matrix profiles also need red, green, and blue colorant tags.

From a practical point of view, less disk storage is required for a grayscale image, compared to an RGB image with R=G=B for all three channels.

Does GIMP uses less RAM and/or CPU power to process a grayscale image, compared to an RGB image where R=G=B?

In the New GEGL World, converting between different channel layouts is going to be a reality, and we should at least put _some_ thought into what that means for color management. Of course, this is way out of my depth, and I have no idea.

I'm also curious as to what gegl n-channel editing might be like. Soft proofing to an n-channel printer is a one use case for n-channel editing, when the goal is to convert to the n-channel ICC profile and tweak the channels while soft proofing. Hopefully again the printer people will correct me if I'm speaking nonsense.

Dan Margulis gives examples of image editing in an artificial CMYK matrix color space, requiring four channels.

Would there be a use case for editing in n-space (as opposed to soft proofing to an n-space output profile), where n is greater than 4?

LCMS2 already accomodates n-channel ICC profile conversions. The GIMP lcms.c plugin doesn't, but support could be added.

Elle

Alexandre Prokoudine
2014-03-12 22:00:23 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On Thu, Mar 13, 2014 at 1:27 AM, Elle Stone wrote:

Would there be a use case for editing in n-space (as opposed to soft proofing to an n-space output profile), where n is greater than 4?

You mean, like CMYK + PANTONE 877C?

Alexandre

Gez
2014-03-13 02:42:19 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

El mié, 12-03-2014 a las 17:27 -0400, Elle Stone escribió:

On 03/11/2014 02:39 PM, Omari Stephens wrote:

Hopefully the printer people will correct me if I'm speaking nonsense here. CMYK printer profiles have four channels because ink produces color subtractively, but not perfectly, as inks are not as "narrow pass reflective" as one might like. So using C+M+Y to make black produces a muddy black and uses a lot of ink, which is sloppy to print. So the fourth color is black.

That's spot on. Another reason is that black ink (carbon based) is cheaper than color inks (and 1 ink pass is cheaper than three pases, and it dries faster).
However, because blank ink isn't perfect either, a pure black pass doesn't look "deep" enough in large areas and will look rather like dark gray than like black, so it's common to add a little C, M and Y to get a "rich" black.

More than four colors of ink gives smoother color reproduction and also may extend the available color gamut, depending on the inks. The corresponding ICC profile is a Lookup Table profile, which basically says "r% ink-1 + s% ink-2 + t% ink-3 + u% ink-4 + . . . + z% ink-n" (where r, s, t, u, . . . z are arbitrary percentages) equals a particular location in the CIELAB reference color space, for all possible combinations of various percentages of the n available inks.

The color profile also contains additional information like black generation, and TAC (Total Area Coverage percentage, a maximum ink coverage recommended for the media used). If you go beyond that value the media will take longer to dry, dot gain could saturate and mud details, etc.

In the New GEGL World, converting between different channel layouts is going to be a reality, and we should at least put _some_ thought into what that means for color management. Of course, this is way out of my depth, and I have no idea.

I'm also curious as to what gegl n-channel editing might be like. Soft proofing to an n-channel printer is a one use case for n-channel editing, when the goal is to convert to the n-channel ICC profile and tweak the channels while soft proofing. Hopefully again the printer people will correct me if I'm speaking nonsense.

Dan Margulis gives examples of image editing in an artificial CMYK matrix color space, requiring four channels.

Margulis is a respected name, but I'd take what he says with a grain of salt. The last time I checked he still insisted that doing creative editing in device CMYK is a great idea and that "color management failed", something that contradicts the direction of the entire graphic industry for the last 15 years.

Would there be a use case for editing in n-space (as opposed to soft proofing to an n-space output profile), where n is greater than 4?

If you have to treat one of the CMYK primaries as a spot color, or if you need an extra spot color, then yes. It's indeed useful and a quite common requirement in the print industry. For instance, if you have a color that can't be achieved mixing CMYK inks (saturated greens, oranges, blues, etc.), an extra print pass is used, inking with a specially formulated ink that reproduces the exact color you need.
That's what a "spot color" means. When you want to get red mixing 100% yellow and 100% magenta (and you want that exact combination) you're using both yellow and magenta as they were spot channels. It has nothing to do with CMYK, because you're overriding color management and using an arbitrary mix, not a colorimetric translation. Perhaps this is not a popular point of view, but in my opinion, using CMYK just because you want to tweak channels manually (as if it was possible to predict the printed output of that procedure) is a bad idea. If you want to work on a computer screen and send the output to print, the most reliable way to get the color appearance properly translated is a solid color managed workflow.

Spot plates only have to be color corrected for previewing purposes, but they won't be separated in individual channels. They are extra channels, completely separated from the CMYK process colors. The only interaction with the CMYK channels is defining overprinting/knockout.

Gez

Liam R E Quin
2014-03-13 03:35:27 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

[ resending this to the list, at Gez's request :) ]

On Wed, 2014-03-12 at 17:43 -0300, Gez wrote:

El mi, 12-03-2014 a las 02:19 -0400, Liam R E Quin escribi:

On Tue, 2014-03-11 at 15:45 -0300, Gez wrote:

Note that the case I mentioned the other day as seeming to be out of scope is when you *are* the print shop, and you (sometimes) receive the cmyk files, or need to edit them. E.g. remove an impression number from the imprint page and then send to imposition... but it seems it's in scope and just not there yet.

You're right, there's no free software tool fully capable for that purpose.

[...]

I'm curious to know how many print shops would consider using GIMP if it had native CMYK. I suspect that the majority of people ranting about the lack of CMYK are mostly designers who know just one way to send stuff to print shops, not print shops.

The print shops I know generally use either mac-based tools or proprietary RIP systems, or (usually) both.

But the future is longer than the now.

[...]

Ok, good point. I missed the segment of users who work with huge scans completely.
On the other hand, is 8-bit enough for the type of work you do?

I scan at 8bpp 2400dpi, or at 16bpp 1800 or 2100dpi right now; when I scan an A3 page at 16bpp and 2400dpi, as I did for http://www.fromoldbooks.org/DehioBezold-Kirchliche/pages/001-600dpi/ as an experiment, Gimp quickly reached over 15G of memory, and I needed to use "discard undo history" after every operation, so I quickly scaled the image down. For the rest of that book I'll be scanning the individual figures.

Like you, I do prefer the higher bit depths, so it's a compromise.

[...]

Anyway, rather than bitdepth, my comment was about giving the artists a framework to create freely without worrying (much) about the constraints of input/output colorspaces.
It's impossible to have that with 8 bpc. And correct me if I'm wrong, but I suspect that using proofing filters on non-linear 8bpc carries a lot of problems and the result can't be completely reliable.

No, I think it's probably fine. Most commercial RIPs these days deal with at least 10 and more likely 16bpp.

Maybe we can have the flexibility and power just keeping two modes: 16 bit integer for memory-conservative tasks and 32 bit float for high quality stuff.

That would rule out editing GIF animations and also make preparing images for the Web or for use n mobile devices very hard.

[...] lots of good stuff deleted, because...

Anyway, this is just an idea. It's not a small change and I'm not suggesting that it has to be done the way I said. I think this is an interesting topic to discuss since seems more suitable for non-destructive editing than the current approach.

Yes.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Gez
2014-03-13 04:05:02 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

El mié, 12-03-2014 a las 02:19 -0400, Liam R E Quin escribió:

On Tue, 2014-03-11 at 15:45 -0300, Gez wrote:

Note that the case I mentioned the other day as seeming to be out of scope is when you *are* the print shop, and you (sometimes) receive the cmyk files, or need to edit them. E.g. remove an impression number from the imprint page and then send to imposition... but it seems it's in scope and just not there yet.

You're right, there's no free software tool fully capable for that purpose.

The Separate+ plugin offers a rudimentary solution for that. The resulting layered composite is far from ideal ("ugly" would be a better description) but it kind of works. Krita, although has native CMYK "mode", it doesn't offer the tools (at least not yet) for that kind of job.

Early binding is still here. I can live without it, but of course that it wouldn't be the case if I was a print-shop. I'm curious to know how many print shops would consider using GIMP if it had native CMYK. I suspect that the majority of people ranting about the lack of CMYK are mostly designers who know just one way to send stuff to print shops, not print shops.

From a user point of view having all the imported stuff converted automatically to a high quality internal model (high bit depth linear scRGB?) and having per-image output/proof settings seems more straightforward and less error prone than the current mixture of profiles.

Are you going to pay for the extra memory I'll need? I only have 32G and already with 2.9 I sometimes am swapping.

No, but I can make you some coffee while you wait :-p

Ok, good point. I missed the segment of users who work with huge scans completely.
On the other hand, is 8-bit enough for the type of work you do? Although I'm still using 8 bpc for my work because I do it with GIMP 2.8, I have a really hard time trying to keep good quality after a few rounds of edits.
Maybe defaulting to 32bpc is too resource-intensive for a lot of works, but wouldn't make more sense to have a higher quality default for editing and keeping 8 bpc just as an output bit depth?
Anyway, rather than bitdepth, my comment was about giving the artists a framework to create freely without worrying (much) about the constraints of input/output colorspaces.
It's impossible to have that with 8 bpc. And correct me if I'm wrong, but I suspect that using proofing filters on non-linear 8bpc carries a lot of problems and the result can't be completely reliable.

Maybe we can have the flexibility and power just keeping two modes: 16 bit integer for memory-conservative tasks and 32 bit float for high quality stuff.
Economy of system resources is important, but I'm sure that image quality is far more important in a image manipulation program.

It may or may not be a problem for keeping legacy compatibility, but I can imagine how simplified the UI and common workflows would be (no bit-depth "modes", no assign/convert to profile, no profile-mismatch warnings, simplified CM preferences, etc).

You might not always be able to do round-tripping, because a colour in the input image's colour model might be out of gamut for the working profile. I don't know how big an issue that would be. Similarly you'd end up using colours that wouldn't come out at all right on your output device. The warnings are there for a reason...

scRGB exceeds the gamut of the usual profiles, following what I proposed in the previous message, if you go -for instance- AdobeRGB -> scRGB -> AdobeRGB with enough precision that shouldn't be a problem and RGB CMYK roundrip is impossible anyway.
I'm not an expert by any means and I might be wrong, but that doesn't seem to contradict what I said.
And regarding "you'd end up using colours that wouldn't come out at all right on your output device", that's exactly what soft-proofing (the topic of this thread) would prevent. If you have in the workflow I presented, say an AdobeRGB image as input, it would be converted to scRGB. All its colours would fall inside the scRGB gamut, so no problem. If you save back to AdobeRGB without changing anything, color shouldn't change. If you save to sRGB, colors would have to be converted using a rendering intent, because the output gamut is smaller. You could soft-proof your editing against sRGB to see how colors would be affected with the selected rendering intent.
The good thing about this is that your XCF file would store unmodified color information, and that would allow to save later to AdobeRGB, Prophoto or whatever you want.
Now, if you were obligated to convert your imported image to a working profile (like you are now), and that profile has a smaller gamut than the original image, your imported image is hopelessly degraded. You're always tied to the color gamut of your working RGB profile.

Anyway, this is just an idea. It's not a small change and I'm not suggesting that it has to be done the way I said. I think this is an interesting topic to discuss since seems more suitable for non-destructive editing than the current approach.

Gez.

Gez
2014-03-13 04:19:34 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

El mié, 12-03-2014 a las 23:35 -0400, Liam R E Quin escribió:

[ resending this to the list, at Gez's request :) ]

Sorry for the accidental private mail :)

Anyway, rather than bitdepth, my comment was about giving the artists a framework to create freely without worrying (much) about the constraints of input/output colorspaces.
It's impossible to have that with 8 bpc. And correct me if I'm wrong, but I suspect that using proofing filters on non-linear 8bpc carries a lot of problems and the result can't be completely reliable.

No, I think it's probably fine. Most commercial RIPs these days deal with at least 10 and more likely 16bpp.

Notice that I'm talking about processing only. The output bitdepth should be the usual for each file format (for instance, although commercial RIPs no longer choke with 16bpc files, it's still recommended to send 8 bit and probably sending more won't make any difference, at least for offset).

Maybe we can have the flexibility and power just keeping two modes: 16 bit integer for memory-conservative tasks and 32 bit float for high quality stuff.

That would rule out editing GIF animations and also make preparing images for the Web or for use n mobile devices very hard.

Why?
Again, processing in high bit depth, soft-proofing against the target colorspace, saving to the destination bitdepth and profile. The "project" file keeps data and color latitude, the exported files are converted to the desired parameters. You can do exactly that with Blender's compositor, and it can save JPGs or PNG for the web.
If an 8-bpc buffer can be displayed, the it's probably possible to generate an indexed projection on the fly, pretty much like gimp-2.9 does now.

Gez.

Liam R E Quin
2014-03-13 06:36:09 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On Thu, 2014-03-13 at 01:19 -0300, Gez wrote:

El mi, 12-03-2014 a las 23:35 -0400, Liam R E Quin escribi:

Maybe we can have the flexibility and power just keeping two modes: 16 bit integer for memory-conservative tasks and 32 bit float for high quality stuff.

That would rule out editing GIF animations and also make preparing images for the Web or for use n mobile devices very hard.

Why?
Again, processing in high bit depth, soft-proofing against the target colorspace, saving to the destination bitdepth and profile.

Because for 256-colour GIF animations you are forced to care about individual pixel values, and use indexed-mode colour with a fixed palette. (strictly speaking GIF can handle higher bit depths too, but for widest distribution you have to keep it simple).

GIMP has the GIMP Animation package to help people make animated GIFs so it has quite a following.

For JPEG and PNG, maybe it's OK in most cases, but "soft proofing" isn't the same as "you edit what you will use". .

If an 8-bpc buffer can be displayed, the it's probably possible to generate an indexed projection on the fly, pretty much like gimp-2.9 does now.

Yes, although 8-bit GIF is not 8 bit per channel but 8 bit for all three channels, so you really care about which colours are allocated. Like, a lot. Anyway, we'll see how it turns out. GIF animations of kittens might not actually be in GIMP's primary use case market...

GIF89a doesn't seem to support embedded ICC profiles, by the way ;)

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Omari Stephens
2014-03-13 06:43:37 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On 03/13/2014 04:05 AM, Gez wrote:

El mié, 12-03-2014 a las 02:19 -0400, Liam R E Quin escribió:

On Tue, 2014-03-11 at 15:45 -0300, Gez wrote:

::snip? SNIP!::

From a user point of view having all the imported stuff converted automatically to a high quality internal model (high bit depth linear scRGB?) and having per-image output/proof settings seems more straightforward and less error prone than the current mixture of profiles.

Are you going to pay for the extra memory I'll need? I only have 32G and already with 2.9 I sometimes am swapping.

No, but I can make you some coffee while you wait :-p

Ok, good point. I missed the segment of users who work with huge scans completely.
On the other hand, is 8-bit enough for the type of work you do? Although I'm still using 8 bpc for my work because I do it with GIMP 2.8, I have a really hard time trying to keep good quality after a few rounds of edits.
Maybe defaulting to 32bpc is too resource-intensive for a lot of works, but wouldn't make more sense to have a higher quality default for editing and keeping 8 bpc just as an output bit depth?

Anyway, rather than bitdepth, my comment was about giving the artists a framework to create freely without worrying (much) about the constraints of input/output colorspaces.
It's impossible to have that with 8 bpc. And correct me if I'm wrong, but I suspect that using proofing filters on non-linear 8bpc carries a lot of problems and the result can't be completely reliable.

Maybe we can have the flexibility and power just keeping two modes: 16 bit integer for memory-conservative tasks and 32 bit float for high quality stuff.
Economy of system resources is important, but I'm sure that image quality is far more important in a image manipulation program.

It depends, right? I'm a photographer. Let's suppose I've got a D800 and a digital medium format body. The D800 is 36MP and captures 10 or 12bpc; the MF is 50MP and captures 14bpc.

On day one, I shoot a breaking-news assignment for a print newspaper or a wire service. In that case, my priority is speed first, quality second, because newsprint only barely qualifies as paper, and wire photos tend to be low-resolution anyway.

While I'm churning through images on my laptop, converting _to_ a high-bit-depth representation and then _from_ that representation back to 8-bit sRGB is both a waste of time and a waste of battery power. That's time I could have spent researching captions, or talking to people, or just getting back out and back to shooting.

A week later, I shoot a piece for a magazine with a 50MP digital medium-format camera. The assignment is set to run a month later, and I'm working on it on my home machine with a ton of memory. In that case, quality is of the essence, and if it takes a few minutes to (say) run sharpening, that's annoying, but it's not all that big of an issue.

By virtue of shooting MF, I care about my gradients more than pretty much anything else, and so I immediately convert from the 14bpc input (encoded as 16bpc files) to 32bpc to avoid introducing any aliasing during post-processing.

The point of this example is that while it makes sense to choose sensible defaults, and to make efforts to keep the user from shooting herself in the foot, I don't think it makes sense to prevent the user from taking direct control of those settings if she so chooses.

It may or may not be a problem for keeping legacy compatibility, but I can imagine how simplified the UI and common workflows would be (no bit-depth "modes", no assign/convert to profile, no profile-mismatch warnings, simplified CM preferences, etc).

You might not always be able to do round-tripping, because a colour in the input image's colour model might be out of gamut for the working profile. I don't know how big an issue that would be. Similarly you'd end up using colours that wouldn't come out at all right on your output device. The warnings are there for a reason...

scRGB exceeds the gamut of the usual profiles, following what I proposed in the previous message, if you go -for instance- AdobeRGB -> scRGB -> AdobeRGB with enough precision that shouldn't be a problem and RGB CMYK roundrip is impossible anyway.

As I tried to demonstrate, requiring the user to convert to different color profiles may be problematic. But using a wide gamut color space at low bit depth is also problematic. In the example, photojournalist-me simply wants to work in 8-bit sRGB. All of the stuff that actually required high bit depth (bringing up really low shadows and whatnot) is stuff I'd have already done in the RAW converter, before that image data even got to GIMP.

I'm not an expert by any means and I might be wrong, but that doesn't seem to contradict what I said.
And regarding "you'd end up using colours that wouldn't come out at all right on your output device", that's exactly what soft-proofing (the topic of this thread) would prevent. If you have in the workflow I presented, say an AdobeRGB image as input, it would be converted to scRGB. All its colours would fall inside the scRGB gamut, so no problem. If you save back to AdobeRGB without changing anything, color shouldn't change. If you save to sRGB, colors would have to be converted using a rendering intent, because the output gamut is smaller. You could soft-proof your editing against sRGB to see how colors would be affected with the selected rendering intent.
The good thing about this is that your XCF file would store unmodified color information, and that would allow to save later to AdobeRGB, Prophoto or whatever you want.
Now, if you were obligated to convert your imported image to a working profile (like you are now), and that profile has a smaller gamut than the original image, your imported image is hopelessly degraded. You're always tied to the color gamut of your working RGB profile.

You are not currently obliged to convert imported images to a working profile. "File Open Behaviour" has three settings, and one is "Keep embedded profile."

--xsdg

Anyway, this is just an idea. It's not a small change and I'm not suggesting that it has to be done the way I said. I think this is an interesting topic to discuss since seems more suitable for non-destructive editing than the current approach.

Gez.

_______________________________________________ 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

Gez
2014-03-13 15:53:13 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

El jue, 13-03-2014 a las 06:43 +0000, Omari Stephens escribió:

On day one, I shoot a breaking-news assignment for a print newspaper or a wire service. In that case, my priority is speed first, quality second, because newsprint only barely qualifies as paper, and wire photos tend to be low-resolution anyway.

I won't say you're wrong because this is matter of preferences, but I don't think it's a good idea to sacrifice quality because the output is limited.
That should be in the realm of export, not of processing. I think it's always better to keep quality as high as possible in your project files and degrade it (to lower bitdepth, smaller gamut, etc.) only when exporting the deliverable file.
Why? Because you never know if you'll need the image for a different output.
What if adjust a photo for the resolution and quality of newsprint, and that photo wins a prize or something and they ask you a better quality picture for a magazine or a large format print? For the same reason you don't (or your shouldn't) work with small jpgs over-compressed, only because "it's just for the web".

The early binding print workflow presents the same problem: If you convert your image to a small gamut colorspace you're restricting the use of that image to that specifica output. Not the best idea in a world where images are likely to be published in different media.

While I'm churning through images on my laptop, converting _to_ a high-bit-depth representation and then _from_ that representation back to 8-bit sRGB is both a waste of time and a waste of battery power. That's time I could have spent researching captions, or talking to people, or just getting back out and back to shooting.

Well,I think it depends on the penalty of such operation. It's a technical issue and since I'm not a developer I can't predict how much impact something like that will have. I know it's not impossible. Several high end image compositing and raw development packages use that approach.

The point of this example is that while it makes sense to choose sensible defaults, and to make efforts to keep the user from shooting herself in the foot, I don't think it makes sense to prevent the user from taking direct control of those settings if she so chooses.

What I'm proposing doesn't necessarily take control from users. If it can be done with a reasonable performance and use of system resources users wouldn't see much difference, only a simplified and less workflow.

scRGB exceeds the gamut of the usual profiles, following what I proposed in the previous message, if you go -for instance- AdobeRGB -> scRGB -> AdobeRGB with enough precision that shouldn't be a problem and RGB CMYK roundrip is impossible anyway.

As I tried to demonstrate, requiring the user to convert to different color profiles may be problematic. But using a wide gamut color space at low bit depth is also problematic. In the example, photojournalist-me simply wants to work in 8-bit sRGB. All of the stuff that actually required high bit depth (bringing up really low shadows and whatnot) is stuff I'd have already done in the RAW converter, before that image data even got to GIMP.

Sure, that's why I suggested high bit depth. Maybe always 32bpc float is too much, but what about 16 bit integer for that kind of works?

Wouldn't it be a reasonable compromise for the lower-end of processing? It would eat extra resources, but it would mitigate most of the huge downsides of 8bpc.

If you already used a RAW converter (that is likely to work non-destructively in high bit depth), why not saving your image in 16-bit for the final touches in the image manipulation program? You would be able to export the final result to 8-bit sRGB.

What I'm trying to discuss here is the real need of keeping such a destructive low end and a inefficient legacy color management workflow.

What's the impact of moving from 8bpc integer to 16bpc integer in terms of memory consumption and performance? Is it a reasonable compromise considering the important gain in quality and precision?

(these are honest questions. I'd love to know what developers think about it).

I just opened a 12 megapixels image in GIMP 2.9, I did some operations on it both in 8 bpc integer and 16 bpc integer. The difference in performance was almost unnoticeable, and for a single layer the difference in memory consumption was around 300 megabytes. Of course, adding layers adds up, but if the argument was to perform some quick edits on an underpowered laptop and quality doesn't matter much, a complex multilayer composite is out of the question.

You are not currently obliged to convert imported images to a working profile. "File Open Behaviour" has three settings, and one is "Keep embedded profile."

You're right. But have you considered the consequences of editing an image in a large-gamut colorspace in 8-bit integer? AdobeRGB isn't enormous, and posterization will show up earlier than in sRGB.
Of course you won't notice it if you're doing minor tweaks, but do you think it's worth to keep 8-bit and editing in the source colorspace just because it would take some extra CPU cycles to take it to a larger gamut working space?

Thanks for your feedback. I'm not trying to prove who's wrong or right here, just trying to discuss the validity of assumptions we make (mine included, of course).

Gez.

Gez
2014-03-13 16:24:06 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

El jue, 13-03-2014 a las 12:53 -0300, Gez escribió:

The difference in performance was almost unnoticeable, and for a single layer the difference in memory consumption was around 300 megabytes.

Hmm. That's not correct. The difference seems to be much less if you discard the undo information.

Gez.

Gez
2014-03-13 19:45:03 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

El jue, 13-03-2014 a las 02:36 -0400, Liam R E Quin escribió:

Why?
Again, processing in high bit depth, soft-proofing against the target colorspace, saving to the destination bitdepth and profile.

Because for 256-colour GIF animations you are forced to care about individual pixel values, and use indexed-mode colour with a fixed palette. (strictly speaking GIF can handle higher bit depths too, but for widest distribution you have to keep it simple).

GIMP has the GIMP Animation package to help people make animated GIFs so it has quite a following.

If an 8-bpc buffer can be displayed, the it's probably possible to generate an indexed projection on the fly, pretty much like gimp-2.9 does now.

Yes, although 8-bit GIF is not 8 bit per channel but 8 bit for all three channels, so you really care about which colours are allocated. Like, a lot. Anyway, we'll see how it turns out. GIF animations of kittens might not actually be in GIMP's primary use case market...

Ok, so the problem is indexed images. How does it work now in 2.9?
Is it really 8 bpp or is it 8bpc and the projection is converted to indexed?

I found these articles (maybe outdated) that seem to imply the latter:

https://lwn.net/Articles/497132/

"Because GEGL operations are defined on abstract buffers, adding support for an entirely different image format is a matter of writing a new format for babl, the underlying pixel transformation layer. During the GEGL hack-a-thon, Kolås wrote such a back-end for indexed color images (such as you find in the GIF format). Natterer had originally planned to drop support for indexed images, but with the babl format defined, they work just as well as any other format in the GEGL-ified GIMP. GEGL also allows GIMP to use all sorts of painting and filter operations on indexed images (such as smudging and blurring) that are typically not possible on indexed color."

http://blog.mmiworks.net/2009/06/gimp-squaring-cmyk-circle.html

"The core of the solution model is that this projection is again a surface, that can be worked on, to make the corrections that are specific to this indexed set‑up. The non‑destructive nature of GEGL makes it possible to reapply these corrections after more creative development, or to adjust them at a later stage."

What I'm saying isn't very different than developers already said: https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html

I'm just presenting a case for a simplified workflow that could cover the same possibilities without a lot of modes and options that could lead to unintended screwups.

GIF89a doesn't seem to support embedded ICC profiles, by the way ;)

Untagged images for the web are always assumed as sRGB, and I'd say that if you use any other profile you should tag them so CM takes care of the proper color transforms.
Untagged images in an unknown colorspace are one of the nasty consequences of an inefficient color workflow that made the hideous command "assign profile" necessary in the first place.

Liam R E Quin
2014-03-13 19:54:57 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On Thu, 2014-03-13 at 16:45 -0300, Gez wrote:

El jue, 13-03-2014 a las 02:36 -0400, Liam R E Quin escribi:

GIF89a doesn't seem to support embedded ICC profiles, by the way ;)

Untagged images for the web are always assumed as sRGB,

You can't tag a GIF image in any case; in Chromium (say) today GIF images are not colour managed, but loaded directly.

Colour management on the Web is still in its early stages, though.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Øyvind Kolås
2014-03-14 02:37:19 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On Wed, Mar 12, 2014 at 10:27 PM, Elle Stone wrote:

In the New GEGL World, converting between different channel layouts is going to be a reality, and we should at least put _some_ thought into what that means for color management. Of course, this is way out of my depth, and I have no idea.

I'm also curious as to what gegl n-channel editing might be like. Soft proofing to an n-channel printer is a one use case for n-channel editing, when the goal is to convert to the n-channel ICC profile and tweak the channels while soft proofing. Hopefully again the printer people will correct me if I'm speaking nonsense.

In the end; you'd have the buffers for individual ink plates in GIMP (more likely than having it as an n-component buffer as you would if there was a CMYK mode along with RGB); and need to preview/softproof it. In some cases lcms might provide what is needed; in others like silk screen printing a couple of metallic inks on colored fabric - maybe not.

Today I wrote a proof of concept spectral soft proofing op for GEGL. https://git.gnome.org/browse/gegl/tree/operations/workshop/ink-simulator.c

The settings are edited in a little multi-line editor, with a default configuration like this:
-----
illuminant = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 substrate = white
ink1 = cyan
ink2 = yellow
ink3 = magenta
ink4 = black opaque
-----

It currently uses an "RGBA float" as input; this could be changed to multiple buffers or an n-channel babl format. The 4 inks in order, though the order only matters if inks are suffixed with opaque. One can either pass in a 20 space separated numbers between 0.0 and 1.0 (or higher), or one of few hardcoded colors.

The op is in the operations/workshop/ directory of GEGL; so you have to type make && sudo make install; in the workshop dir to install it. For quickly preparing a file to use with the default settings; decompose a color imake to CMYK and recompose it to RGBA; then invoke the ink-simulator from the GEGL tool.

The model is far from complete. It lacks spectral curves for commonly used illuminants, sane spectral responses for the inks, it doesn't take any form of dot gain into account - and has a naive idea about types of ink.
With the addition of a couple of animated frames and more tweaks; one could add the ability to preview glossy or metallic inks as well.

/pippin

Elle Stone
2014-03-14 13:21:47 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On 03/13/2014 10:37 PM, Øyvind Kolås wrote:

On Wed, Mar 12, 2014 at 10:27 PM, Elle Stone wrote:

In the New GEGL World, converting between different channel layouts is going to be a reality, and we should at least put _some_ thought into what that means for color management. Of course, this is way out of my depth, and I have no idea.

I'm also curious as to what gegl n-channel editing might be like. Soft proofing to an n-channel printer is a one use case for n-channel editing, when the goal is to convert to the n-channel ICC profile and tweak the channels while soft proofing. Hopefully again the printer people will correct me if I'm speaking nonsense.

In the end; you'd have the buffers for individual ink plates in GIMP (more likely than having it as an n-component buffer as you would if there was a CMYK mode along with RGB); and need to preview/softproof it. In some cases lcms might provide what is needed; in others like silk screen printing a couple of metallic inks on colored fabric - maybe not.

Today I wrote a proof of concept spectral soft proofing op for GEGL. https://git.gnome.org/browse/gegl/tree/operations/workshop/ink-simulator.c

The settings are edited in a little multi-line editor, with a default configuration like this:
-----
illuminant = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 substrate = white
ink1 = cyan
ink2 = yellow
ink3 = magenta
ink4 = black opaque
-----

It currently uses an "RGBA float" as input; this could be changed to multiple buffers or an n-channel babl format. The 4 inks in order, though the order only matters if inks are suffixed with opaque. One can either pass in a 20 space separated numbers between 0.0 and 1.0 (or higher), or one of few hardcoded colors.

The op is in the operations/workshop/ directory of GEGL; so you have to type make && sudo make install; in the workshop dir to install it. For quickly preparing a file to use with the default settings; decompose a color imake to CMYK and recompose it to RGBA; then invoke the ink-simulator from the GEGL tool.

The model is far from complete. It lacks spectral curves for commonly used illuminants, sane spectral responses for the inks, it doesn't take any form of dot gain into account - and has a naive idea about types of ink.
With the addition of a couple of animated frames and more tweaks; one could add the ability to preview glossy or metallic inks as well.

/pippin

I looked at the code. Some questions come to mind:

1. LCMS2 has CMYK soft proofing and also ink-limiting already covered. Here's the ink-limiting algorithm, quoted from the LCMS API (looks similar to the GEGL code):

Ink-limiting algorithm: Sum = C + M + Y + K
If Sum > InkLimit
Ratio= 1 - (Sum - InkLimit) / (C + M + Y) if Ratio t be provided in the lcms.c plugin and elsewhere as needed, such that LCMS can do the conversion part - between LAB and *any* RGB color space, not just between LAB and *s*RGB - and let GEGL can handle the pixel math? And can a hook be provided for converting to CMYK? At least for soft proofing to the screen and for final conversion for exporting to disk?

Elle

Øyvind Kolås
2014-03-14 14:34:52 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On Fri, Mar 14, 2014 at 2:21 PM, Elle Stone wrote:

I looked at the code. Some questions come to mind:

1. LCMS2 has CMYK soft proofing and also ink-limiting already covered. Here's the ink-limiting algorithm, quoted from the LCMS API (looks similar to the GEGL code):

Ink-limiting algorithm: Sum = C + M + Y + K
If Sum > InkLimit
Ratio= 1 - (Sum - InkLimit) / (C + M + Y) if Ratio
Ratio=0
endif
Else
Ratio=1
endif
C = Ratio * C
M = Ratio * M
Y = Ratio * Y
K: Does not change

LMCS already supports up to 16 channels in an ICC profile. Granted, the LCMS ink-limiting algorithm seems at present limited to only four inks. But a patch to LCMS for more than four inks is surely possible.

The code *experiment* linked to has nothing to do with ink limiting; what I linked to is rather naive additive and subtractive color mixing in a 20 band spectral color space, a little bit like how physics works. But yes; as I noted it doesn't take into account subsurface scattering and other things that ICC profiles try to encompass indirectly.

2. Many people with printers go to great lengths to use Argyllcms or some commercial equivalent to make accurate printer profiles. LCMS already does accurate conversions from the source RGB color profile to the printer profile. So I guess I don't see the point of the gegl code.

The gegl code, no matter how refined and complicated it might become, can't compensate for the fact that real printers+inks+papers can and do have all kinds of unpredictable channel cross-overs and varying deltas in resulting color between any given color patch (combination of inks laid down on the paper) to the next closest color patches. Can gegl handle this kind of variation in colors from one color patch to the next? Real printer profiles have tremendous variation in resulting device white and black points - can the gegl code handle the wide variety of real printer white and black points? You mention different illuminants and spectral ink responses. In light of the tremendous variation in how actual inks on actual paper reflect actual wavelengths of light, what does "sane spectral responses for inks" even mean? An industry average? Or will GEGL developers build and maintain a database of spectral responses for various paper/ink/illuminant combinations and allow the user to choose a combination, instead of just letting them use their actual printer profiles along with LCMS for soft proofing?

The ink-simulator code as it stands is a naive; and when one has an ICC profile that can be softproofed through LCMS; there should be no reason for not using such a code path. The LCMS code path should however most likely live in a different GEGL op; and GIMP or something else would swap things around as needed (or have no such op there at all.)

There is a reason I listed the code as being limited. If you look at the code and read it; you would understand what I meant by the spectral responses used not being "sane", or "sound", they are all 0.0 and 1.0; in comparison to the cone response curves used; which are based on real data. One wouldn't need spectral responses for inks/pigments under different illuminants, something close to illuminant E would suffice. And illuminants are standardised.

The reason for that softproofing experiment is hunting for ways to deal with CMYK as a subset of the ink-plate printing/spot-color problem. Is it is easy to create and dynamically update/replace ICC profiles programattically using LCMS/agryll for a combination of inks coming from a couple of pantone colors (and yes, I'll include metallics and reflective transparent again); on a custom fabric choice. Like perhaps simulating the printing of silver, black and reflective transparent on top of black fabric.

3. LCMS can convert between XYZ, LAB, LUV, YCbCr, xyY, HSV, HSL, CMYK, CMY, RGB, and GRAY, plus handle spot colors (and a whole lot of other stuff, including providing gamut displays, useful for soft proofing, and also color temperature conversions). Why is there so much babl/gegl/gimp code for doing things like converting from RGB to "naive CMY", LAB, HSV, etc? Why not leverage LCMS to accomplish these goals?

Because LCMS traditionally has been unpredictably slow (due to different type of ICC profiles and code paths the code needs to take); thus from GEGLs point of view LCMS is suitable for import (into one of the babl managed spaces). And export to a custom ICC profile.

babl/gegl is hard-coded to convert between only *s*RGB and LAB/CMY/HSV, etc. LCMS can convert between *any* RGB color space and these other color spaces. GIMP is already at the top of the heap of available image editors in so very many ways, but not with respect to color management. Leveraging LCMS to do all color space conversions would bring GIMP to the top of the heap of all available image editors even for color management.

LCMS is intended for all external/ICC-requiring conversions; for internal conversions we bring our own faster ones through babl.

4. Regarding 3, I would already have done my very best to write the color-conversion code for all the various color spaces handled by LCMS, except that I was told that GEGL is going to take over handling color management, a proposition that continues to baffle me.

GEGL is taking over all pixel processing in GIMP; color mangement is part of that. In particular the display filters should all be turned into GEGL operations.

See https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html for an older writeup I did on the topic of GEGL and color.

One of the things that seemed to me to be really cool about GEGL is the fact that it seemed color space agnostic - it just does pixel math. Or so I thought. Perhaps I'm wrong. If I'm right, then personally I really, really, really (that's not enough "reallys" but you get the point) want GIMP to support real CIELAB editing. LAB has three channels. RGB has three channels. LCSM can convert between RGB and LAB. Is there any reason why a hook can't be provided in the lcms.c plugin and elsewhere as needed, such that LCMS can do the conversion part - between LAB and *any* RGB color space, not just between LAB and *s*RGB - and let GEGL can handle the pixel math? And can a hook be provided for converting to CMYK? At least for soft proofing to the screen and for final conversion for exporting to disk?

GEGL is intended to be _strongly_ color managed. Far from color space agnostic. Each operation specifies it's working space; and you are not permitted to override that. For instance a 5% brightness adjustment should do the same absolute colorimetric changes to your image data regardless of the source/import ICC profile. This means that compositing in with a linear working space, and compositing with a perceptual gamma working space should be two _different_ GEGL ops; at least it doesn't depend on the GeglBuffer. Similar for linear-invert and perceptual-invert.

If you pass a CIE-Lab buffer to GEGLs gaussian-blur; the gaussian blur will turn the data into alpha premultiplied single precision floating point with linear light gamma. which is the working space of the gaussian blur operation, if you really wanted to blur in CIE-Lab space; you would have to put a fake "RGB" bablformat on the buffer, do the blur and the put back the CIE-Lab format.

I've spent more time writing emails about this code; than writing - and playing with it. It would've been nice if you had had time to come to LGM.

/pippin

Elle Stone
2014-03-16 21:22:52 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On 03/14/2014 10:34 AM, Øyvind Kolås wrote:

On Fri, Mar 14, 2014 at 2:21 PM, Elle Stone wrote:

But a
patch to LCMS for more than four inks is surely possible.

The code *experiment* linked to has nothing to do with ink limiting; what I linked to is rather naive additive and subtractive color mixing in a 20 band spectral color space, a little bit like how physics works. But yes; as I noted it doesn't take into account subsurface scattering and other things that ICC profiles try to encompass indirectly.

My apologies. Clearly I didn't read the code carefully enough.

The reason for that softproofing experiment is hunting for ways to deal with CMYK as a subset of the ink-plate printing/spot-color problem. Is it is easy to create and dynamically update/replace ICC profiles programattically using LCMS/agryll for a combination of inks coming from a couple of pantone colors (and yes, I'll include metallics and reflective transparent again); on a custom fabric choice. Like perhaps simulating the printing of silver, black and reflective transparent on top of black fabric.

That's a question for the ArgyllCMS mailing list. People on that list profile all kinds of very odd things for specialized print reproduction, including rock specimens, tile samples, and oil paints. I doubt any of them would describe the process as "easy".

I've spent more time writing emails about this code; than writing - and playing with it. It would've been nice if you had had time to come to LGM.

Time is one thing. Family responsibilities are another. Sometimes there are conflicts. We all do the best we can.

See

https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html

for an older writeup I did on the topic of GEGL and color.

I read your writeup several times over when you first posted it and also recently. But I'm not sure I understand it. Below is a summary of what I think your writeup means in terms of an image-editing workflow using GIMP:

1. When a user opens an image: a. If there isn't an embedded ICC profile, sRGB is assigned. The user has the option to assign a different ICC profile. b. If there is an embedded ICC profile, to cover cases where the embedded ICC profile is incorrect, the user has the option to assign a different ICC profile.

2. Once the initial ICC profile assignment is taken care of: a. The image precision is promoted to 32-bit floating point R'G'B'A (32-bit floating point gamma). b. The image is converted to the regular sRGB color space. c. As the conversion is done using LCMS2 unbounded mode, no colors are clipped during the conversion. Instead, out-of-gamut colors are expressed using RGB values such that one or more of R, G, and B are less than 0 and/or greater than 1.

3. Although the image really is in the regular sRGB color space, all editing is done in a linear light version of the sRGB color space, which ensures that colors blend correctly: a. If certain layer blending operations look wrong when blended using the 32-bit floating point *gamma* precision, the user can opt to use 32-bit floating point *linear* precision (32-bit floating point RGBA). b. Some operations (for example painting with a brush and Gaussian blur) are always done using linear light, regardless of whether the image is converted to linear or to gamma floating point precision.

4. BABL has functions for converting sRGB to LAB, HSV, CMY, etc, for use in decomposing and composing. Also, babl/gegl/gimp all have functions for calculating the luminance of an sRGB image. Compose/decompose/calculating luminance are all done to/from/in linear light sRGB.

5. When linear light sRGB is required for an operation: a. Certain BABL functions "undo" the regular sRGB TRC to create linear light sRGB.
b. The required editing operations are performed. c. The image is returned to the regular sRGB color space. These "to/from linear light" BABL functions include four functions in /babl/babl/base/util.h: linear_to_gamma_2_2, gamma_2_2_to_linear, babl_linear_to_gamma_2_2, and babl_gamma_2_2_to_linear.

6. Before exporting the edited image, the user can convert the image to the desired bit depth and ICC color space profile.

7. At present ICC profile conversions are handled by GIMP, but in the future they will be handled by GEGL. A start on GEGL color management is found in "gegl/operations/external/lcms-from-profile.c".

Does my description of the anticipated workflow cohere with what you've described? Did I get parts/all of it wrong?

Elle

Øyvind Kolås
2014-03-17 16:44:51 UTC (9 months ago)

Soft proofing and the GIMP Display Filters and Color Management settings

On Sun, Mar 16, 2014 at 10:22 PM, Elle Stone wrote:

On 03/14/2014 10:34 AM, Øyvind Kolås wrote:

On Fri, Mar 14, 2014 at 2:21 PM, Elle Stone wrote:

But a
patch to LCMS for more than four inks is surely possible.

Doing soft spectral spot color proofing, might be outside the scope of LCMS2, or the resulting data might end up being prepared and baked into ICC profiles using LCMS for the pre-separated output.

The code *experiment* linked to has nothing to do with ink limiting; what I linked to is rather naive additive and subtractive color mixing in a 20 band spectral color space, a little bit like how physics works. But yes; as I noted it doesn't take into account subsurface scattering and other things that ICC profiles try to encompass indirectly.

My apologies. Clearly I didn't read the code carefully enough.

That's a question for the ArgyllCMS mailing list. People on that list profile all kinds of very odd things for specialized print reproduction, including rock specimens, tile samples, and oil paints. I doubt any of them would describe the process as "easy".

Note that spectral measurements of spot colors is also used for standards based spot color soft proofing, see http://color.org/CxF_test.xalter .

In a future GIMP with ink/plate targeting capabilities; it would be reasonable to let the operator experiment with adding and removing/rearranging inks interactively in GIMP; and some suitable good GEGL op is used for previewing purposes (some of these options; might already want meta data about the spot colors encoded in a passed in profile.).

https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html

for an older writeup I did on the topic of GEGL and color.

I read your writeup several times over when you first posted it and also recently. But I'm not sure I understand it. Below is a summary of what I think your writeup means in terms of an image-editing workflow using GIMP:

1. When a user opens an image: a. If there isn't an embedded ICC profile, sRGB is assigned. The user has the option to assign a different ICC profile. b. If there is an embedded ICC profile, to cover cases where the embedded ICC profile is incorrect, the user has the option to assign a different ICC profile.

The same conversation to a babl managed pixel format applies on import. Though we might be loading the data in the native representation and only later turn it to a babl managed pixel format (these are also spaces we can deal with ourselves on the GPU) using a GEGL operation, or even an implicit conversion with ICC profiles managed by a babl-extension. For a composition of multiple source images; these ICC profile settings might vary per asset; and you want to be able to tweak some of it after the initial import/load. When using GIMP 2.9 in 8bit mode; implicit babl conversions keep turning the data 32bit as explained below.

2. Once the initial ICC profile assignment is taken care of: a. The image precision is promoted to 32-bit floating point R'G'B'A (32-bit floating point gamma).
b. The image is converted to the regular sRGB color space. c. As the conversion is done using LCMS2 unbounded mode, no colors are clipped during the conversion. Instead, out-of-gamut colors are expressed using RGB values such that one or more of R, G, and B are less than 0 and/or greater than 1.

3. Although the image really is in the regular sRGB color space, all editing is done in a linear light version of the sRGB color space, which ensures that colors blend correctly:
a. If certain layer blending operations look wrong when blended using the 32-bit floating point *gamma* precision, the user can opt to use 32-bit floating point *linear* precision (32-bit floating point RGBA).

b. Some operations (for example painting with a brush and Gaussian blur) are always done using linear light, regardless of whether the image is converted to linear or to gamma floating point precision.

Yes, as image data flows through the GEGL processing graph - the generated temporary output buffers end up being in the preferred working pixel format of the operation. If all your operations used in a pipeline are have "CIE Lab float" as their desired working/output space, there would be only one implicit conversion to CIE Lab at the beginning - no conversions between the operations since the data is already in the desired format. And then an implicit conversion to the desired reading format of for instance a PNG exporting op. Most of the operations in GEGL generate either "RGBA float" or "RaGaBaA float" buffers.

4. BABL has functions for converting sRGB to LAB, HSV, CMY, etc, for use in decomposing and composing. Also, babl/gegl/gimp all have functions for calculating the luminance of an sRGB image. Compose/decompose/calculating luminance are all done to/from/in linear light sRGB.

babl is intended to provide accurate and fast, conversions between a large; and dynamically extended set of pixel formats. It provides a way to register and describe pixel formats (color model, order of components and data types used by components.) and has a reference color conversion engine that goes through double precision floating point linear light sRGB that automatically provides conversions between the pixel formats that can be described.

On top of those capabilities; babl has extensions for direct conversions between registered pixel formats; these conversions are checked against the reference at runtime and benchmarked against each other at runtime. Chains of conversions are also checked for accuracy and speed performance. All GeglBuffers are annotated with what BablFormat the pixels within have.

The CMYK model in babl as it stands is only intended for annotating that a GeglBuffer contains CMYK; it likely does a really bad job at both decomposing to inks; as well as turning inks to RGB again - it does something though; instead of just giving you black pixels back.). babl also has the abilitiy to deal with indexed/paletted pixels like in GIFs. Where correct using babl for decomposing/recomposing is good - in some cases, like CMYK we'd want GEGL operations that are not using babl but for instance lcms2.

5. When linear light sRGB is required for an operation: a. Certain BABL functions "undo" the regular sRGB TRC to create linear light sRGB.
b. The required editing operations are performed.

c. The image is returned to the regular sRGB color space. These "to/from linear light" BABL functions include four functions in /babl/babl/base/util.h: linear_to_gamma_2_2, gamma_2_2_to_linear, babl_linear_to_gamma_2_2, and babl_gamma_2_2_to_linear.

For c. see above, this part is wrong; though in GIMPs case when doing editing in a "gamma" based space; it is true for applying destructive editing operations, but for compositing the layer stack; the data is not returned to 8bpc sRGB until the final result is displayed on screen.,

The utility functions enumerated are part of the reference conversion (and also used by some of the fast paths). The use in the fast paths is not really clean; since it encourages micro optimizations in the reference code paths; that wouldn't be detected if they cause errors.. but it has the benefit of making all users of the utility functions faster.

6. Before exporting the edited image, the user can convert the image to the desired bit depth and ICC color space profile.

How and when export profile preferences are configured and managed is open. If we ignore concern of ink separation workflows; it is at export time (as well as during soft proofing) that the data would end up being converted to the desired bit depth and ICC color profile.

7. At present ICC profile conversions are handled by GIMP, but in the future they will be handled by GEGL.

Some code will likely remain in GIMP, primarily UI related and setting up the processing using GEGL will remain in GIMP, the actual conversions of pixels values would be done by GEGL operations.

A start on GEGL color management is found in "gegl/operations/external/lcms-from-profile.c".

A start on using lcms2 for GEGLs external color management is more correct ;) Internally GEGL uses babl for to provide a way to carry color (and alpha)-management meta data along with the pixels of buffers.

Does my description of the anticipated workflow cohere with what you've described? Did I get parts/all of it wrong?

More correct than wrong. My focus is more on the pipeline than the workflow; the pipeline provides some constraints on which workflows makes sense and which do not.

/Øyvind K.