GNOME Bugzilla – Bug 745360
Feature-Request n-point-deformation tool
Last modified: 2018-05-24 15:04:11 UTC
Actually ( http://comments.gmane.org/gmane.comp.video.gimp.devel/26453 )
the new GSOC 2013 developed n-point-deformation-tool is not in the master branch of 2.9/2.10
Please change that. (Do whatever is neccesary to finish this impressive work.)
That is a really important feature, direct comparing with a very popular tool in photoshop!
(And beside this, it was advertised in public as exemplary Gimp GSOC project. Don't underestimate the impact of dropping it now.)
And last not least, I would really like to use this tool in Gimp 2.10 :-)
Coincidentially, it's happening right now. However I think you will
be slightly disappointed, because it's too slow and unpolished to be
enabled by default, but the code will be in git master.
Any help improving its performance is appreciated.
Thank You for the quick reply.
The help that I can offer is testing the tool in detail on an available windows build and report all my findings to you.
OK, 1. Test works!
(2.9 dev 2015-03-05 on Notebook with Windows Vista 32 bit and integrated Intel graphics)
In my opinion the deformation itself works fast enough (compared with cage transform tool) for production. And the tool does what I expected. Yes!
1.) The (in other tools) usual hints in the statusline would be helpful: like "Hit [Enter] when ready; [Esc] to abort"
2.) After 1. click on the picture to create the mesh, a progressindicator (like in cage transform tool) would be helpful. To inform the user that something is running and that it takes some time - nothing wrong with it!
3.) Only 1 deformation at the same time?
I have opened two different pictures in two tabs to compare working time of mesh creation. Result:
a) Generated mesh in first picture
b) Changed to second picture and generated the mesh.
c) Changed back to first picture: mesh was gone.
But same effekt with cage-transform tool. So it's OK.
The time to create the mesh seems to depend on the size of the opaque object in the layer (not the layer size itself). A small object works faster than a larger one. And a fully opaque layer is the slowest option (OK, and senseless at all). But taken even a midsize object with 1000*300 pix it takes a really long time to create the mesh.
Yes, there is a performance problem.
And now ... I try a completely blind suggestion (which leads possible to a much faster solution ... or not).
I do not know anything about the used algorithm to create the mesh, nor about the programming in Gimp, but I can see the effekt of a created mesh: The whole layer is divided in equal rectangular cells. And each cell with at least 1 opaque pixel within is part of the resulting visible mesh. That means on the other hand, that all cells witch are fully transparent, ... are not. And that is my suggestion: Do not try to find the object/structure in the picture. But delete everything, which is not part of it!
1. Make an invisible grid for the whole layer. A rectangular matrix (e.g. for a 1000*300 pix layer a grid with 100*30 cells, indexed from cell1,1 to cell100,30)
2. Implement a regular double-loop, taking all cells of the matrix, one after the other, and check with the fastest possible algorithm (value addition?) if all pix in the cell (in fact a submatrix) are fully transparent (optimisation: can stop testing the cell after found a pixel that was not).
ToDo: transparence YES = delete the cell from result; NO = cell is part of the resulting mesh.
This is very sad because this tool is awesome, but it can't be released as-is. None wants to tackle the task of working on this? :-)
Gimp 2.9.7 fe3339e215
This tool has a bug when clicking in a layer that it is located > 0, 0. With a layer that it is not at upper left, tool makes a strange behaviour:
- It moves visually the layer to 0, 0 (upper left).
- It creates the mesh in that "visual layer".
- When creating new points and moving them, the points move the mesh where it is, not connected with the mesh... or connected, but "at distance".
Look at the original location of the layer (yellow box), the location of the image and mesh, the point and where, in the mesh, this point deforms.
So sad but I believe this tool won't get out of the playground by the time of 2.10. Pushing it back.
Of course, as always, it may still make it if someone wants to work on it in the next few weeks/months.
Sad to read that. I'm not a developer, I just report bugs... :(
Putting back to 2.10 milestone. We decided to simply put the very import bugs as blockers. Anything non-blocker have simply very few chances to make it unless someone decides to give it an importance (by working on it and providing working patches).
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/649.