Re: [Gimp-developer] IWarp as a tool
On Feb 17, 2008 5:07 PM, Tor Lillqvist <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
> 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 ? After "Do it", yes, definitely. But before, that is a tough question. In my first patch (which is not good), each stroke is undoable, but then it works in a different way. If implemented to work in the style of the transform tools, the strokes won't be undoable as such, any more than you can undo each incremental rotation "nudge" in the rotation tool while you are tweaking looking for the right rotation, for instance. Which is sad, true. 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. 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. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
On Feb 17, 2008 9:18 AM, Tor Lillqvist <[EMAIL PROTECTED]> 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 :-)
--
Laxminarayan Kamath Ammembal
(+91) 9945036093
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
On 16/02/2008, Sven Neumann <[EMAIL PROTECTED]> wrote: > No, the tool class shouldn't do anything but providing the user interface. I now realize that the non-GUI code for a warp tool does not need to be very interesting or complicated. One could maybe even just use the existing displace plug-in for the non-GUI code. The only problem, if it is a problem, with the displace plug-in is a matter of precision, as it uses just signed bytes for the X and Y displacement, and IWarp uses doubles. It's the GUI part that has to do all the "interesting" stuff, collecting separate strokes and build up a deformation vector array, i.e. displacement map. 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?) So a more or less complete redesign of my current patch is indeed needed. (But that's what I was expecting anyway.) On 17/02/2008, Bill Skaggs <[EMAIL PROTECTED]> wrote: > I have doubts that the Warp tool should be a paint tool at all -- it > certainly doesn't use a brush. Yes. I thought long about this for a long time back and forth, and I had to at least actually get something done that works in some way, if only to get visual proof that it is the wrong approach... > Multiple strokes are always treated incrementally, though. That is a problem. But as I said above, a complete redesign is needed anyway, and if the warp tool is implemented more in the style of the transform tool, this shouldn't be a problem. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
On Feb 16, 2008 2:08 PM, Tor Lillqvist <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
> 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(). But isn't each stroke with a tool a separate GimpPaintCore object? In 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? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
> 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. It does produce a significantly different result. In my current code, there is interpolation upon interpolation when calculating the new pixels as the stroke proceeds, and the affected area gets more and more blurred. In IWarp, even when updating the preview while stroking, it is just one interpolation away from the original (scaled) preview pixels. > 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.) That sounds promising indeed. I do wish that there was some technical documentation on how this all hangs together. Just trying to understand by reading the code is a bit hard. When you say "tool", you mean an object of a subclass of GimpTool, right, not an object of a subclass of GimpPaintCore? That is one thing that was a unclear to me, what is the proper division of tasks between a GimpTool and a GimpPaintCore? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
On Fri, Feb 15, 2008 at 2:57 AM, Tor Lillqvist <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
On Fri, Feb 15, 2008 at 10:57 AM, Tor Lillqvist <[EMAIL PROTECTED]> 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. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
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. Basically, when using the IWarp filter, and manipulating the preview in its dialog, IWarp all the time has access to the complete original drawable (well, it uses a preview-sized scaled version of it). Also, the deformation vector array is built up and modified by each stroke in the preview, and not re-initialized between strokes. The displayed result preview is continuously based on pixels fetched from the original drawable, not from the already warped preview. In my current warp tool, on the other hand, each stroke (i.e. invocation of a GimpWarp object, a subclass of GimpPaintCore) is independent and reinitialises the deformation vector array. Also, it continuously modifies the drawable being painted on from itself to itself, if you understand what I think I mean... 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? Ditto for a copy of the original drawable. But when should this state then be discarded? 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? 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? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
On Thu, Feb 14, 2008 at 11:15 AM, Liam R E Quin <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
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 -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
