After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 169365 - Selection boundary not fully obeyed by bucket fill tool
Selection boundary not fully obeyed by bucket fill tool
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Tools
2.2.x
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-03-06 08:41 UTC by James Gholston
Modified: 2018-05-24 11:27 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description James Gholston 2005-03-06 08:41:28 UTC
Version details: All
Distribution/Version: All

With an image, have a solid color area connecting to another area of that color
and a separate nonconnected area.  With any selection tool, select all three
areas but exclude the part that connects the first two areas so that you can
fill the first area without filling the other two, plus not go outside of your
selection.   Unfortunately, the bucket tool fails to pay attention and gleefully
fills in the enclosed part of the second area when you fill the first, even
though they have no connection inside the selection.

This is for some applications and users, a show-stopper, in this case, a
cartoonist I've been trying to get to switch to GIMP for half a decade.  Right
now this bug is her ONLY show-stopper.  

If this behavior is considered an important nifty feature for some other users,
then the behavior needs to be selectable between them -- as the expected
behavior I describe is what most users will be expecting to occur.

http://www.dolari.org/images/forumimages/before.jpg
http://www.dolari.org/images/forumimages/after.jpg

These examples don't fully reproduce the scenario I describe, but rather show an
example of why it's a show stopper for someone who's trying to meet a deadline.

I have reproduced this on my Windows 2000 machine runnig 2.2.4 and my Libranet
Debian machine running 2.0.  It should be strongly considered for any bugfix
releases for legacy versions.

Strangelv
Comment 1 weskaggs 2005-03-06 16:27:59 UTC
I was at first going to say that there is no bug here, but actually I think you
are right.  Quite a while ago the sort of behavior you are asking for was
requested by somebody else, in bug #72896, and the developers agreed that it was
a good idea, and tried to implement it.  But it seems that the implementation
was not quite perfect:  if you choose "Fill similar colors" in the bucket fill
options, the tool apparently first floods outward from the start point, and then
applies the selection to the result.  It really should be done in the other order.
Comment 2 weskaggs 2005-03-07 15:26:18 UTC
Just a note:  what is required to get this to work properly is to modify the
function gimp_image_continuous_region_by_seed() in
app/core/gimpimage-contiguous-region.c, so that it takes a "selection mask"
argument and rejects pixels that are not selected.  This would also mean
modifying the functions find_contiguous_region_helper(),
find_contiguous_segment(), and pixel_difference(), correspondingly.  Probably
not too difficult, except that the code is highly optimized and hence not very
readable. 
Comment 3 Andrew Roazen 2005-04-05 23:44:11 UTC
You're assuming the possibility of a selection mask should be integrated into
the bucket fill code, or even that Adobe does this with their "Contiguous"
checkbox on the bucket tool. Try this idea instead: As soon as the user clicks
inside the region in the original image (O), create two buffers; one, a bounding
box copy of the selected region (C) and another consisting of the alpha mask the
selection delineates (A). Perform the standard bucket fill in the corresponding
spot, then combine C and O using A as a mask. Am I missing something here?
Comment 4 weskaggs 2005-04-06 15:45:08 UTC
I think so.  The method you are describing (if I understand it) is essentially
the one that GIMP currently uses, and the problem with it is that it can produce
the undesirable results described in this bug report.
Comment 5 Tom McAnally 2007-03-12 16:48:16 UTC
Similar problems with flood-fill using the tolerance feature (no masking), calculating tolerance downwards differs from the upwards tolerance.

Example: I snagged the following image from Rudy Rucker's FLURB webzine

http://www.flurb.net/2/goldie_allesame.jpg

I wanted it for desktop wallpaper, so I flood-filled the white surround with black. At a lower setting, I am left with a white fringe at the bottom of the picture. When I adjusted the tolerance to fix this, and ended up with black bleeding into the central image from the top.
Comment 6 Luidnel Maignan 2008-08-13 08:59:59 UTC
I would like to add that the described behaviour can be obtain by using the "Float Selection" feature. Following the initial comment description, do [Edit->Select->Float] just before using the Bucket Fill Tool. As the float selection layer is created, the selection mask is applied before as suggested in comment #1, and is maybe the idea behind the comment #3.

Then the requested option is already possible. Is that solution enough to close this bug or should it be easier to do that or more user-friendly to have an additional option in the Bucket Fill Tool ?
Comment 7 GNOME Infrastructure Team 2018-05-24 11:27:43 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/135.