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 309219 - EOG does not preserve EXIF data when saving pictures
EOG does not preserve EXIF data when saving pictures
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: general
2.10.x
Other All
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
: 312445 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-06-30 18:22 UTC by Vladimír Kotal
Modified: 2006-07-13 15:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
sample picture before any write action in EOG was performed (930.28 KB, image/jpeg)
2005-06-30 18:29 UTC, Vladimír Kotal
  Details
After rotation+save was performed (494.82 KB, image/jpeg)
2005-06-30 18:31 UTC, Vladimír Kotal
  Details
try to fix it (1.17 KB, patch)
2006-05-01 16:03 UTC, Felix Riemann
none Details | Review
possibly better version (1.31 KB, patch)
2006-05-01 16:30 UTC, Felix Riemann
committed Details | Review

Description Vladimír Kotal 2005-06-30 18:22:57 UTC
Please describe the problem:
When doing some manipulation with a picture in EOG (e.g. rotating it) and then saving it (via Ctrl+S), 
the resulting image has its EXIF data part stripped.

Steps to reproduce:
1. open some image with EXIF data present in EOG
2. rotate it, save it, close it
3. open it once more -> it does not have the EXIF data it had before the rotation+save


Actual results:
The EXIF data disappear from the picture.

Expected results:
The EXIF data will be preserved.

Does this happen every time?
No, it seems it depends on whether the name of the directory in which the picture is located contains 
spaces.

Other information:
Comment 1 Vladimír Kotal 2005-06-30 18:29:46 UTC
Created attachment 48464 [details]
sample picture before any write action in EOG was performed
Comment 2 Vladimír Kotal 2005-06-30 18:31:44 UTC
Created attachment 48465 [details]
After rotation+save was performed

Now the picture does not contain EXIF data.
Comment 3 Vladimír Kotal 2005-06-30 18:35:25 UTC
It can be seen that EXIF data are present in the first picture, whereas the second lacks them:

[erazim ~]$ jhead /home/media/Pictures/dir\ with\ spaces/pict0400-before.jpg
File name    : /home/media/Pictures/dir with spaces/pict0400-before.jpg
File size    : 952602 bytes
File date    : 2005:06:29 19:05:07
Camera make  : KONICA MINOLTA
Camera model : DiMAGE Z5
Date/Time    : 2005:06:20 18:32:00
Resolution   : 2560 x 1920
Flash used   : No (auto)
Focal length :  5.9mm  (35mm equivalent: 35mm)
Exposure time: 0.025 s  (1/40)
Aperture     : f/2.8
ISO equiv.   : 100
Whitebalance : Auto
Metering Mode: matrix
Exposure     : program (auto)

[erazim ~]$ jhead /home/media/Pictures/dir\ with\ spaces/pict0400-after.jpg
File name    : /home/media/Pictures/dir with spaces/pict0400-after.jpg
File size    : 506693 bytes
File date    : 2005:06:30 20:27:27
Resolution   : 1920 x 2560

[erazim ~]$
Comment 4 Teppo Turtiainen 2005-07-10 23:23:29 UTC
Confirmed. Saving the file to a directory with spaces in its name seems to make
a difference. Very strange.
Comment 5 Brent Smith (smitten) 2005-08-03 18:24:31 UTC
*** Bug 312445 has been marked as a duplicate of this bug. ***
Comment 6 Brent Smith (smitten) 2005-08-03 18:25:45 UTC
wow, yeah the space definitely makes a difference for some reason.  It worked
fine before I added a space to the location of the image.
Comment 7 Felix Riemann 2006-05-01 15:59:49 UTC
Well, EOG prints a warning in this case:

(eog:23764): Eog-WARNING **: Input file not openable: /home/felix/eogtest/folder%20with%20spaces/eogtest.jpg

I don't think fopen (which causes this message with an ENOENT) understands entities like %20.
Comment 8 Felix Riemann 2006-05-01 16:03:03 UTC
Created attachment 64621 [details] [review]
try to fix it

This is the only solution I could find yet. I'm not sure if gnome_vfs_format_uri_for_display() is correct here, but gnome_vfs_uri_to_string, g_filename_from{uri,utf8} didn't work.
Comment 9 Felix Riemann 2006-05-01 16:30:51 UTC
Created attachment 64625 [details] [review]
possibly better version

This one uses gnome_vfs_unescape_string(), which seems more appropriate according to the docs.?
Comment 10 Lucas Rocha 2006-07-13 15:40:47 UTC
Patch applied in HEAD, gnome-2-14, and eog-ng branches. Thanks!

2006-07-13  Lucas Rocha  <lucasr@gnome.org>

        * libeog/eog-image-jpeg.c (_save_jpeg_as_jpeg): avoid losing
        EXIF data when saving changed jpeg images (Fixes bug #309219).
        Patch from Felix Riemann <felix@hsgheli.de>.