Feature request - new Transform tool

[hedles]

Background and reason for request:

I frequently find myself 'stitching' together parts of a picture that I cannot scan in one operation on my scanner. It often takes 'forever' to align a new part of the picture to the growing montage.

The technique I use is to add the new part of the picture as a new layer, adjust its opacity so that I can see through to the layer below, then keep making successive trial/partial adjustments (Shifts (move selected pixels), and Rotations (Layer Rotate/Zoom) and sometimes also scalings) until I achieve an alignment that I am happy with, before re-maximising the opacity, possibly trimming off part of the overlaps and then merging the new layer down to the existing picture.

If there is a better/quicker technique for achieving this then I would welcome enlightenment!

If it were possible to adjust the position (and possibly scale) of a layer/selection by selecting pairs of locations - first the source pixel to be moved, followed by its destination - then having the program perform this in one operation without having to drag or step (with the arrow keys) the layer/selection, it would enormously speed the desired transform.

Failing that, or anyway . . .

My suggestion is for a new Transform Tool that works as follows:

1. With a selection (which might be a whole layer), choose the Transform Tool.

A small dialogue box appears labelled "Transform" with a "Transform" button and a "Cancel" button.

2. Depressing the Ctrl key the user clicks on the first source pixel, which is then highlighted by a nub.

(The source nub can be relocated at this point, by repeating the operation.)

3. Depressing the Alt key the user clicks on the destination for the first pixel which is then highlighted by a second nub.

(The destination nub can be moved at this point, by repeating the operation.)

An arrow appears between the two nubs representing the vector from the source pixel to its destination.

(At any point after an arrow has appeared, it can be

a. moved (without change of orientation) by

i dragging it from between the nubs, or

ii selecting it with a left (double?)-click and using the arrow keys to move it one pixel at time;

b. adjusted by

i dragging either of the nubs to a new location, or

ii selecting one of the nubs with a left (double?)-click and using the arrow keys to move it one pixel at time;

c. deleted (by right-clicking on it?);

d. undeleted (if performed before any other operation since it's deletion), by right-clicking again (with the shift key depressed?)

)

X. If the "Transform" button is clicked (or the Enter key is pressed) after just one source-destination pair is defined, then the pixels selected to be moved shift just like a move operation without any rotation or scaling. The operation is complete: the Transform dialogue exits.

If the "Transform" button is not clicked at this point, . . .

4. A second pair of source and destination pixels may be selected in a repetition of steps 2. and 3.

Y. If the "Transform" button is clicked (or the Enter key is pressed) at this point then the selection is transformed so that the two source pixels are relocated to their respective destinations, applying, to the whole selection, any rotation or scaling necessary to achieve this. The operation is complete: the Transform dialogue exits.

If the "Transform" button is not clicked at this point, . . .

5... Further pairs of source and destination pixels may be selected.

Z. The "Transform" button is clicked (or the Enter key is pressed) and the selection is 'morphed' so that all the source pixels are relocated to their respective destinations, applying, to the whole selection, any rotation, scaling and stretching necessary to achieve this.

It should not be necessary for a source pixel to be a pixel within the current selection. It could be a 'virtual source pixel' and mapped onto a virtual destination, but this vector would contribute to the transform generated just as if the current selection filled the whole canvas - however, only the area of the current layer within the current selection would be affected by the transform.

In any case where a transform carries pixels at the boundary of the current selection into the interior of the selection, one would have to take a view on (or provide an options to select) whether,

a. the boundary itself is 'morphed' by the transformation so that the selection changes shape under the transformation and, if so, whether pixels carried from the selection boundary are

i 'torn' from the boundary (producing an area of transparency in the transformed layer between the old boundary location and the new boundary location), or

ii 'stretched' from the old boundary to it's destination (producing a sequence of pixels the same colour as the stretched pixel), or

iii the gap between the old boundary and the new boundary of the selection is filled by pixels that have 'escaped' from inside the old selection and remain in their original locations (thus producing an area where some pixels which have been mapped onto and represented in a new position within the new selection boundary, are also mapped onto and represented in their original position within the original selection, but outside the morphed selection boundary),

or,

b. the selection boundary remains unaffected by the transformation and, if so, whether pixels carried from the selection boundary are

i 'torn' from the selection boundary (producing an area of transparency in the transformed layer between the selection boundary and the new location of the torn pixel), or

ii 'stretched' from the selection boundary to it's destination (producing a sequence of pixels the same colour as the stretched pixel), or

iii the gap between the selection boundary and the new position of the pixels carried from the boundary is filled by pixels that have been 'imported' by the transformation from outside the selection (thus producing an area where some pixels which are still represented (in their original positions - outside the selection), are also mapped onto and represented in an area within the selection),

Note that:

Once the selection is deselected following the transformation, the visual effect of a.i above would be indistinguishable from b.i, likewise a.ii and b.ii, but a.iii would produce a different result than b.iii.

The Click of the "Transform" button ("Transform Pixels") and the defining of the transform vectors ("Define Transform") ought to be distinct operations in the history window. This would permit a trial operation to be quickly and easily adjusted if it did not quite achieve the desired effect, by undoing the Transform Pixels operation and thus leaving the user with all the previously defined transform vectors ready to adjust.

It might also be useful for the Transform Tool to keep a history of (at least one) transform(s) so that (this)these could be selected for reapplication to another selection.

If only one transform were kept in the history, then another button, "Retrieve Last Transform" would be useful in the Transform dialogue box, which would leave the user ready to adjust, if desired, the vectors of the last transform before clicking the "Transform" button.

If many, then a dropdown listbox would be useful, that were used to select transforms by name, blank when the tool is invoked so that the user can either go ahead and start defining transform vectors, or can select a previous transform from the dropdown list by name. Unless otherwise entered, a default name would be created (starting with "1", "2" etc.) when the "Transform" button is clicked. To create a copy of an existing transform to work with, any time the original is selected just type a new name in the dropdown selection box and press the Enter key; Or whatever is in the dropdown selection box when the "Transform" button is clicked will be the name of the new transform. To rename a transform create a copy, change it's name, press Enter and then delete the original. To delete a stored transform, highlight it in the dropdown list and hit the delete key. (An undoable operation?)

Should transforms be saved in a PDN file? . . . saveable in some other file?

Again, if there already exists a plugin or some such that provides something like this functionality, I would be pleased to be enlightened.

[Rick Brewster]

Wow that is a lot to read...! Unfortunately I just don't have the energy to read through it all at this moment.

Could you provide some sample images that show what you're trying to achieve, or have already achieved?

The first thing I spotted is that you're using Layers->Rotate/Zoom for rotations. Did you know that Move Selected Pixels can do rotation as well? In the status bar it'll tell you that you can drag with the right mouse button to perform a rotation (yeah yeah, I'll be adding a "rotate lollipop" in v4, this is honestly a silly thing to not have in the UI).

[hedles]

Rick, Thanks for your reply.

Sorry, I did go on a bit. I just found that more and more explanations were needed as I thought around how the tool would work and what contingencies might arise. If you can read only from "My suggestion is for an new Transform Tool" down to the paragraph labelled Z., that gives the essentials of how I see the Tool operating. The rest is just footnotes.

What I am trying to achieve:

The essential problem is aligning two pictures - or rather two parts of the same picture (often including text) - that have been scanned separately and at minutely differing angles, so that one needs a rotation - usually of only tenths of a degree (or they don't line up properly all over) as well as a vector shift into place.

I got into using Layers->Rotate/Zoom to achieve the rotations because mouse movements didn't provide fine enough control with rotations using RMB with Move Selected Pixels. It's not so much a question of lack of a rotate lollipop (if I understand correctly what you mean by that), simply that mouse movement doesn't cut the mustard, whereas precision control down to 100ths of a degree does.

The problem is that it usually takes many trials to get the rotation spot on and that takes a lot of time - especially on my very old desktop computer which is maxed out at 384MB! (I know. I need a new computer!)

What has hit me - over and over again - is that if only I could define a rotation, not by the numerical size of the angle, but by actually mapping where two pixels were each to start from and to end up, then the rotation would be correct first time, every time - and any shifting required would be achieved in the same operation.

Then I realised that (unless one was very careful - or lucky! - in the selection of the two pixels and their destinations) this transform would most likely need to include a scaling as well as the rotation and the shift. Well that was all to the good, if the pixels ended up mapping correctly from picture to picture.

From there the idea morphed into a generalised morphing tool, which maps any number of pixels each onto a destination point, and lets the maths apply any scaling and stretching (rubber sheet geometry) that was needed.

I'll see if I can get together an example or two to post.

Thanks for listening.