RSS/Atom feed Twitter
Site is read-only, email is disabled

`Bucket fill' ..

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

5 of 8 messages available
Toggle history

Please log in to manage your subscriptions.

87psk8ig63.fsf@gimp.org 07 Oct 20:24
  `Bucket fill' .. Gerald Friedland 27 Mar 10:02
   `Bucket fill' .. Sven Neumann 27 Mar 10:58
44270674.4090205@c-art.com 07 Oct 20:24
6bff6b5a0603270138r5d71d5ax... 07 Oct 20:24
  `Bucket fill' .. Sven Neumann 27 Mar 12:01
   `Bucket fill' .. Nathan Summers 28 Mar 16:38
    `Bucket fill' .. Sven Neumann 28 Mar 20:47
Gerald Friedland
2006-03-27 10:02:59 UTC (about 18 years ago)

`Bucket fill' ..

I think his problem is that he is trying to bucket fill a natural image. This doesn`t really work as there are too much colors in natural images and thresholding doesn`t really work.... (for example, try to bucket fill a gradient).
However, this gets me to an idea: We could build a "natural" bucket fill tool by reducing the colors using color clustering from SIOX and then fill. The color reduction would have to be much more radical, like with limits={5,5,10} or even higher values. I guess it has to be user controllable at the end... but this is something that I miss in every image manipulation program. Maybe we can put this on the task list.

On 3/27/06, Sven Neumann wrote:

Hi,

John Eadie writes:

For instance, how can you make the bucket fill tool actually do anything?

Point and click ?!

Seriously, your question doesn't make a lot of sense to me. The tool should just work. If it doesn't, you should perhaps describe what exactly you are trying to do and how.

Sven

Sven Neumann
2006-03-27 10:58:44 UTC (about 18 years ago)

`Bucket fill' ..

Hi,

"Gerald Friedland" writes:

I think his problem is that he is trying to bucket fill a natural image. This doesn`t really work as there are too much colors in natural images and thresholding doesn`t really work.... (for example, try to bucket fill a gradient).

What does not work about bucket-filling a natural image or a gradient? Sure, it doesn't make much sense, but it still does what it is supposed to do.

However, this gets me to an idea: We could build a "natural" bucket fill tool by reducing the colors using color clustering from SIOX and then fill. The color reduction would have to be much more radical, like with limits={5,5,10} or even higher values. I guess it has to be user controllable at the end... but this is something that I miss in every image manipulation program. Maybe we can put this on the task list.

Can you explain to me why you would want to bucket-fill parts of a photograph and why you cannot do that by selecting the relevant parts and filling this selection? I am having problems to see the problem that you are trying to address here.

Sven

Sven Neumann
2006-03-27 12:01:37 UTC (about 18 years ago)

`Bucket fill' ..

Hi,

"Gerald Friedland" writes:

and why you cannot do that by selecting the relevant parts and filling this selection? I am having problems to see the problem that you are trying to address here.

True. As long as you have got an appropiate selection too, you could select the object, fill it, and you are done. A "natural" bucket fill would just be a short cut to this process.

Do we really need the overhead in code and complexity to achieve something that can be easily done in two steps? I think that using the selection tools followed by a fill is the natural way to achieve the desired effect and it is also a lot more flexible than a dedicated tool.

If someone wants to put effort into a specialised tool, maybe it could be a red-eye-removal tool because that is really an often requested feature and it is not easily achievable using a combination of the existing tools.

Sven

Nathan Summers
2006-03-28 16:38:38 UTC (about 18 years ago)

`Bucket fill' ..

On 3/27/06, Sven Neumann wrote:

Hi,

"Gerald Friedland" writes:

True. As long as you have got an appropiate selection too, you could select the object, fill it, and you are done. A "natural" bucket fill would just be a short cut to this process.

Do we really need the overhead in code and complexity to achieve something that can be easily done in two steps? I think that using the selection tools followed by a fill is the natural way to achieve the desired effect and it is also a lot more flexible than a dedicated tool.

Maybe I'm not understanding what's wanted here, but I get the impression that they're talking about a tool that you could use to e.g. change the color of a shirt someone is wearing without loosing the lighting and shading. That would be a pretty cool tool to have, and I can imagine a decent algorithm for doing it, but I can't think of a reasonable way to do it with the existing tools.

If someone wants to put effort into a specialised tool, maybe it could be a red-eye-removal tool because that is really an often requested feature and it is not easily achievable using a combination of the existing tools.

Again, yes, a useful tool. But I think that before we go about making more tools, we finally implement pluggable tools. To avoid the problems we had last time, I suggest that we come up with a sane tool API, implement it in the core, port several tools over to it, and then after it's fairly stable worry about finding a way to do things out-of-process.

Nathan

Sven Neumann
2006-03-28 20:47:46 UTC (about 18 years ago)

`Bucket fill' ..

Hi,

"Nathan Summers" writes:

Maybe I'm not understanding what's wanted here, but I get the impression that they're talking about a tool that you could use to e.g. change the color of a shirt someone is wearing without loosing the lighting and shading. That would be a pretty cool tool to have, and I can imagine a decent algorithm for doing it, but I can't think of a reasonable way to do it with the existing tools.

Select the shirt, then use the Colorize tool on the selection?

Again, yes, a useful tool. But I think that before we go about making more tools, we finally implement pluggable tools. To avoid the problems we had last time, I suggest that we come up with a sane tool API, implement it in the core, port several tools over to it, and then after it's fairly stable worry about finding a way to do things out-of-process.

Coming up with a sane tool API is the hard part. The current core API is far from being sane.

Sven