Hi,

On Wed, 2008-02-13 at 02:06 +0200, Tor Lillqvist wrote:

Currently it allocates a big buffer for the deformation vectors, two doubles for each pixel in the image. This should probably be changed to either use tile-based storage, or use a scaled (when necessary) deformation vector array with some fixed maximum size.

You should be able to use a tile-manager for this. A tile-manager can hold any number of bytes per pixel. There is one tool already that does something like this, the IScissors tool. It even does something particularily elegant in that it uses a validate_proc so that only the tiles that are actually needed by the tool are calculated.

Sven

On Wed, 2008-02-13 at 02:06 +0200, Tor Lillqvist wrote: [...]

Is it conceivable to have a Filter Brush that takes any filter, ala krita?

Liam

On Thu, Feb 14, 2008 at 11:15 AM, Liam R E Quin wrote:

Is it conceivable to have a Filter Brush that takes any filter, ala krita?

This has nothing to do with a Warp tool, really (because a Warp tool doesn't use a brush), but the answer is yes, it is very conceivable.

I would be interested in getting opinions on some of the open questions about how such a tool should work. Here are some of the questions:

1) How should a filter-brush handle the settings for the filter? Should it run the filter's dialog when activated in order to get settings, or have a button to run the dialog, or use the default settings, or the last settings used, or what?

2) Should a filter brush, in effect, apply the filter to the drawable, and then clone from the result at each stroke? Or should it reapply the filter after each brush stroke? Or after each brush mark? Or should this be an option?

In any case, applying a filter with a brush is basically a fancy kind of cloning, so there is nothing intrinsically all that difficult about it. There would probably need to be a bit of new machinery, such as a mechanism for distinguishing "paintable" filters, and a way to run a plug-in in "dry-run" mode -- so that it sets up parameters but does not actually alter the image -- but nothing incredibly challenging.

-- Bill

On Fri, Feb 15, 2008 at 10:57 AM, Tor Lillqvist wrote:

snip<

Hopefully this is a question with an obvious answer, and there is some tool that already works like this...

Or is it really so that a warp tool, and the "filter brush" kinds of tools that Ankh asks for, and all other nice cool things will need to wait for a complete geglification?

At least when it comes to doing such a warp tool, after a complete GEGLification this would be seen as a nondestructive editing operations that warps the image. By using specialised paint tools when the iwarp effect layer is selected, the painting would be affecting the deformation masks, the deformation masks would be stored with the the iwarp effect layer.

For such an iwarp effect, as well as for most other effect layers like unsharp masking, gaussian blurring etc. The way to discard the state would be to "merge down" the effect into the original drawable thus losing the non-destructive ness of it.

/Øyvind K.

On Fri, Feb 15, 2008 at 2:57 AM, Tor Lillqvist wrote:

Unfortunately now that I have had time to think a bit harder, I understand that there is a fundamental difference in how my initial effort to implement a warp tool works compared to how the IWarp filter does.

Do you really need to do it exactly the way the filter does it?

From your description, I don't really understand why your

current approach is less valid, or even why it will produce a significantly different result. (The filter needs to do it that way because it doesn't act on the image until the user has finished working with the preview, but that logic doesn't apply to your tool.)

Can a GimpWarpTool object know when some other tool or filter is being used on the drawable, and thus the warping data for that drawable should be discarded?

Yes, many tools face this problem, and the system is set up so that tools are automatically halted if a drawable is dirtied while a tool is active. (More precisely, while tool_control is active.) Even tools themselves must take measures to keep from being halted when they make changes to the image: they do this by calling gimp_tool_control_set_preserve() before making a change.

-- Bill

Hi,

On Fri, 2008-02-15 at 20:43 +0200, Tor Lillqvist wrote:

what is the proper division of tasks between a GimpTool and a GimpPaintCore?

A GimpPaintCore is an object used by paint tools. It does the actual painting and it is also used when the painting is done by means of a PDB call.

A GimpTool object should not have any functionality besides providing the user interface for a specific tool. Everything else needs to live outside the tool object.

Sven

Hi,

On Fri, 2008-02-15 at 12:57 +0200, Tor Lillqvist wrote:

So, how to solve this? Should the bookeeping of deformation vectors be done per-drawawble by the GimpWarpTool object (a subclass of GimpPaintTool) and not GimpWarp object?

No, the tool class shouldn't do anything but providing the user interface.

Ditto for a copy of the original drawable.

You don't need to allocate such a copy as it is already allocated for you by means of the undo tile-manager. If you need access to the original drawable, just read from the undo tiles. If your warp object is a GimpPaintCore, then you can just use gimp_paint_core_get_orig_image().

Sven

On Feb 16, 2008 2:08 PM, Tor Lillqvist wrote:

But isn't each stroke with a tool a separate GimpPaintCore object?

No, a GimpPaintCore is basically an object that creates brush-marks. A paint tool creates its paint core when it comes into existence, and uses the paint core as long as it exists.

I have doubts that the Warp tool should be a paint tool at all -- it certainly doesn't use a brush. When I was thinking about this, I imagined that the tool would inherit directly from GimpDrawTool, or maybe even from GimpTool, with the code that actually does the warping in a file gimpdrawable-warp.c in app/core.

Anyway, the paint tool that has most in common with a warp tool would probably be the ink tool, because it also does not use a brush. The brush tools have a lot of specialized code for brush-handling that wouldn't be of any use to you.

the warp tool's case, I would like sequential strokes to have access to the same original image, the one before the first stroke. Is there any existing infrastructure to do this, or would the warp tool code need to manage such bookkeeping itself?

For paint tools (the ones that use a brush), there is a distinction between "incremental" mode and "non-incremental" mode. In incremental mode (as used by the airbrush), each brush mark is added to the image that results from the previous brush marks. In non-incremental mode (as used by the simple paintbrush), all of the brush-marks from a stroke are in effect applied at once to the image as it existed before the stroke. So, in non-incremental mode, going back and forth over the same area in a single stroke does not produce a cumulative result. Multiple strokes are always treated incrementally, though. So, you might look at how this is handled in the paint core code.

-- Bill

On Feb 17, 2008 9:18 AM, Tor Lillqvist wrote:

I guess, in a way the warp tool should be like the transform (rotate/perspective/shear) tools. While interacting with it a preview is shown. Separate mouse drags are incremental, and just add to the in-progress build-up of data for the warp. Only when the user is satisfied and explicitly chooses some "Do it" action, does the actual warping take place. (Or would it be possibly to do it implicitly when the user switches tools?)

Will we be able to do "undo" *between* the strokes ? * before "Do it"?
* after "Do it" ? In other words, will the undo stack be updated after each stroke ?

As a slightly off-topic idea , How is the idea of having an in-transformation undo-stack ? This will also help in transformation and other "Do-it" style operations like brightess contrast, levels, etc. The "Reset" button can be replaced" by "|< < > >|" buttons. and "{ [ ] }" can be used as keyboard shortcuts.

Whups.. Got carried away :-)

Hi,

On Sat, 2008-02-16 at 17:29 -0800, Bill Skaggs wrote:

I have doubts that the Warp tool should be a paint tool at all -- it certainly doesn't use a brush.

If it doesn't use a brush, then it is not a GimpBrushTool. It can still, and probably even should, be a GimpPaintTool.

Sven

On Feb 17, 2008 5:07 PM, Tor Lillqvist wrote:

Perhaps for the rotation tool it doesn't mean much, but at least for the perspective tool it would be nice if one could undo the incremental changes one does to the control points. Probably this wouldn't be hard to implement? I doubt the normal undo mechanism could be used, though, the transform tool would have to implement and own simple undo mechanism.

I would suggest getting the functionality first, and worrying about undo later. My experience is that the Gimp undo system is pretty well designed, and can handle most of the tasks that you would want to give it.

For a warp tool working in the style of the transform tool, the amount of state is much larger, and implementing an own undo mechanism for it does not necessarily sound like a good idea.

Having each tool implement its own kind of internal undo is a nightmare for maintenance.

-- Bill