Re: [Gimp-developer] GSOC - Free Transform Tool

2010-04-10 Thread peter sikking
Stephen McKeague wrote:

 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,

good point, undo in steps during the use of the tool is on the menu.
this may be aggregated for undo too after the tool is left.

 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?

well, this needs UI spec work, for these (valid) edge cases, but that  
needs
to have context of users (when the intent is there) working at a  
magnification
that is workable. but this is hard thinking work and TBD.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GSOC - Free Transform Tool

2010-04-09 Thread Stephen McKeague




 From: pe...@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. 
  
_
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now
http://clk.atdmt.com/UKM/go/195013117/direct/01/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GSOC - Free Transform Tool

2010-03-29 Thread peter sikking
Stephen McKeague wrote:

 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.

with the size calculations I meant the calculation of all the  
handles for
manipulating the frame are done according to how big the transformation
frame is on-screen.

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.

 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.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GSOC - Free Transform Tool

2010-03-28 Thread peter sikking
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:
http://209.85.135.132/search?q=cache:5vLW1Vm8rQIJ:gui.gimp.org/index.php/Transformation_tool_specification
 
 

however, last week I have updated the design of the shear and  
perspective
transform handles and all opcities:
http://mmiworks.net/test/no%20parallel.png and
http://mmiworks.net/test/no%20parallel.jpg

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.

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.

 --ps

 founder + principal interaction architect
 man + machine interface works

 http://mmiworks.net/blog : on interaction architecture



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GSOC - Free Transform Tool

2010-03-28 Thread Stephen McKeague




 From: pe...@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 
_
Do you have a story that started on Hotmail? Tell us now
http://clk.atdmt.com/UKM/go/195013117/direct/01/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] GSOC - Free Transform Tool

2010-03-27 Thread Stephen McKeague

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  
_
Do you have a story that started on Hotmail? Tell us now
http://clk.atdmt.com/UKM/go/195013117/direct/01/___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer