Hello
My name is Stephen McKeague and I am very interested in implementing the Free Transform Tool in GIMP for this years Google Summer of Code, originally proposed by Martin Nordholts. The project information page seems to still be offline, so I would like to discuss the bounds of the project. Since the functionality is obviously in place for rotate, scale sheer and perspective separately, they could be combined in a Photoshop like fashion for the Free Transform Tool, presumably using shortcut keys to specify the details of the required transform. Since the GUI would have to be amended to include the new tool, would it be a good idea to have the icons for both a Free Transform and the existing separate transforms beside each other? This would possibly result in too much feature duplication but I would like to hear your thoughts on the matter along with anything else relating to the project.

I am starting a Ph.D. in Computer Vision this October at Imperial College London. I feel that I would be able to contribute a lot to this project and would love to use the experience gained through it to continue developing GIMP as a regular contributor.

Thank you very much for your time Stephen McKeague
__________________

----------------------------------------

From: peter@mmiworks.net
To: gimp-developer@lists.XCF.Berkeley.EDU Date: Sun, 28 Mar 2010 17:01:12 +0200 Subject: Re: [Gimp-developer] GSOC - Free Transform Tool

Stephen McKeague wrote:

My name is Stephen McKeague and I am very interested in implementing the Free Transform Tool in GIMP for this years Google Summer of Code, originally proposed by Martin Nordholts. The project information page seems to still be offline, so I would like to discuss the bounds of the project.

yes, it would give you quite a complete overview of how I see that tool working,
I hope the site can be up soon.

meanwhile, try this google cache:  

however, last week I have updated the design of the shear and perspective
transform handles and all opcities:

looks really good, I love the idea

 and
 
 
this of course triggers a big update of the spec. there are also some rough edges in the spec that need to be defined: like when the frame is partially in view, or no edge of the frame is in view.

On this note, could you please clarify for me where it says, "Only the visible part of the transform frame goes into the size calculations".  I know the selection tool would used to define the desired area for transform but what significance would the local zoom level (for example) hold? Surely if all parts of the user selected area were not subject to the same transformation it would seem inconsistent (or did I not understand what you were trying to say)? Also, can you please confirm why the transformation tool would only perform the calculation when the user "goes and does something else".  I understand the angle of the tool processing an "aggregate transformation", but the intro specifies that "we try to enable a positive feedback loop where the result of the last transformation input inspires the next few steps".  Enhancing the "feeling" nature of the transformation, I took this to mean that the user should see the result of one stage of the free transform tool (e.g. an initial scale) before applying a further stage (e.g. a further rotate).  Am I correct?

btw: getting the opacity part working may need some serious grunt work. ask the developers about it.

Since the functionality is obviously in place for rotate, scale sheer and perspective separately, they could be combined in a Photoshop like fashion for the Free Transform Tool, presumably using shortcut keys to specify the details of the required transform.

The new transform tool is indeed a combined transform tool: move, rotate,
scale, shear, perspective.

Since the GUI would have to be amended to include the new tool, would it be a good idea to have the icons for both a Free Transform and the existing separate transforms beside each other? This would possibly result in too much feature duplication but I would like to hear your thoughts on the matter along with anything else relating to the project.

see my intro in the spec. but the short version is: the combined tool is "to supersede the move, scale and shear tools" and should be complemented
by expert rotate and perspective tools. the flip tool is a goner.

I was going to suggest replacing that :-)

Thanks a lot for the inputStephen __________________

----------------------------------------

From: peter@mmiworks.net
To: gimp-developer@lists.XCF.Berkeley.EDU Date: Mon, 29 Mar 2010 15:37:42 +0200 Subject: Re: [Gimp-developer] GSOC - Free Transform Tool

what needs sorting out is that after some manipulation the transformation
frame can be any kind of shape that can be made out of 4 corners connected
by 4 straight lines, including a twisted bow tie type of shape.

this general shape is then clipped by the viewport of the image window, which is really a rectangle. This clipped general shape then needs to be manipulated. I still have to investigate what is reasonable for users to be able to do in these situations and how I can make this happen.

Yeah, after a perspective change of close to 90deg in any one direction - even if this was actually a mistake - the frame will be rendered unusable because of the low resolution between the different handles.  Given that currently you will not be able to undo just part of the overall Free Transform, this will pose a problem (Large shears will exhibit the same behaviour).  One possible solution would be that transform frame would only mirror the actual transformation up to a certain threshold.  Otherwise the decision could be left to the user to accept (or undo) the current transformation and start a new free transform (and thus new transformation frame).  Any update on your thoughts on this?  >> Also, can you please confirm why the transformation tool would only

perform the calculation when the user "goes and does something else".

yeah that passage is not clear. what I mean is that what is manipulated on-screen is just a preview of the real image data: it is just a limited amount of pixels (there are only 1 to 2 Mpix on a monitor) and it will, using all the dirty tricks in the world, 'instantly' reflect the transformation made by users using the handles. even while moving the handles.

the real transformation of the real pixels in memory is then done with the aggregate transformation in one pass when "users go and do something else."
this is the "maximum fidelity contract" with users.

Cool, this will allow us to combine adjacent affine transformations at the end of the tool's usage to reduce the computational expense of the operations. 
__________________