After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 385239 - Image manipulation using Bezier Paths
Image manipulation using Bezier Paths
Status: RESOLVED DUPLICATE of bug 138462
Product: GIMP
Classification: Other
Component: Tools
unspecified
Other Windows
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2006-12-12 22:40 UTC by Josh Mathis
Modified: 2006-12-14 07:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Josh Mathis 2006-12-12 22:40:10 UTC
This is an idea that I've had for a little while, trying to find a way to let the right people know is a whole other issue.

The concept is very simple.

First, you take a Bezier Path and position it on your picture. It can be straight or curved. The next step, when you get it how you want is to lock it to the image (or layer). The final step would be manipulating the Bezier Path. This could be as simple as dragging the anchors around.

The complicated part is deciding just how the pixels around the path are affected. There are going to be some times when you don't want very much distortion, yet there will have to be some "streching" and "compressing" of the pixels. How that gets done and how far away from the path it gets done is a major consideration.

So, you want some examples of how it could work in real life . . .

1. You have a wide angle picture that is distorted big time. Maybe it's a fish-eye lens. If you have anything that you know should be straight such as a tree or a tall building (preferable one on either side of the picture, then you would build two paths. Just follow the curve of the building or the tree. The next step would be to "link" or anchor the path to the picture. After that it could be as simple as clicking a button that straightens the path between the endpoints. 

If it looks good you could save those paths to a file and "fix" any fisheye pictures by importing those curved paths and straightening them.


2. You have a panorama that you are trying to put together from multiple, overlapping pictures. In the process you find a spot on the horizon that just won't line up by using the other gimp tools. Take a Bezier Path and build it so that it lines up on the horizon that is out of whack. Once you have the path built, anchor it to that layer. Then drag the anchors so that it matches up with the other horizon.


I have personally had many times when I have needed to tweek a picture just a bit. There is no other tool that I know of that would have the versatility to manipulate the image like the tool I am trying to describe.

I unfortunately am just an end user. I don't know where to begin to even dream of doing this on my own. And I know that it won't be simple to implement. In fact, deciding how the image close to the path acts in contrast to how the pixels away from the path act will be critical. Being able to decide just how much distortion is allowed and how far away the path actually affects the pixels is something that should be allowed to be decided by the user.
Comment 1 Sven Neumann 2006-12-12 23:02:14 UTC
We all are full of ideas. I don't think it helps if we all file them as enhancement requests in this bug tracker. An enhancement request should at least try to outline a possible implementation. Did you do some research on this? Have you looked at free panorama and stitching tools? What about software or algorithms for lens correction?

GIMP is rather short on active developers and we have a hard time keeping up with bug reports. I really don't know what to do with this one. You did a good job at specifying your wishes. But it would have helped more if you had done that on the mailing list where you have a larger audience and thus a better chance of raising someone's interest in implementing something like this.
Comment 2 Josh Mathis 2006-12-13 02:20:58 UTC
(In reply to comment #1)
> We all are full of ideas. I don't think it helps if we all file them as
> enhancement requests in this bug tracker. An enhancement request should at
> least try to outline a possible implementation. Did you do some research on
> this? Have you looked at free panorama and stitching tools? What about software
> or algorithms for lens correction?
> 
> GIMP is rather short on active developers and we have a hard time keeping up
> with bug reports. I really don't know what to do with this one. You did a good
> job at specifying your wishes. But it would have helped more if you had done
> that on the mailing list where you have a larger audience and thus a better
> chance of raising someone's interest in implementing something like this.
> 


I know that I can't come close in implementing this idea. I believe that I did mention that I knew that this wasn't the place for submitting this idea. I was merely hoping that someone could point me in the right direction as to where to submit the idea. Who knows, maybe someone will understand it and know how to implement it, and thereby make GIMP just a little bit better.

I have looked at panorama and stitching tools and I have paid some good money for them. However, they do not let the user have the complete versatility that this tool would.

I am not very good at math so I know that I want to stay way far away from algorithms and the like. I wouldn't even know how to implement them.

No I have not looked at software for lens correction. Lens correction is just one small function of what this tool could be.

So, in saying all that. I'm sorry I bogged down your bug server. Where do I find the mailing list so that I can post this there?

Josh
Comment 3 Sven Neumann 2006-12-13 08:08:17 UTC

*** This bug has been marked as a duplicate of 138462 ***
Comment 4 david gowers 2006-12-14 03:56:34 UTC
If the path was single component and convex, this might be doable by chopping up the src and dest areas into an equal amount of 2d polygons, then mapping src->dest. If Perspective were better behaved, it could be used as a backend; but currently it fails when two points are very close together or angles are particularly acute.

In any case, this bug is not a duplicate of bug #138462. #138462 is about a set of functionality comparable to that of Inkscape's transformation facilities.
This bug report is more apropos to morphing than simple transformation.
Comment 5 Sven Neumann 2006-12-14 07:03:18 UTC
I know, but bug #138462 comes closest and is more likely to ever get implemented.