After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 629960 - Saving multiple rotated images saves only last one
Saving multiple rotated images saves only last one
Status: RESOLVED OBSOLETE
Product: eog
Classification: Core
Component: general
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
: 654034 666691 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-09-17 20:34 UTC by denkpadje
Modified: 2021-06-19 08:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Incorrect condition inside g_return_if_fail in eog_image_set_thumbnail. (689 bytes, patch)
2016-12-11 21:50 UTC, Igor Unanua
rejected Details | Review
Set priv->modified = TRUE (669 bytes, patch)
2017-01-03 18:04 UTC, Igor Unanua
needs-work Details | Review

Description denkpadje 2010-09-17 20:34:33 UTC
I opened a folder containing multiple images. I opened one of them in EoG and then started rotating several of the images. Then, when I closed EoG, it asked me to save the files, I choose "Save". When I checked the images, only the last one got saved. As a result, because of this bug, I had to sequentially open each image, rotate it, close Eog, save the image, and then open the next image that had to be rotated.

EoG 2.30.2

Tell me if you need more information.
Comment 1 denkpadje 2010-09-17 20:44:35 UTC
I now realise I could have drag and dropped the save button to the toolbar to save some time, but that doesn't fix bug of course.
Comment 2 Felix Riemann 2010-09-18 10:52:46 UTC
Just tried and it worked correctly here.
The only thing I can think of right now would be that an error occured while saving. Eog currently doesn't react on that (bug 615376). But then it would have happened while saving each image on its own as well.

Where were those files located somewhere special (USB‐Stick, Camera, Network‐Share, …) in your case?
Comment 3 denkpadje 2010-09-19 16:19:36 UTC
I just copied the photo's to a new folder and then tried messing with it by opening via nautilus and terminal. I don't get any output from eog when running in terminal and in terminal it doesn't save. Via nautilus it saves sometimes. Also when I press the save button (which then becomes insensitive), eog still asks for saving via dialog. The files are in a folder in ~/Desktop
Comment 4 Felix Riemann 2010-10-16 21:14:27 UTC
Can you roughly describe which modifications you applied to the images?

We just discovered a bug during image saving when rotations and flips were mixed (see bug 632290). Maybe this is the same.
Comment 5 denkpadje 2010-10-17 07:23:35 UTC
I don't recall doing flips, only rotations. I just pressed the Left or Right buttons (once for each) for some photos.
Comment 6 Sebastien Bacher 2011-03-11 18:37:13 UTC
There is a similar bug on https://bugs.launchpad.net/eog/+bug/697882

"Eog image viewer saves only last changed item 

Browse images with eog and rotate them, and after rotating more than one image, close eog, it will ask to select pictures to save the changes (all preselected by default), press Save, it saves all, but only the last one is really rotated."
Comment 7 Felix Riemann 2011-07-27 20:25:37 UTC
*** Bug 654034 has been marked as a duplicate of this bug. ***
Comment 8 Felix Riemann 2011-12-30 11:19:16 UTC
*** Bug 666691 has been marked as a duplicate of this bug. ***
Comment 9 Felix Riemann 2011-12-30 13:03:50 UTC
I finally was able to reproduce it myself.
It looks like not all pictures are flagged modified correctly.
If you look at the number of modified images the dialog talks about when quitting you'll notice that this doesn't match the number of images you changed.
Comment 10 Felix Riemann 2011-12-30 13:46:05 UTC
Alright, I think I found the problem and it looks like this could be broken since at least eog-2.20 but just didn't show that easily before adding the confirmation dialog. The problem is that eog only flagged an image modified if it could apply the transformation to the image itself and/or the image's thumbnail. If the image you modify is not visible in the collection or the timing is bad that the transformation job falls behind, the image is not flagged correctly.

This part of the problem is rather easy to fix by reordering two codeblocks.
Unfortunately this will leave us (and partially already does so today) with wrong Exif data. That is updated when the transformation is applied, but of course only if it is loaded at that time. Fixing this is probably going to be a bigger change as it will likely requiring moving this work to image saving.
Comment 11 nodiscc 2012-07-28 14:30:23 UTC
This bug was reported against a version which is not supported any more. Developers are no longer working on this version so there will not be any bug fixes for it.
Can you please check again if the issue you reported here still happens in a recent version of GNOME and update this report by adding a comment and adjusting the 'Version' field?

Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here.

Without feedback this report will be closed as INCOMPLETE after 6 weeks.
Comment 12 Felix Riemann 2012-07-28 15:47:33 UTC
Yes, it does, which is why it is targeted for 3.6. ;)

It most likely won't be fixed in time though. :(
Comment 13 Egor Panfilov 2014-06-07 13:46:26 UTC
eog 3.12.2-1.

1. select, for example, 20 images in EoG;
2. rotate (all thumbnails in eog window look rotated);
3. press ctrl+s to save (all images still selected);
4. wait for progressbar to be filled;
5. thumbnails in eog still look rotated, but thumbnails in nautilus (so images do) look various: last image and first 7 images in folder are rotated, but others arent.

i'm facing this bug since 2007 year, i think.
Comment 14 Andrea Vai 2014-10-06 07:50:54 UTC
Same happens to me (eog 3.4.2 and Ubuntu 12.04 LTS)

I noticed that the bug happens if I open a some images taken from my phone, but does not occur if I open a bunch of files coming from my Nikon camera.
Comment 15 Andrea Vai 2015-12-03 10:47:11 UTC
Still happens to me with eog 3.14.4 and Ubuntu 15.04
Comment 16 Andrea Vai 2016-05-19 09:55:02 UTC
Still present in 3.18.5
Comment 17 Andrea Vai 2016-05-19 09:55:58 UTC
(In reply to Andrea Vai from comment #16)
> Still present in 3.18.5

SORRY, 3.18.2
Comment 18 Igor Unanua 2016-12-11 21:50:49 UTC
Created attachment 341782 [details] [review]
Incorrect condition inside g_return_if_fail in eog_image_set_thumbnail.

Hi there!

The assert g_return_if_fail (GDK_IS_PIXBUF (thumbnail) || thumbnail == NULL), in eog_image_set_thumbnail function, does not return when thumbnail value is NULL, assigning a NULL value to priv->thumbnail.

Later, when eog_image_real_transform function is invoked, only the transformation is applied to the EogImages with priv->image != NULL or priv->thumbnail != NULL.
Comment 19 Felix Riemann 2016-12-19 19:36:06 UTC
Review of attachment 341782 [details] [review]:

Thanks for the patch!
Unfortunately, setting the thumbnail to NULL is actually desired here. This saves the thumbnail memory in large folders.
It works around the problem (no rotation if neither image nor thumb are loaded) but it's not fixing it.
Comment 20 Igor Unanua 2017-01-03 18:04:07 UTC
Created attachment 342786 [details] [review]
Set priv->modified = TRUE

Second try :)

What if eog_image_real_transform sets priv->modified = TRUE regardless of the values of priv->image and priv->thumbnail?
Comment 21 Felix Riemann 2017-01-16 18:26:12 UTC
Review of attachment 342786 [details] [review]:

Thanks for staying on it.
This is probably the easiest solution, however it suffers from the problem I described in comment 10. Although all images might be written now, it doesn't adjust the Exif data in the written files. So, if you employ Exif autorotation your image might be rotated the wrong way, besides the height and width entries being wrong.
Comment 22 Andrea Vai 2020-04-09 08:58:30 UTC
Still present (and very annoying) in

$ eog --version
GNOME Image Viewer 3.28.1
Comment 23 Andrea Vai 2020-04-17 13:15:03 UTC
Seems working in eog 3.34.2 (Fedora 31)
Comment 24 Andrea Vai 2020-04-17 13:54:29 UTC
I am sorry to report that with 3.34.2 it still fails sometimes.

I am sorry I cannot specify "sometimes" better, at the moment.
Comment 25 André Klapper 2021-06-19 08:46:50 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/eog/-/issues/

Thank you for your understanding and your help.