Keystone UI improvement
The keystone UI can be awkward to use, in that there's no way to drag one end of one guide line, leaving the other three guides unaffected. Thus, one has to do some very careful mousing to move a handle vertically, say, without changing its horizontal position.
For some images, things can be much worse. If the subject of the photo has significantly rounded corners, there are no obvious points to position the handles on. This results in a fair amount of iteration to home in on the correct positions. Once I've positioned the top guide, say, I can't move the pivot point for the right guide to where I need it, because that would screw up the top guide's position. So I have to estimate the top-right-corner's X position by eye (while being careful not to move the top guide); then estimate similarly for the bottom-right corner; then go back and fine-tune the top-right; then the bottom-right again; and so on. Repeat for the bottom and left guides.
In such a case, I don't want to interact with the corners at all; I want to be able to position each end of each guide, independently.
Suggested approach: add another pair of handles to each of the four guide lines. Each handle moves that end of its guide, with no effect on the other three guides.Notes:
- I want to de-keystone in both dimensions; thus using horizontal or vertical doesn't seem to help me. I need full
- This shouldn't require any changes to the stored data. The same four corner points can be stored; it's just that they might be computed by the GUI, rather than indicated directly by the user
- IMO, this issue wants to be classified somewhere between "bug" and "feature". The code is working as designed -- but the design itself has a bug....
#2 Updated by Eric Siegerman over 1 year ago
Yes, exactly. And in terms of persisted data, it would still be only the four intersection points, as it is now.
I was assuming the existing handles would remain, i.e. a total of three per corner. I imagine there are users who would be upset to lose the intersection handles. I don't have a strong opinion either way. It's a choice of functionality vs. clutter, and for me neither side is winning (especially since I'm new to darktable, and don't know which way the project tends to lean).
#4 Updated by Eric Siegerman over 1 year ago
I don't have a strong opinion either way
On further thought, I've changed my mind on this: I believe the intersection handles should stay. For an image that does have sharp corners to target on, the lack of them would be annoying. Not as bad as the other way around (as described above), but still suboptimal.
#5 Updated by Tobias Ellinghaus over 1 year ago
The biggest challenge is probably to deal with the points being close. It might make sense to only show those new control points when there is enough space and hide them otherwise.
If anyone wants to dive into this and give it a try, just join us in IRC so we can give some pointers to where to start.