GNOME Bugzilla – Bug 779620
"Advanced Color Options" in filter dialogs is confusing
Last modified: 2017-05-01 00:10:27 UTC
Filter and Color operations "Advanced Color Options/Apply filter in color managed space (slow)" is mislabeled. GIMP already is a color-managed image editor, but this Advanced Color Option makes it sound like GIMP really isn't color-managed unless the user uses the option to "Apply filter in color managed space (slow)". Here is a more informative label: "Convert the image to GIMP's built-in sRGB color space before running the operation. Please note that this will allow some operations to produce technically correct results and make other operations produce surprisingly wrong results, and we are leaving it up to you to figure out which is which." Making the right choice for this option requires that the user have a detailed working understanding of: (1)The basics of radiometrically correct color mixing. (2)Which GIMP editing operations use Y, XYZ or LAB/LCH. (3)Which GIMP editing operations are chromaticity-dependent. (4)Which GIMP editing operations assume an RGB channel encoding different from what is specified by your image's ICC profile. (5)How GIMP treats images with embedded linear gamma ICC profiles. (6)How GIMP treats various image file types that don't support ICC profiles. See http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html for details, and follow the links for examples of various critically important operations that will produce very wrong results when using the option to "Apply filter in color managed space (slow)". IMHO it would be far better for users to just be told that: * GIMP 2.10 only supports editing sRGB images * Support for "anyrgb" and "anytrc" requires waiting for future GIMP * Anyone who wants to edit non-sRGB images should realize that for most editing operations, GIMP 2.9/2.10 won't produce correct results. Or if "anyrgb" (but not "anytrc") really is a goal for 2.10, try this two-part approach: 1. Provide a Preferences option to convert images upon import to a new ICC profile color space with the image's original ICC profile's primaries and the sRGB TRC. This will take care of all GIMP operations that produce wrong results because of a mismatch between babl's currently assumed sRGB TRC and the image's ICC profile's actual TRC. 2. Make one of the following code changes: * Provide a second Preferences option to convert from the image's assigned ICC profile to the built-in GIMP sRGB profile for all editing operations that require a conversion to Y/XYZ/LAB/LCH. Unfortunately making a grayscale layer mask does require a conversion to Y, as does converting to Luma/Luminance. * Better yet, set up a global variable for converting to Y/XYZ/LAB/LCH. My patched GIMP already has working code for such a global variable. I'm not sure how this would affect GIMP's color-managed color picker as I had to pretty much rewrite all of that code to make it work with my global variable for passing Y/XYZ/LAB/LCH information around. As an aside, for 3.0, I suspect it might make for more flexible code going forward (as in forward towards "anyrgb" and "anytrc") if the channel-encoding code is modified such that the assumed starting TRC is linear instead of the sRGB TRC.
I think this options, and the gamma hack options, should only be visible if explicitly enabled through a toggle in preferences - as to not confuse new operators with more toggles that provide subtle differences in results. .. The last statement I also agree with; a making use of a linearized ICC profile based on the image profile will likely make interaction with lcms2 easier. In particular for the planned work for GIMP 3.x or beyond in babl for supporting first arbitrary RGB primaries and at a later stage arbitrary transfer functions.
(In reply to Elle Stone from comment #0) > As an aside, for 3.0, I suspect it might make for more flexible code going > forward (as in forward towards "anyrgb" and "anytrc") if the > channel-encoding code is modified such that the assumed starting TRC is > linear instead of the sRGB TRC. The above sentence shouldn't be part of this bug report, as it's an aside that isn't specifically focussed on the actual topic of the bug report. My apologies for making an aside. The bug report is about the fact that the option to "Apply filter in color managed space" (1) has a very misleading label and (2)it's not at all easy to explain to users what this option does and when to use it. There has to be a better way to accomplish whatever it is that "Apply filter in color managed space" is intended to accomplish. If the actual goal of "Apply filter in color managed space" is "any rgb", then maybe that goal should be deferred to future GIMP. Or else use the code in a different way, that's easier for users to understand and make decisions accordingly.
Will look into it.
Created attachment 348702 [details] [review] Change wording in Advanced Color Options menu Proposed rewording, to not imply that GIMP isn't color-managed: "Convert layer to GIMP's built-in sRGB to apply filter (slow)" "Assume GIMP's built-in sRGB (ignore actual image color space)"
(In reply to Øyvind Kolås from comment #1) > I think this options, and the gamma hack options, should only be visible if > explicitly enabled through a toggle in preferences +1, completely agree. Otherwise this option is present in the various Filter and Color dialogs, and so requires documentation. Accurate documentation of what the Advanced options really do requires a fairly complicated flowchart. With a detailed flowchart, for many operations the user could use these options to produce what would happen if GIMP already supported anyrgb and/or anytrc. Without a detailed flowchart (that includes things like current and past image precision including any conversions between linear and gamma precision, whether the image was originally in a linear gamma color space, and the particular operation in question), the user is reduced to "push the button and see if you like the results".
Review of attachment 348702 [details] [review]: I won't accept nor reject it because I don't feel qualified enough to be sure, but it looks understandable to me, which is a good thing. So I'd say the change is good and we could commit it. Mitch? Pippin? Do any of you agree with this?
Note that for all the details on what these means exactly (cf. the bug description), this could be in the doc, not in the GUI obviously. :-) Yet there could also be a mouse-hover tooltip with slightly more text if needed. If you feel it necessary, I guess.
I'm on this, using quite some more code, please don't push.
Step one: change the combo's wording (not quite) as suggested: commit c940b5d376b503b78c16151ba9f5de3f237043f8 Author: Elle Stone <ellestone@ninedegreesbelow.com> Date: Sat Mar 25 10:18:32 2017 -0400 Bug 779620 - "Advanced Color Options" in filter dialogs is confusing Change wording in Advanced Color Options drop-down menu to not imply that GIMP isn't color-managed. Slightly changed wording from Elle's original patch (mitch). Also set the combo box' "ellipsize" property to END because it's too wide. As mentioned before, this doesn't work for whatever reason, hints are appreciated :) app/tools/gimpfiltertool.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Fixed in master: commit 4455cd984dffbc3adea56b08a5b03b4b671a4ace Author: Michael Natterer <mitch@gimp.org> Date: Mon May 1 02:07:09 2017 +0200 Bug 779620 - "Advanced Color Options" in filter dialogs is confusing Hide "Advanced Color Options" by default, and add a toggle to show them to prefs -> color management. app/config/gimpguiconfig.c | 14 ++++++++++++++ app/config/gimpguiconfig.h | 1 + app/config/gimprc-blurbs.h | 5 ++++- app/dialogs/preferences-dialog.c | 9 +++++++++ app/tools/gimpfiltertool.c | 6 +++++- 5 files changed, 33 insertions(+), 2 deletions(-)