Feature #12032

Keystone UI improvement

Added by Eric Siegerman almost 2 years ago. Updated almost 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
git master branch
hardware architecture:


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.

  • 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....


#1 Updated by Tobias Ellinghaus almost 2 years ago

So you are basically asking for 2 handles per corner instead of one, located on the lines near the corner? Thus the four lines would still be defined by two points each.

#2 Updated by Eric Siegerman almost 2 years 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).

#3 Updated by Tobias Ellinghaus almost 2 years ago

  • % Done changed from 0 to 20
  • Status changed from New to Triaged

#4 Updated by Eric Siegerman almost 2 years 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 almost 2 years 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.

Also available in: Atom PDF

Go to top