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 610389 - metadata lost after resize
metadata lost after resize
Status: RESOLVED FIXED
Product: gthumb
Classification: Other
Component: general
2.11.x
Other Linux
: Normal normal
: ---
Assigned To: Paolo Bacchilega
Paolo Bacchilega
: 568187 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-02-18 19:14 UTC by Michael Chudobiak
Modified: 2010-03-02 16:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Chudobiak 2010-02-18 19:14:51 UTC
The resize tool loses the exif metadata in the original image (although it inserts the mandatory exif tags).

This is undesirable. It should copy the metadata.

- Mike
Comment 1 Matthias Hawran 2010-02-18 21:05:51 UTC
I confirm this.
Comment 2 Paolo Bacchilega 2010-02-20 09:43:08 UTC
fixed now.
Comment 3 Matthias Hawran 2010-02-23 13:50:19 UTC
I'm afraid this is not fixed :(
I just tried with 2.11.2.1
It's even worth, more metadata are lost.
Only the 'File' and 'General' sections are left.
Comment 4 Michael Chudobiak 2010-02-23 14:19:24 UTC
Are you sure?

Both the Tools>Resize and Edit>Resize preserved the exif data for me, using latest git.

- Mike
Comment 5 Michael Chudobiak 2010-02-23 14:24:57 UTC
You have the "Edit Metadata" plugin enabled, right?

- Mike
Comment 6 Matthias Hawran 2010-02-23 14:56:48 UTC
Yup I'm pretty sure.
Like I say in Bug 610810, I just deleted my git clone, to download a fresh one, but no changes.
I tried it many times, with both ways (tools>resize and edit>resize)

I do have "Edit metadata" enabled, but how is it related?
(I have all extension enabled btw).
Comment 7 Michael Chudobiak 2010-02-23 14:59:21 UTC
Could you try deleting /usr/lib/gthumb/extensions and reinstalling?

- Mike
Comment 8 Matthias Hawran 2010-02-23 15:06:52 UTC
Well I'm not installing :D
I run in place (--enable-run-in-place)
So no such directory for me.
Comment 9 Matthias Hawran 2010-03-01 15:22:30 UTC
Guys,

How can we move forward with this issue?
I tried to do some step by step debugging, trying to understand what's going wrong, but I must say I'm not sure where to look.

My starting point is Paolo's modifications in gthumb/gth-pixbuf-list-task.c which fixes the problem for Mike.

http://git.gnome.org/browse/gthumb/commit/?id=c98a741816d940ca61d1b7e2fb5c1093ea42c0b3

In process_current_file() there's a call to _g_query_all_metadata_async() to load the metadata.
I have the feeling the metadata is not loaded, or is lost somewhere.

In file_info_ready_cb(), there's
g_file_info_copy_into (updated_file_data->info, file_data->info);

which is suppose to copy the GFileInfo right?

Is that the good place to verify the metadata is loaded/copied?
I'm trying to use, for example

g_file_info_get_attribute_as_string (updated_file_data->info, "Exif::Image::Make");

but I get 
GthMetadata:0x945eaa0

Instead of 'Canon' in this case (the model of my camera)

Any inputs ?
Comment 10 Michael Chudobiak 2010-03-01 15:49:03 UTC
Just to be sure, try some tests on images from other brands of cameras, just in case exiv2 is having problems with the metadata from your specific camera.

- Mike
Comment 11 Matthias Hawran 2010-03-01 16:27:03 UTC
Good idea.
I managed to get images from Nikon, Konica and another Canon.
The result: all keep the metadata except Canon.

However note that everything works fine in 2.10.x (compiled version) which uses the same exiv2 library.
Difficult then to put all the blame on exiv2.

To experiment a little more, I notice the same behavior for the 'convert format' function. All metadata lost for Canon, all kept for others.
And works fine in 2.10.x for Canon.

There's definitely something with Canon...
Comment 12 Michael Chudobiak 2010-03-01 16:30:02 UTC
2.10.x does NOT use exiv2.

- Mike
Comment 13 Matthias Hawran 2010-03-01 16:35:48 UTC
The latest 2.10.x repository version does, which I'm using.
Remember bug 431187 :-)
Comment 14 Michael Chudobiak 2010-03-01 16:42:26 UTC
Well, no released version of 2.10.x used exiv2. I forget what version info was used in the unreleased trunk stuff with exiv2.

Anyway... I don't suppose any exiv2 warnings or errors are dumped to the console?

- Mike
Comment 15 Matthias Hawran 2010-03-01 16:52:52 UTC
(In reply to comment #14)
> Anyway... I don't suppose any exiv2 warnings or errors are dumped to the
> console?
> 
> - Mike

That would be to easy :-D
Comment 16 Michael Chudobiak 2010-03-01 16:56:58 UTC
You could try using the exiv2 command-line tool to copy the metadata. That would at least tell us if the problem was deep in exiv2, or in gthumb's use of it.

I haven't used it in a while, so I forget how to use it...

- Mike
Comment 17 Michael Chudobiak 2010-03-01 16:58:00 UTC
Posting a link to a sample problem image would be nice too.

- Mike
Comment 19 Matthias Hawran 2010-03-02 09:10:48 UTC
OK I tried exiv2 CLI, but I'm not sure what is your idea here.

exiv2 CLI allows you to print the metadata or extract them to a .exv file (it's binary)

I can do both and the metadata is there.

For the Canon one

$ exiv2 -p s 00N6RN-39382984.JPG                      
Nom du fichier  : 00N6RN-39382984.JPG                 
Taille du fichier: 2268467 Octets
Type MIME       : image/jpeg
Taille de l'image: 1880 x 2816
Marque de l'appareil: Canon
Modèle de l'appareil: Canon EOS DIGITAL REBEL XTi
...


$ exiv2 -p a 00N6RN-39382984.JPG 
Exif.Image.Make                              Ascii       6  Canon
Exif.Image.Model                             Ascii      28  Canon EOS DIGITAL REBEL XTi
Exif.Image.Orientation                       Short       1  (0)                        
Exif.Image.XResolution                       Rational    1  72                         
Exif.Image.YResolution                       Rational    1  72                         
Exif.Image.Software                          Ascii      11  Picasa 3.0                 
Exif.Image.ResolutionUnit                    Short       1  Pouce                      
Exif.Image.DateTime                          Ascii      20  2006:10:05 21:49:46        
Exif.Image.YCbCrPositioning                  Short       1  Co-sited                   
Exif.Image.ExifTag                           Long        1  216                        
Exif.Photo.ExposureTime                      Rational    1  1/100 s                    
Exif.Photo.FNumber                           Rational    1  F5.6                       
Exif.Photo.ExposureProgram                   Short       1  Priorité ouverture         
Exif.Photo.ISOSpeedRatings                   Short       1  200                        
Exif.Photo.ExifVersion                       Undefined   4  2.21                       
Exif.Photo.DateTimeOriginal                  Ascii      20  2006:10:05 21:49:46
Comment 20 Paolo Bacchilega 2010-03-02 11:57:45 UTC
I added a line to print the exiv2 error, it gives the following message:

TIFF array element tag 43 has wrong type
Comment 21 Paolo Bacchilega 2010-03-02 12:11:03 UTC
I think the problem is explained here: 
http://uk.groups.yahoo.com/group/exiv2/message/1472

it looks like we have to store the original type in GthMetadata.
Comment 22 Matthias Hawran 2010-03-02 14:08:24 UTC
*** Bug 568187 has been marked as a duplicate of this bug. ***
Comment 23 Paolo Bacchilega 2010-03-02 16:19:55 UTC
It should be fixed now.  I tested the canon image posted above and it worked for me.
Comment 24 Matthias Hawran 2010-03-02 16:37:01 UTC
Simply amazing!
It's fixed.
Thanks a lot Paolo.