Version: (using KDE Devel) Installed from: Compiled sources Image warping similar to the GIMP's iwarp plugin and made famous by tools like kai's power goo can be really useful for many things. They're often a pain to use because once you've done them, the only tools you get to alter them are, if you're lucky, undo and redo. So the way I have always wanted to see this implemented is having a 'warp layer' which dynamically warps image data underneath it. On the warp layer you would be able to place and move 'warp objects' which would pinch, punch, spin, shift (etc.) the underneath image. Mathematically, this would be quite a simple concept. It would just require a bit of vector calculus. All of these operations are representable mathematically by divergence, gradient, curl, laplacian (etc.) and the warp layer would simply be a(n analytical) vector field mapping one space to another based on summing the effect of the warp objects. As with most of my mad ideas, the real issue would be speed. Doing all these lookups for each pixel is not a fast thing. Reevaluation occurring every time any of the underlying data were edited would definitely not be a fast thing. Add to that the fact that to get pleasing output, you would have to do some kind of supersampling. But perhaps someone else can see a way of mitigating these problems, so I thought it would be worth mentioning how, as a user, in an ideal world, I would like to see this handled.
* speed: I don't think it would be that time consuming. After all you only need to update a small part of your image. * drawing: like "transformation effects layer" (which doesn't exist yet) the main issue when drawing is that if you draw on some part of the image, it might be (and it will be) confusing for the user to move the mouse on some part of the image and then the actual drawing appears somewhere else The most complex part is to compute what part of your image really needs to be updated.
"the main issue when drawing is that if you draw on some part of the image, it might be (and it will be) confusing for the user to move the mouse on some part of the image and then the actual drawing appears somewhere else" I think this is just a compounding of the problem I have when working with several layers with masks and different blending modes etc. You can't quite figure out why your paint isn't showing up and it turns out you weren't painting where you thought you were. That could be maybe helped if a layer's entry in the layers list 'pulsed' all the time it was being written to. But I don't know if that would give enough of a hint as to why your paint is showing up 'over there' instead of 'over here'. It would just alert you to the fact that you're painting to a layer beneath the warp layer "The most complex part is to compute what part of your image really needs to be updated." Assuming you use rectangular QRegion-like dirty areas, then it would be a horrible non-Euclidean geometry problem. Fun.
Well I would hate something that pulse ;) I find myself to close website with an advertisement that pulse. But that's a little bit offtopic here ;) It wasn't really the "on which layer I am painting" problem I was thinking about. But rather where on the layer and end results. With no "adjustment layer", when I draw on the layer I draw exactly where the mouse is. But with a "wrap adjustment layer", if I draw on the pixel (10x10), it's indeed changing the value of the (10x10) pixel but due to the adjustment layer, what I see is that pixel (42x42) is changing.
Yes, I understand that, but the key to making it clear why paint is ending up in 'the wrong place' is making it clear that you're painting underneath a warp layer. It's all too common to not pay attention to what layer you're painting on. Perhaps the answer would be to send the painting operations through the inverse mapping when writing to a layer beneath an enabled warp layer, so that it seemed like you were painting on a plain geometry, whilst in fact, the underlying image layer were receiving an inverse warped version of your painting. Perhaps that would be more confusing in the long run. Perhaps either mode could be selectable.
Just want to share you that I'm developing deform brush, that is quite close to Gimp's iwarp filter. It is already in svn, but you have to enable in manually to compile.
Now that I think of this. It would be probably best done with "editable" pathes. We have on our TODO to have path that can be changed after creation, to which you can associate a painting operation. So basically, if the Lukas's deform tool is associated to such a path, then we get editable image warping in a similar way to what an adjustement layer would do.
*** Bug 332054 has been marked as a duplicate of this bug. ***
An adjustment layer for warp and transform will make the clone layers and file layers usage explode as they could be a lot more versatile than they are today.
Dmitry implemented transform masks -- yay!