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

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

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

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