+- Gimp-Forum.net (https://www.gimp-forum.net)
+-- Forum: GIMP (https://www.gimp-forum.net/Forum-GIMP)
+--- Forum: Extending the GIMP (https://www.gimp-forum.net/Forum-Extending-the-GIMP)
+--- Thread: Path transformations (/Thread-Path-transformations)
RE: Path transformations - Ofnuts - 08-07-2020
For the quadrangle one, it appears to be the same as Gimp's perspective (the basic transforms: rotate, scale, shear, perspective, flip, as well as the Unified transform that combines manyl of them are all affine transforms). Then you shouldn't need to set precision, a property of Bézier curves is that for affine transforms, the transform result of the whole curve is the curve produced by the transform of the four control points (this property is what makes Bézier curves so popular despite other shortcomings).
RE: Path transformations - Ottia Tuota - 08-07-2020
(08-07-2020, 08:23 AM)Ofnuts Wrote: For the quadrangle one, it appears to be the same a Gimp's perspective (the basic transforms: rotate, scale, shear, perspective, flip, as well as the Unified transform that combines manyl of them are all affine transforms). Then you shouldn't need to set precision, a property of Bézier curves is that the transform result of the whole curve is the curve produced by the transform of the four control points (this property is what makes Bézier curves so popular despite other shortcomings).
Excuse me, but from where do you know that those Gimp's tools do affine transformations? I would indeed like to know precisely what they do.
To take the perspective transform tool for example, when I apply it to a path, it shows four corner points and one central point, and by moving those points you change the transformation. That central point makes a translation, that is obvious. But what about the four corner points? Why four? If it were an affine mapping, three points would suffice. Four points are needed to determine a projective mapping.
And there is that 3x3 matrix. (At the upper right corner in the GUI of the perspective tool.) I don't know its function. But I do know that in general such a matrix is associated with any projective transformation, and the transformation is performed by multiplication with the matrix. (More precisely, points in the projective plane are expressed as homogeneous coordinates, and those coordinate vectors are what are multiplied by the matrix.)
If I now just assume that that 3x3 matrix in the GUI indeed is exactly that same matrix that I have learned from general theory (which I don't know, this is just guessing), then: If you move the central point (a translation), then what changes in the matrix are the first and second numbers in the right-most column, nothing else. That is precisely what should happen if the guess about the matrices were right. Now, if you change the four corner points, you see that in the matrix you can change all numbers (except the 1 at bottom right corner). But if the mapping where affine, its bottom row should remain as 0,0,1. But the bottom row changes.
So, I am baffled since I don't know the exact definitions of what the Gimp's transform tools do. Until I know better, I stick to the notion that Gimp's perspective transform and some other tools actually perform projective transformations, and that that 3x3 matrix is the one I learned from general theory. It certainly looks like that.
But: If I were correct (big IF), then I would expect that those Gimp's tools would silently do approximation when dealing with paths. Namely, a projective transformation does not send (polynomial) Bézier curves again onto such curves. And approximation would require(?) generating extra control points in paths, but that does not seem to happen! So, instead of an exact projective transformation, paths are mapped in some other manner? That is ok, but how is the mapping done?
Gimp's online documentation gives no definitions. To add to the confusion, in connection with the transform tool it says: "This tool is not actually a perspective tool, as it doesn't impose perspective rules. It is better described as a distort tool." Without any further explanations.
So, as far as I understand, this all is just guessing until we know precise definitions behind Gimp's tools. Until that, I just keep stumbling along as well as I can according to my best understanding. If you can shed any light here, I would be grateful.
RE: Path transformations - mahvin - 08-07-2020
(08-07-2020, 07:25 AM)Ottia Tuota Wrote: Now a couple of words and two pictures about the two small plugins "Fit a path in a triangle" and "Fit a path in a convex quadrangle". These arouse just as by-products. I have no idea if anybody will find them useful.
The first plugin:
The plugin performs a transformation called dilation to place and fit the given path in the given triangle. Dilation means translation plus scaling. So, no rotation or distortion. This plugin involves no approximation since the mapping is affine, so it can be made just by mapping control points.
The second plugin:
The transformation done here is what mathematicians call a projective transformation. I believe other people coming from different backgrounds may call it a perspective transformation. It is, I believe, almost the same as Gimp's tool perspective transform (but then I don't know what that one actually does).
As you see from the picture, the path is fitted in the given quadrangle, but in the process it is clearly distorted.
Looking at the picture you are likely to notice that the accomplished fitting is not the only possible. An infinite number of different fittings could be done when distortion is allowed. The plugin implements just one particular choice. Imagine the bounding box of the path drawn there; it is that box which is deformed into the shape of the quadrangle, and the path is deformed along with it.
(To make the plugin more general, to allow the user to choose from those infinitely many other possibilities, would mean complicating things again... I might be doing that next.)
Also, when applied to Bézier curves, the latter plugin necessarily does approximation; that is why this plugin offers choice of the algorithm. But please note that the plugin is not perfect and the fitting may not be exact with the default algorithm (=4). You may set the algorithm number higher or set it to 0 (slow). Even then nothing is guaranteed.
<grainofsalt>I've been following this thread with much interest and the first thing that came to mind for me, concerning text is: imagine taking your city skyline silhouette and imposing the city name to it by using one of the above methods or taking like an elephant silhouette and imposing the text "elephant" into the silhouette path. Just two minor examples. These things can be done on their own, individually, certainly. Having a python script would just make it quicker. </grainofsalt>
RE: Path transformations - Ottia Tuota - 08-07-2020
(08-07-2020, 01:55 PM)mahvin Wrote: <grainofsalt>I've been following this thread with much interest and the first thing that came to mind for me, concerning text is: imagine taking your city skyline silhouette and imposing the city name to it by using one of the above methods or taking like an elephant silhouette and imposing the text "elephant" into the silhouette path. Just two minor examples. These things can be done on their own, individually, certainly. Having a python script would just make it quicker. </grainofsalt>
Nice to here that you find my little creations interesting.
But I'm not sure I understand what you have in mind. Wouldn't ofn-bend-path be suitable? It allows long paths with unlimited number of anchors, and it seems to handle text well. And ofn-text-along-path is another. My plugins use as "shapers" only very restricted paths, having only two or four anchors. The effect is different from that given by Ofnut's plugins, though, and perhaps that may have some appeal.
Could you perhaps draw a simple figure showing what you have in mind? I would like to think about it though I cannot promise it will lead to anything.
RE: Path transformations - mahvin - 08-07-2020
It's not critical. Now that I understand the complexity of having very few anchors in use, that throws out my idea, entirely.
RE: Path transformations - Ottia Tuota - 08-07-2020
(08-07-2020, 07:56 PM)mahvin Wrote: It's not critical. Now that I understand the complexity of having very few anchors in use, that throws out my idea, entirely.
Ok. The restriction is unfortunate but it comes from the very ideas behind the plugins.
RE: Path transformations - Ofnuts - 08-08-2020
(08-07-2020, 12:06 PM)Ottia Tuota Wrote:(08-07-2020, 08:23 AM)Ofnuts Wrote: For the quadrangle one, it appears to be the same a Gimp's perspective (the basic transforms: rotate, scale, shear, perspective, flip, as well as the Unified transform that combines manyl of them are all affine transforms). Then you shouldn't need to set precision, a property of Bézier curves is that the transform result of the whole curve is the curve produced by the transform of the four control points (this property is what makes Bézier curves so popular despite other shortcomings).
Excuse me, but from where do you know that those Gimp's tools do affine transformations? I would indeed like to know precisely what they do.
To take the perspective transform tool for example, when I apply it to a path, it shows four corner points and one central point, and by moving those points you change the transformation. That central point makes a translation, that is obvious. But what about the four corner points? Why four? If it were an affine mapping, three points would suffice. Four points are needed to determine a projective mapping.
And there is that 3x3 matrix. (At the upper right corner in the GUI of the perspective tool.) I don't know its function. But I do know that in general such a matrix is associated with any projective transformation, and the transformation is performed by multiplication with the matrix. (More precisely, points in the projective plane are expressed as homogeneous coordinates, and those coordinate vectors are what are multiplied by the matrix.)
If I now just assume that that 3x3 matrix in the GUI indeed is exactly that same matrix that I have learned from general theory (which I don't know, this is just guessing), then: If you move the central point (a translation), then what changes in the matrix are the first and second numbers in the right-most column, nothing else. That is precisely what should happen if the guess about the matrices were right. Now, if you change the four corner points, you see that in the matrix you can change all numbers (except the 1 at bottom right corner). But if the mapping where affine, its bottom row should remain as 0,0,1. But the bottom row changes.
So, I am baffled since I don't know the exact definitions of what the Gimp's transform tools do. Until I know better, I stick to the notion that Gimp's perspective transform and some other tools actually perform projective transformations, and that that 3x3 matrix is the one I learned from general theory. It certainly looks like that.
But: If I were correct (big IF), then I would expect that those Gimp's tools would silently do approximation when dealing with paths. Namely, a projective transformation does not send (polynomial) Bézier curves again onto such curves. And approximation would require(?) generating extra control points in paths, but that does not seem to happen! So, instead of an exact projective transformation, paths are mapped in some other manner? That is ok, but how is the mapping done?
Gimp's online documentation gives no definitions. To add to the confusion, in connection with the transform tool it says: "This tool is not actually a perspective tool, as it doesn't impose perspective rules. It is better described as a distort tool." Without any further explanations.
So, as far as I understand, this all is just guessing until we know precise definitions behind Gimp's tools. Until that, I just keep stumbling along as well as I can according to my best understanding. If you can shed any light here, I would be grateful.
OK, so I was wrong... OTOH as far as my tests go:
- There are indeed cases where the transform of the rendered path is not the rendering of the transformed path, so in all likelihood there is no code to increase the accuracy of the path (and the transformed path has the same number of control points as its source).
[attachment=4728]
(black: transform of rendered path, red: path from transformed control points)
- Still, in most cases (and in particular when the path has been obtained from text), the transform of the rendered path is darn close to the rendering of the transformed path (and in the example below, the font has been picked for not having too many control points, many fonts have many more control points per characters):
[attachment=4729]
(green: transformed text, red: path from transformed text path)
RE: Path transformations - Ottia Tuota - 08-08-2020
So, I guess that we have to content ourselves with that we don't know exactly. So, I keep making my plugins by my own ideas. Then at least I know what I am doing (most of the time at least, being optimistic here!).
RE: Path transformations - Ottia Tuota - 08-11-2020
(08-07-2020, 07:25 AM)Ottia Tuota Wrote: Looking at the picture you are likely to notice that the accomplished fitting is not the only possible. An infinite number of different fittings could be done when distortion is allowed. The plugin implements just one particular choice. Imagine the bounding box of the path drawn there; it is that box which is deformed into the shape of the quadrangle, and the path is deformed along with it.
(To make the plugin more general, to allow the user to choose from those infinitely many other possibilities, would mean complicating things again... I might be doing that next.)
That is what I said post #20. I have now indeed implemented a way to realize those infinitely many possibilities. The new version is 0.20 (see post #1 for how to get it). No other changes (except for a couple bug fixes).
Now the plugin asks for a reference box. The default is the bounding box of the source path, and you can apply that without any further trouble - just use the default and you get the same result as from the older version. But now there is another option: You can draw a quadrangle roughly around the source path and feed that to the plugin to be used as the reference box:
[attachment=4735]
What is happening here is: Imagine in that picture that you translate each of those four edges of the reference box a little to be a precise tangent of the path. This gives a box of four tangents (only imagined, you need not try to create those tangents). That imagined tangent box is sent onto the target quadrangle by a projective transformation, and the source path is transformed along with it.
(The "tangents" need not really be tangents if the source path has cusps or such, but the idea is the same. I use the word tangent just for simplicity.)
This enables you to control which points of the source path are sent onto the edges of the target quadrangle.
One fact may cause surprises: The plugin has now two quadrangles, the reference box and the target quadrangle, and to perform the transformation of the former onto the latter it has to decide which edge to map onto which edge. It does this by deciding which edges are lowest on the screen and matches those. For this it has its own algorithm, and the result may not always be what you would expect.
Of the reference box the precise locations of the edges is not so relevant, only their directions. So, there is some freedom to change the box in case of such surprises.
Please report if the plugin works strangely or fails altogether.
RE: Path transformations - Ottia Tuota - 09-03-2020
The newest version is 0.22. For how to get it, see post #1. There is one new plugin. It converts a path to polar coordinates. It is supposed to imitate Gimp's filter Filters > Distorts > Polar coordinates. But this plugin distorts paths, not images, and options are different. The inputs are:
- Choose which edge is mapped to the middle. Gimp's filter offers two choices: top or bottom. The plugin offers four: top, bottom, left, right. These refer to the edges of the Reference box (see below). Default is "top".
- Central angle. Default is 360 (degrees), which causes the path to be wound to a full circle. This is the same behaviour as in Gimp's filter. But the plugin allows you to choose some different (smaller) angle, and instead of a full circle you get a circle sector.
- Reference box. Gimp's filter uses always the whole window. In the plugin the default is the bounding box of the source path. Let us call it BB. You can imagine BB to be somehow "the window of the path", and with this choice the effect will indeed be similar to that of the filter. But the plugin allows other choices with different effects.
- Algorithm. Choose the best but slow one, or a quick one which creates lots of control points and is possibly inaccurate.
Pictures: The first shows the effect of the central angle. Here the angle is 360, 270, 180, 90 degrees. All other inputs are defaults (Top, BB).
[attachment=4846]
The second picture shows the effect of the choice of the edge (top, bottom, left, right) of the Reference box. In the picture I used central angle=270 since I think it makes the effect clearer. The Reference box is BB:
[attachment=4847]
For example, in the "Top" case happens: The top edge goes to the middle point. (Indeed, the whole edge goes to one point!) The bottom edge goes to the outer circular arc. The left and right side edges go to the two straight edges emanating from the middle point.
The third picture tries to show what may happen when the Reference box does not coincide with the BB of the path. The inputs are defaults except for the Reference box. Let us call RB = the Reference box, and BB = the bounding box of the source path. (In the picture "Box" means RB.) Since I use the option "Top to middle", the top edge of RB is sent to the middle point. The source path is the grid, and its BB equals its outer boundary. The first case in the picture is the same which already appeared. There RB equals BB, hence also the top edge of BB goes to one point (the middle point).
[attachment=4848]
The other cases in this picture are created with RB changed so that its top edge is moved higher, and higher, and higher, and higher. You can think that RB equals otherwise the outer boundary of the grid except that its top edge is moved ever higher. Then the top edge of RB differs from the top edge of BB. The top edge of RB goes again to one point, but now the top edge of BB differs from it, so the latter does not go to one point. Instead, it goes to a small circle around the middle point. The result is that an empty circle emerges at the center, and it becomes the larger the greater the discrepancy is between the top edges of RB and of BB. (To make these examples I used the option to take the Reference box from guides.)
Finally, some plays using default inputs (except that algorithm=0):
[attachment=4849]
An interesting fact: Simplifying matters a little, we can say that when we use the option "Top to middle", the mapping is essentially (x,y) -> y(cos(x),sin(x)) (cartesian coordinates are interpreted as polar coordinates). Then:
- vertical lines are mapped onto straight lines passing through the middle point;
- horizontal lines are mapped onto circles centered at the middle point;
- all other straight lines are mapped onto Archimedean spirals.