GNOME Bugzilla – Bug 791519
Unexpected selection from channel
Last modified: 2018-04-10 00:05:25 UTC
Created attachment 365432 [details] Gradient + selection example. When following the Luminosity Masking tutorial (https://www.gimp.org/tutorials/Luminosity_Masks/) there are steps that require the subtraction and intersection of channels. In 2.9.6 on windows you can reproduce the problem by: 1. Create a gradient from black to white that spans the entire image from left to right. 2. On the channels, right click any channel and do "Channel to Selection". Problem: The lighter ~20-25% of the gradient will become selected with marching ants. Expected: Half of the gradient (lighter side) will become selected, with marching ants in the middle of the gradient. (It works in 2.8). To investigate further, the expected result would normally be a smooth selection. In 2.8, filling the selection with another color would show a smooth transition across the entire image. In 2.9.6 it is not (and is bunched up on the lighter side of the gradient). I'm attaching an .xcf that has a gradient, plus a selection (from "Channel to Selection" of the Red channel). Opened in 2.8, it shows the selection in the middle of the gradient. Opened in 2.9.6 it will show the selection on the lighter ~20-25% of the gradient.
I can confirm this behavior. The gradient is drawn "as if" the image were in the regular sRGB color space. But the selection resulting from loading a channel is made "as if" the image were in the linear gamma sRGB color space: In my "CCE" version of GIMP-2.9, making a new image in the regular sRGB color space, making a black to white gradient, and loading a channel as a selection produces a selection that covers half the image. The only way to duplicate results in default GIMP is to convert the image to a linear gamma sRGB profile. In default GIMP, when loading a channel as a selection, regardless of whether the image is at linear or gamma precision, only about a quarter of the image is selected. From using the luminosity masks in my CCE version of GIMP, and making the masks when the image is in a linear gamma color space versus a perceptually uniform color space, my impression is that the masks made in the perceptually uniform color space are more useful even if the image itself is then converted to a linear gamma color space. But this is just a tentative conclusion based on experiments made several months ago.
Isn't this a duplicate of 791512?
It seems to be. However, after making the indicated code changes from bug 791512 and then following Pat's tutorial, only the first step, creating the "Lights" produces the expected result. The second step, selecting the entire image and then subtracting the "Lights", doesn't produce the same as inverting the Lights. But for Pat's tutorial to work, subtracting "Lights" from the entire selection should produce the inverse selection of "Lights". I don't think just changing the midpoint in that one file will allow making the luminosity masks. To produce the same result as 2.8, these masks require operating on RGB encoded using the sRGB TRC.
(In reply to Elle Stone from comment #3) > doesn't produce the same as inverting the Lights I meant to say "doesn't produce the same as inverting the Lights selection"
precision note: there is no difference between selection and channels ; selection is no more than a permanent channel (which does not appear in the channels dock) from which the marching ants boundaries are computed. In 2.8, channels pixels are combined in perceptual gamma. https://git.gnome.org/browse/gimp/tree/app/core/gimpchannel-combine.c?h=gimp-2-8#n505 In master, they are always combined in linear light, whatever the image precision. https://git.gnome.org/browse/gimp/tree/app/core/gimpchannel-combine.c#n216 https://git.gnome.org/browse/gimp/tree/app/gegl/gimp-gegl-mask-combine.c#n371 So the selection buffer resulting of channels combination (add, subtract, intersect) is not the same in 2.8 and master. How marching ants boundaries are computed in 2.8 and in master is another independent issue, even if related to linear versus perceptual gamma. https://bugzilla.gnome.org/show_bug.cgi?id=791512
So now that bug 791512 is fixed, I understand that the only remaining complaint is that channel combinations work differently in 2.8 and master. Yet from what I read from comment 5, this is expected and maybe even wanted. Is it just how channel combinations evolved and tutorials have to go with it and find alternative processes? Or is there anything that we want to do about that?
Making it a 2.10 blocker so that we answer this question by 2.10 release.
Created attachment 366128 [details] luminosity masks created using perceptual vs linear rgb I created luminosity masks for a "step wedge" image using my "CCE" version of GIMP, which makes it easier than using default GIMP to test the results of using linear RGB vs perceptually uniform RGB. The attached screenshot shows two copies of the "step wedge" image. For both copies of the step wedge image, the top four rows show perceptually uniform steps and the bottom row shows linear steps. The only difference between the two step wedge images is that the one pictured at the top of the attached png was converted to a perceptually uniform RGB color space, and the one at the bottom was converted to a linear gamma RGB color space. For each copy of the step wedge image I used Saul Goode's luminosity mask filter to create the luminosity masks. Then I loaded the "DD" mask and added to it the "LL" mask. As you can see: * When using perceptual RGB, the "DD" and "LL" selections are approximately equal, and the unselected portions represent the midtones. * When using linear RGB, the "DD" selection occupies about half the image and the "LL" selection is squeezed into the brightest highlights, and what's left unselected isn't really midtones. What people expect when using the luminosity masks is the result of making the masks using perceptual RGB, not linear RGB. This makes perfect sense because when using such masks, usually (maybe not always, but usually) we want the selections to match how we *perceive* differences in shadows, midtones, and highlights.
I don’t have much to add as Elle already covered my points better than I could have. I have no problem updating tutorials to match any evolution of the tools, but I tend to agree with Elle’s observation that people using luminosity masks would likely expect them to behave as if in perceptual RGB. (It’s already a concept that’s tough for some to wrap their heads around, without throwing linear RGB into the mix - pun intended).
This should fix it. >8-bit images saved with earlier 2.9 versions will now probably have broken channels, but who uses unstable GIMP for production :) Elle, Pat, can you test the previously broken cases again please? commit bb4ac7c8293ad994f82b257b32fc27c3eafd2b26 Author: Michael Natterer <mitch@gimp.org> Date: Sun Apr 8 19:16:58 2018 +0200 Bug 791519 - Unexpected selection from channel Storing selections and layer masks as linear grayscale, but channels as whatever-the-layers-are caused severe problems in images with gamma-corrected layers: when combining channels with the selection, they would go thorugh a gamma conversion before being combined, giving unexpected results. This commit changes all channels to always be linear, except in 8-bit images, where they continue to be "Y' u8", for compatibility with old XCF files, and because linear 8-bit can't really be used in compositing (channels can be visible too). To fix channel -> selection combinations also for these images, add a small hack to gimp_gegl_mask_combine_buffer() which makes sure the to-be-combined channel's pixels are always read as-is, without any gamma conversion. After changing channels to linear, this makes no difference except in the 8-bit images where we need this hack. app/core/gimpimage.c | 13 ++++++++++--- app/gegl/gimp-gegl-mask-combine.c | 19 ++++++++++++++++++- 2 files changed, 28 insertions(+), 4 deletions(-)
One additional fix: commit 8994246be259d05c33942a5c908c0907f96e0c5b Author: Michael Natterer <mitch@gimp.org> Date: Sun Apr 8 20:26:32 2018 +0200 Bug 791519 - Unexpected selection from channel One additional fix for the gimp-channel-combine-masks procedure, it needs both the combined *and* combined-to buffer in gimp_gegl_mask_combine_buffer() to be treated specially. app/gegl/gimp-gegl-mask-combine.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
FWIW, these new channels from the luminosity mask plug-in look right to me.
I'm not so sure. I just compiled from git $ gimp-2.10.exe -v GNU Image Manipulation Program version 2.10.0-RC1-git git-describe: GIMP_2_10_0_RC1-119-gf5cb1fed85 If I create a new image and add a gradient from black to white across the image, selecting the red channel and do "Channel to Selection" - I still get a selection that is not in the middle of the gradient (8-bit, perceptual gamma (sRGB)). https://i.imgur.com/Tke7oFc.png I would expect to get a selection of the brighter half of the image, not this.
*** Bug 791512 has been marked as a duplicate of this bug. ***
Now 150% fixed: commit 3f95dc52d3232cac64283d9514e6d8bcf32df951 Author: Michael Natterer <mitch@gimp.org> Date: Tue Apr 10 02:00:23 2018 +0200 Bug 791519 - Unexpected selection from channel Make sure a channel -> selection -> channel roundtrip never does any gamma conversion. In gimp_channel_duplicate(), make sure a created channel has the right format, and the right data. Fixes selection -> channel. When switching off quick mask, call gimp_item_to_selection() instead if gimp_selection_load(), the latter was implementing a shortcut which is now wrong. Remove gimp_selection_load() which is now unused. Unrelated: also remove gimp_selection_save(), it was an obvious 3-liner used only twice. app/actions/select-commands.c | 14 ++++++++--- app/core/gimpchannel.c | 32 +++++++++++++++++++++++++ app/core/gimpimage-quick-mask.c | 6 ++--- app/core/gimpselection.c | 53 ----------------------------------------- app/core/gimpselection.h | 4 ---- app/pdb/selection-cmds.c | 13 ++++++++-- pdb/groups/selection.pdb | 13 ++++++++-- 7 files changed, 68 insertions(+), 67 deletions(-)