GNOME Bugzilla – Bug 553855
Bucket fill colour is always blended with filled pixel colour when threshold > 0
Last modified: 2016-09-15 10:30:10 UTC
Please describe the problem:
The problem was observered when attempting to remove a large area of near white pixels around a logo (from a scanned image). Because the near white pixels are all slightly different colours I attempted to use a FG fill with 100% opacity and a threshold of 10 to convert all of the near white pixels to my target colour. I used purple as my target colour to determine if my tolerance would match the necessary pixels. The tolerance match works as expected, however the filled in colour isn't the same consistent solid purple - but is instead blended with the matched pixel's colour
Steps to reproduce:
1. Create a new solid white image, say 200x200 px
2. Use the "Filters"->"Noise"->"RGB Noise" tool to add random noise to the image (I used 0.2,0.2,0.2 for the RGB values)
3. Use "Colours"->"Desaturate" to give a grey scale (near white) image. This is our starting case
4. Select the "Bucket Fill" tool, pick an obvious fill colour (I chose #FF00FF), Mode=Normal, Opacity=100, Type=FG colour, Area=Fill Similar, Fill transparent=checked, Sample Merged=unchecked, Threshold=10.0, Fill By:Composite or Value
5. Left click somewhere in the image to being the fill
6. Observer that the filled pixels aren't all uniformly #FF00FF
Some proportion of the pixels are filled (based on the tolerance setting). The filled colour is not uniformly the fill colour selected - as if a non 100% opacity were being used
Some proportion of the pixels should be filled (based on the tolerance setting). The filled pixels should all be exactly the fill colour I selected.
Does this happen every time?
You make a very good point here, and frankly, I have never noticed this
It remains to be discussed whether any of the behaviors is "correct"
or if it is desirable to have both as an option.
Thanks anyway for this really high quality bug report.
I'd agree it's difficult to determine which is correct. My personal opinion is that the current behaviour isn't correct based on past experience of other similar software. I'd also argue that the fill isn't respecting the 100% opacity setting - and from that standpoint the current behaviour is wrong.
Actually, this is simply the "gboolean antialias" parameter in
gimp_image_contiguous_region_by_seed() which is used internally.
We simply need a decision here, setting milestone.
Fixed in master:
Author: Michael Natterer <email@example.com>
Date: Thu Sep 15 12:24:37 2016 +0200
Bug 553855 - Bucket fill colour is always blended with filled pixel colour...
...when threshold > 0
Add an "Antialias" toggle to the bucket fill options and set it on the
GimpFillOptions. In gimp_drawable_bucket_fill(), pass it to
gimp_pickable_contiguous_region_by_seed() instead of always defaulting
The position of the toggle and its huge tooltip may need some
app/core/gimpdrawable-bucket-fill.c | 5 ++++-
app/tools/gimpbucketfilloptions.c | 28 ++++++++++++++++++++++++++++
app/tools/gimpbucketfilloptions.h | 1 +
app/tools/gimpbucketfilltool.c | 2 ++
4 files changed, 35 insertions(+), 1 deletion(-)