---- Reported by shotwell-maint@gnome.bugs 2010-08-07 18:09:00 -0700 ----

Original Redmine bug id: 2369
Original URL: http://redmine.yorba.org/issues/2369
Searchable id: yorba-bug-2369
Original author: Thøger Thorsen
Original description:

I've recently changed to shotwell from F-Spot, and in general I am very happy
with the change. I do however have one problem, which is the design of the
Shotwell red eye removal procedure.

First off, the little circle has to be placed with a big “hand†mouse
cursor which makes it impossible to do any fine adjustment, since the cursor
is covering up the circle and the eye.

I tried to remedy this by zooming in on the picture before placing it, but as
soon as I select the red-eye removal tool, the image is automatically zoomed
out and is not zoomable while the tool is active – rendering it pretty much
unusable.

I really think Shotwell is awesome, and definitely an improvement from F-Spot.
But this looks likea bit of a design glitch…

Related issues:
related to shotwell - 3887: Redeye: Significant graphical corruption
occurs if the ma... (Fixed)
duplicated by shotwell - Feature #5716: Enabling zoom in red-eye (Duplicate)



---- Additional Comments From shotwell-maint@gnome.bugs 2012-08-27 05:08:00 -0700 ----

### History

####

#1

Updated by Adam Dingle almost 3 years ago

  * **Priority** set to _High_
  * **Subject** changed from _Red-eye removal virtually unusable_ to _allow red eye removal while zoomed_

Upping to high as several users have said they'd like this.

####

#2

Updated by Adam Dingle almost 3 years ago

  * **Status** changed from _Open_ to _Review_
  * **Assignee** changed from _Anonymous_ to _Lucas Beeler_

####

#3

Updated by Adam Dingle almost 3 years ago

Gustaf Thorslund suggested a workaround on the upstream ticket at
https://bugs.launchpad.net/ubuntu/source/shotwell/bug/652158 :

Crop out the area with the red eyes

Now use the redeye function on the limited picture

Use crop again and move the box to an other area of red eyes.

When done, crop the picture again to the full size (or any otherdesired size).

####

#4

Updated by dave42 - almost 3 years ago

This would be less important if the red eye removal function worked better.
I've added some suggestions on ticket #2171. My opinion is that those kinds of
improvements should be higher priority than this. Both would be great, of
course.

####

#5

Updated by kimaidou - almost 3 years ago

ticket #3069 is a duplicate of this ticket

####

#6

Updated by Adam Dingle almost 3 years ago

  * **Target version** changed from _0.4_ to _0.9_

####

#7

Updated by Antony Mee almost 3 years ago

  1. # mainly addresses a completely independent, and potentially more involved issue (the desaturation algo itself). Though I have not yet had a chance to look at the code, this sounds like a much more straight forward interface issue. It's true the red-eye algo isn't great, but it does the job okay for images where the eyes are small: precisely the ones where you want to zoom while fixing the red-eye.

Is this already tabled for 0.9 as Adam's change suggests?

####

#8

Updated by Lucas Beeler almost 3 years ago

@ onlymee:

> Is this already tabled for 0.9

> as Adam's change suggests?

We do hope to get this feature implemented for Shotwell 0.9, and I've already
done some work on it. In short, it's highly likely to make 0.9. It's not as
much a “straight forward interface issue†as it seems, however. Because of
Shotwell's non-destructive nature, we transform photos on the fly during
display and interaction while leaving the originals untouched. To get quick,
seamless zooming behavior, even with dynamically-regenerated 18 or 20
megapixel images, we have to do some clever caching and background processing
stuff. Getting all of this to work with dynamic red-eye updates isn't rocket
science, but it's not simple as it might appear. ;-)

Lucas

####

#9

Updated by Adam Dingle almost 3 years ago

  * **Target version** deleted (<strike>_0.9_</strike>)

Lucas has made good progress on an implementation, but it's still incomplete
and it's a bit late to try to get this into 0.9 at this point. We should
finish this up for 0.10.

####

#10

Updated by Adam Dingle over 2 years ago

  * **Assignee** changed from _Lucas Beeler_ to _Anonymous_

####

#11

Updated by Adam Dingle over 1 year ago

  * **Target version** set to _0.13_

####

#12

Updated by Adam Dingle over 1 year ago

  * **Target version** deleted (<strike>_0.13_</strike>)

####

#13

Updated by François Cerbelle about 1 year ago

  * **Description** updated (diff)

As my bug report has been merged to this one, I just want to repeat here an
idea to implement a quicker fix. Instead of allowing zooming while in red-eye,
it would be possible to have a dynamic magnifying glass instead of the red-eye
mouse cursor (as Hugin does when pining reference points on the photos). It
might be easier to implement than the whole zoom and maybe a better user-
experience also.



--- Bug imported by chaz@yorba.org 2013-11-25 21:46 UTC  ---

This bug was previously known as _bug_ 2369 at http://redmine.yorba.org/show_bug.cgi?id=2369

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