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 549861 - EXIF headers are lost when syncing resized pictures (SVN)
EXIF headers are lost when syncing resized pictures (SVN)
Status: RESOLVED WONTFIX
Product: conduit
Classification: Other
Component: dataproviders
unspecified
Other All
: Normal minor
: ---
Assigned To: conduit-maint@gnome.bugs
conduit-maint@gnome.bugs
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2008-08-29 20:07 UTC by Antonio
Modified: 2018-07-01 09:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Antonio 2008-08-29 20:07:13 UTC
Please describe the problem:
When the sync process is configured to resize the original pictures, the resulting copies don't include the original's EXIF metadata.

Steps to reproduce:
1. Setup a sync group from a folder containing any modern digital camera pictures to "Picasa". Configure Picasa to resize the original pictures.
2. Sync the group
3. Open Picasaweb, go to the chosen album and open one picture. On the right side of the page, press "more info".


Actual results:
You can see the uploaded picture's metadata is empty, while most digital cameras include fields such as aperture size, shutter speed, etc...

Expected results:
Uploaded picture should respect original's metadata.

Does this happen every time?
Yes

Other information:
The following patch against SVN 1681 solves it, but it'll make conduit depend on python-pyexiv2 library:

<----------------------------------------------------------------------------->
Index: PhotoConverterModule.py
===================================================================
--- PhotoConverterModule.py	(revisión: 1681)
+++ PhotoConverterModule.py	(copia de trabajo)
@@ -37,14 +37,16 @@
                         types[t] = None
             self._image_types = types
         return self._image_types
-        
+
     def _convert(self, photo, format, width, height, doResize, doReformat):
         """
-        Basically we defer the conversion until as late as possible, or 
+        Basically we defer the conversion until as late as possible, or
         not at all.
         """
         import gtk.gdk
+        import pyexiv2
 
+        in_file = photo.URI.path
         pb = photo.get_photo_pixbuf()
         out_file = photo.to_tempfile()
 
@@ -54,17 +56,32 @@
                 pb = pb.scale_simple(width,height,gtk.gdk.INTERP_HYPER)
             except Exception, err:
                 log.debug("Photo: Error scaling photo\n%s" % err)
-        
+
         #save to new format. gdk.Pixbuf needs the type argument
         if doResize or doReformat:
             log.debug("Photo: Saving photo:%s Format:%s" % (out_file,format))
             pb.save(out_file, format)
+
+            # Copy metadata to modified file
+            orig = pyexiv2.Image(in_file)
+            out = pyexiv2.Image(out_file)
+
+            orig.readMetadata()
+            out.readMetadata()
+
+            for key in orig.exifKeys():
+                try:
+                    out[key] = orig[key]
+                except ValueError:
+                    log.debug("Error copying EXIF tag %s" % key)
+            out.writeMetadata()
+
             #can safely rename the file here because its defintately a tempfile
             photo.force_new_file_extension(".%s" % format)
 
     def transcode(self, photo, **kwargs):
         log.info("Transcode Photo: %s" % kwargs)
-        
+
         #default format is the current format, and default is no resize
         formats = kwargs.get("formats",photo.get_mimetype()).split(',')
         newSize = kwargs.get("size",NO_RESIZE)
<----------------------------------------------------------------------------->
Comment 1 Alexandre Rosenfeld 2009-01-20 04:05:26 UTC
We could turn pyexiv2 as an optional dependency, much like GStreamer is now to read music tags. 
However, it would have the side-effect of the Exif metadata working for some people and not working for other people, without any visible explanation. We should probably avoid such things, unless we can better comunicate with the users what is missing and how to install it.
Comment 2 John Stowers 2009-01-20 04:10:46 UTC
I agree. It almost feels like a bug in Gtk - it should preserce EXIF headers (but I dont think that is going to happen)

One of the things on my TODO list is to provide a much more accessible logging system, to show the user what is going on. That would provide a place to display these things.

On another note, I am pretty disappointed with Ubuntu for not tracking our stable branch. I think I will just give up and tell users to install from a PPA. Unfortunately Jc2k has dropped off the map, so I need to learn how to make deb packages and put them into out ppa. Once we have control of this, we can depend on whatever we like.
Comment 3 André Klapper 2018-07-01 09:03:58 UTC
Conduit is not under active development anymore, has not seen code changes for eight years, and saw its last tarball release in 2010.
Its codebase has been archived: https://gitlab.gnome.org/Archive/conduit/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.