square crop does not produce an image that is exactly square
Submitted by Adam Dingle
Link to original bug (#717027)
Description
---- Reported by adam@yorba.org 2010-11-15 12:18:00 -0800 ----
Original Redmine bug id: 2827
Original URL: http://redmine.yorba.org/issues/2827
Searchable id: yorba-bug-2827
Original author: Adam Dingle
Original description:
Ticketed athttps://bugs.launchpad.net/bugs/675717:
Shotwell gives inconsistent results when trying to make a square crop of
an image. Sometimes the results are fine, meaning that the height equals
the width, but other times the result is off by one or two pixels. For
example, an image that should be 600×600 pixels is 600×601 instead. It
seems to me that cropping large images exacerbates the problem, while
smaller images are usually fine.
---- Additional Comments From shotwell-maint@gnome.bugs 2011-05-19 11:46:00 -0700 ----
History
Comment 1
Updated by Valentín Barros over 2 years ago
Well… I tried to fix this, but I found it too hard :S It seems to be some problems related to calculating things using float/double and later storing them using int (rounding sometimes and truncating another ones).
I found that there are two versions of this bug. One of then is the reported one, and the other is that sometimes an image (for example) that should be 600×600 is 600×606 I mean, the error is split in two phases, and the first one only happens sometimes, but when it happens it maximizes the second one.
First error is that sometimes the crop rectangle is not a rectangle. I found the error in CropTool.constrain_crop, as I've seen that sometimes the box created at the end of the function is N x N+1 instead of N x N, while all values seems to be right to me, just until the execution reaches the final strange part of the code, where scaled_width/height are modified multiplying them by box_rescale_factor. The error could be related to the fact that scaled_center_x – (scaled_width / 2.0f) sometimes produces a negative value at the end of the function, where the new Box is created.
You can force this situation using a without restriction aspect ratio to create a hight but strait crop, then move it to the very left of the photo and later select square aspect ratio: The produced crop is not really a square.
The second situation is the most common: The crop is really a square but the created image isn't N x N+1 instead of N x N.
This time I'm not sure where the problem is, but to someone more familiarized with the app it could be relevant to know that with large images seems to be not possible to obtain a correct translation between scaled pixbuf coordinates to original photo coordinates, because there is an operation of rounding when scaling the pixbuf, so Dimensions.get_scale_ratios returns wrong values I think this because if you go to Box.get_scaled_similar you'll see that right – left == bottom – top, but r – l != b – t, so the error is in x_scale or in y_scale, which are calculated as original-photo-x / scaled-pixbuf-x (being the x with or height, you know).
Sorry if I am wrong, but those are my conclusions after investigating the problem but I couldn't correct the error, so I thought this could be helpful to somebody.
Cheers!
Comment 2
Updated by Adam Dingle over 2 years ago
Valentn, thanks for investigating this as far as you did and for writing up your findings. This isn't at the top of our priority list, but I hope we'll be able to investigate this in more detail at some point.
--- Bug imported by chaz@yorba.org 2013-11-25 21:48 UTC ---
This bug was previously known as bug 2827 at http://redmine.yorba.org/show_bug.cgi?id=2827
Unknown Component Using default product and component set in Parameters Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution