Rotation feels "backwards", doesn't persist for multiple images

[ferdnyc]

After spending a little time with the (incredibly handy!) page-rotation feature, I've come to the conclusion that its rotation just feels... backwards. Working with a page scan, it's natural to think of it as a physical piece of paper, and to conceptualize rotation operations as "turning" that piece of paper. So, "increasing" the rotation would mean turning the paper farther to the right (clockwise), the opposite of how gImageReader currently inteprets the rotation. (Bonus: The direction of rotation would match the placement of the [-] [+] buttons on the toolbar.)

Before filing this as a bug I decided to check how Gimp handles rotation, to get another data point. Gimp has two rotation modes. Quoted descriptions are from the Gimp manual.

• "Normal rotation" : "will rotate the layer as one might expect", and works as I described. As you increase the rotation angle, the displayed image/layer turns in a clockwise direction.
• "Corrective rotation" : "is primarily used to repair digital images that are not straight". As you increase the angle of rotation, the displayed image doesn't move at all — instead, the overlay that Gimp superimposes on the image/layer (by default, a bounding box containing a 15x15 grid of guide lines) rotates in the opposite direction. The correct angle of rotation is discovered by visually lining up the grid lines with horizontal/vertical image features, rather than having to "eyeball" it straight. When you press "Rotate", the image/layer is then rotated accordingly.

So, based on Gimp's example I feel I can more confidently say that gImageReader's current rotation feature is reversed. A "corrective rotation" feature could be handy to have, but it would require some sort of "horizon" overlay (like the Gimp's guide box) that could be rotated in lieu of turning the image itself. (Typically I'll draw an arbitrary selection box, in gImageReader, and then rotate the image until the baseline of a line of text is aligned with the edge of the box.)

---

Separate from the above, but also rotation-related: When working with multiple images, switching between them resets the angle of rotation to 0. It would be great if the rotation persisted per image, so it was possible to move among them without losing the rotation and having to re-do it. Meaning (for instance), the user could do the following:

1. Load three images; Slide 1, Slide 2, Slide 3.
2. Rotate Slide 1 to 3.1 degrees.
3. Change to Slide 2, rotation resets to 0.
4. Rotate Slide 2 to -2.6 degrees.
5. Switch back to Slide 1, rotation is set to 3.1 degrees.
6. Switch to Slide 3, rotation goes to 0 (as there's no stored value).

[manisandro]

Hello and thanks for the feedback.

The reason why the sign of the rotation was implemented this ways is because mathematically positive rotations are counter-clockwise. But I see that, indeed, Gimp does it the other way round, and I agree that it feels more intuitive, especially considering the layout of the + and - buttons in the spinbox. So it is probably worth changing, just hoping not too many people have gotten used to the old behaviour.

The second issue is also a good point, shouldn't be too hard to implement.

[manisandro]

Just thought I'd mention: I'm currently working on a Qt port of the application, and I'll integrated the necessary changes for this issue in the process. Will probably be another two weeks.

[manisandro]

Fixed in gimagereader-3.0.

[ferdnyc]

I just checked out and built the gImageReader Qt port (after pulling in qtspell-qt4 (and -devel) from Fedora 20 updates-testing, as it hasn't hit the main repo yet — seems the package was only created 10 days ago); it looks great! Everything does indeed work as expected with regards to these changes. Many thanks!

I have one feature suggestion, so far, from playing around with it, but I'll file that as a new issue.