GNOME Bugzilla – Bug 629960
Saving multiple rotated images saves only last one
Last modified: 2021-06-19 08:46:50 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.
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.
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?
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
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.
I don't recall doing flips, only rotations. I just pressed the Left or Right buttons (once for each) for some photos.
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."
*** Bug 654034 has been marked as a duplicate of this bug. ***
*** Bug 666691 has been marked as a duplicate of this bug. ***
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.
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.
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.
Yes, it does, which is why it is targeted for 3.6. ;) It most likely won't be fixed in time though. :(
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.
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.
Still happens to me with eog 3.14.4 and Ubuntu 15.04
Still present in 3.18.5
(In reply to Andrea Vai from comment #16) > Still present in 3.18.5 SORRY, 3.18.2
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.
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.
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?
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.
Still present (and very annoying) in $ eog --version GNOME Image Viewer 3.28.1
Seems working in eog 3.34.2 (Fedora 31)
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.
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.