GNOME Bugzilla – Bug 791512
[PATCH] make the selection boundary detection the same as 2.8
Last modified: 2018-04-09 22:31:01 UTC
Created attachment 365413 [details] [review] change the GIMP_BOUNDARY_HALF_WAY threshold value to 0.212 As pointed by pat david on IRC, selection boundary resulting from channel selection is not the same as gimp 2.8. Use a threshold value of 0.212 instead of 0.5, since selection and channels buffers are always in linear precision. This value will match the 8bits gamma-corrected threshold value of 127 in gimp 2.8.
Hi Thomas! Do you mean "channel to selection"? Could you explain a bit the issue for people who weren't on iRC? :P If you are sure of your patch and Pat David even confirmed the fix, I would suggest to push it but since you published it on bugzilla first, I wouldn't mind an explanation. Also in the patch, you could add a comment before the macro to explain where this value comes from (to avoid just the "magic values" issue).
Set this as a 2.10 blocker since it's about having same behavior as 2.8 and there is a proposed patch.
Each time marching ants boundaries need to be computed, each pixel of the selection buffer is compared to a threshold value to determine if it is inside or outside the selection. In 2.8, where selection pixels are stored in perceptual gamma, a 8bits threshold value of 127 is used, which correspond approximately to the medium gray. https://git.gnome.org/browse/gimp/tree/app/core/gimpchannel.c?h=gimp-2-8#n995 https://git.gnome.org/browse/gimp/tree/app/base/boundary.h?h=gimp-2-8#n23 In master, the boundaries computation is performed in linear light instead of perceptual gamma: https://git.gnome.org/browse/gimp/tree/app/core/gimpchannel.c#n1169 but the used threshold value is still in perceptual gamma (the 8bits 127 value was only converted to floating point precision and rounded to 0.5) https://git.gnome.org/browse/gimp/tree/app/core/gimpboundary.h#n23 To obtain the same boundaries as in 2.8, either the threshold value must be converted to linear light, or the computation must be performed in perceptual gamma.
Let me repeat my comment from IRC here: I would prefer if we had two defines, GIMP_BOUNDARY_HALF_WAY_PERCEPTUAL and GIMP_BOUNDARY_HALF_WAY_LINEAR so it's obvious in every piece of code, and when future changes happen people will be reminded to think twice.
Created attachment 365725 [details] [review] define and use GIMP_BOUNDARY_HALF_WAY_LINEAR in channels selection boundary detection
Go ahead and push please.
pushed to master commit 27512d802b221df14b7c805e4ceccf710fcd0e4e (HEAD -> master) Author: Thomas Manni <thomas.manni@free.fr> Date: Mon Dec 18 21:01:30 2017 +0100 Bug 791512 - make the selection boundary detection the same as 2.8 Replace the GIMP_BOUNDARY_HALF_WAY macro by two others : one for perceptual and one for linear gamma. Use the GIMP_BOUNDARY_HALF_WAY_LINEAR to compute channels and floating selection boundaries. app/core/gimpboundary.h | 3 ++- app/core/gimpchannel.c | 4 ++-- app/core/gimplayer-floating-selection.c | 2 +- app/tools/gimpregionselecttool.c | 2 +- 4 files changed, 6 insertions(+), 5 deletions(-)
I'm afraid this commit was only hiding the problem, making it look as if the result of "channel to selection" was doing the right thing. Reverting. commit bba8f695941fa52b1bef60c3c5cf8f251229fb18 Author: Michael Natterer <mitch@gimp.org> Date: Tue Apr 10 00:26:01 2018 +0200 Revert "Bug 791512 - make the selection boundary detection the same as 2.8" This commit was fixing only a symptom of our channel/selection problem, making it appear things were fine. This reverts commit 27512d802b221df14b7c805e4ceccf710fcd0e4e. app/core/gimpboundary.h | 3 +-- app/core/gimpchannel.c | 4 ++-- app/core/gimplayer-floating-selection.c | 2 +- app/tools/gimpregionselecttool.c | 2 +- 4 files changed, 5 insertions(+), 6 deletions(-)
The actual fix was done for bug 791519. *** This bug has been marked as a duplicate of bug 791519 ***