Project

General

Profile

Bug #8688

changing crop borders resets crop orientation and thus loses crop setting

Added by tetreb - almost 8 years ago. Updated almost 7 years ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

100%

Estimated time:
Affected Version:
git development version
System:
unknown
bitness:
64-bit
hardware architecture:
amd64/x86

Description

-crop an image and rotate the crop area, then accept (double click)
-when you move the crop area next time, its orientation resets to default (and you have to do the crop again)

0001-Fix-Bug-8688-calculate-initial-image-aspect-ratio-to.patch (991 Bytes) 0001-Fix-Bug-8688-calculate-initial-image-aspect-ratio-to.patch Workaround - aspect recalculation on focus Petr Styblo, 06/06/2012 01:32 PM

History

#1 Updated by Simon Spannagel almost 8 years ago

verified with git master.

#2 Updated by Petr Styblo over 7 years ago

The reason for this bug is that aspect ratio isn't stored with the image crop properties, neither is the aspect orientation (swap button state).

When you move the crop area next time, its orientation resets to default

In fact it does not fall back to a default, but rather to a kind of global aspect ratio setting, which is the aspect setting that was applied to the last edited photo (change aspect ratio of one picture, switch to another picture and try to re-size).

I believe the proper way to handle this bug would be to save crop ratio together with other crop parameters.

A workaround that seemingly solves the situation is to forcibly recalculate and set an image aspect on each Crop and Rotate module focus event. This way we can get rid of the abrupt crop changes, but at the same time we introduce potential logical problems (e.g. setting an aspect where it wasn't one etc.). Another way is to start with a free aspect on every new edit, which isn't too compelling either.

Attached is the workaround with recalculated aspect ratio. Perhaps worth checking.

#3 Updated by Simon Spannagel over 7 years ago

  • Affected Version set to git development version
  • Target version set to Candidate for next patch release
  • Status changed from New to Triaged
  • Tracker changed from Bug to 4

#4 Updated by Simon Spannagel over 7 years ago

  • Status changed from Triaged to Patch attached
  • Tracker changed from 4 to Bug

#5 Updated by Simon Spannagel almost 7 years ago

  • System set to unknown
  • % Done changed from 0 to 100
  • Status changed from Patch attached to Fixed

this should be fixed by the rework of the c&r module.

Also available in: Atom PDF

Go to top