search

peircej / jbrout

Automatically exported from code.google.com/p/jbrout
0 stars 0 forks source link

Incompatibilty between synchronizeXmp option and pyexiv2 0.3 #184

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Use pictures tagged with old pyexiv2 (0.1 => exiftool for XMP), accented 
characters, and synchronizeXmp option on
2. Load them on jbrout with pyexiv2 0.3 and synchronizeXmp on
3. Refresh the album

What is the expected output? What do you see instead?
Tags are duplicated, with incorrectly encoded characters. 
Each time the album is refreshed, a new set of tags is produced, since they are 
converted from ansi to utf8 and reencoded (or the other way around), and merged 
with the old ones. 

What version of the product are you using? On what operating system?
Jbrout SVN (R328) on Ubuntu 11.04 and pyexiv2 0.3

Please provide any additional information below.
Apparently, XMP tags created with exiftool where encoded in ANSI instead of 
UTF8 (but that might depend on the platform). 

Using pyexiv2 0.3 already does the synchronization IPTC/XMP, so the option 
should then be disabled, or invalidated anyway, since it does at minima twice 
the job, or creates invalid tags. 

Nb: not tested with accented chars created correctly (correct encoding of XMP 
tags in UTF8)

Original issue reported on code.google.com by chartier...@gmail.com on 25 May 2011 at 12:00

GoogleCodeExporter commented 8 years ago

Original comment by chartier...@gmail.com on 27 May 2011 at 5:08

Attachments:

GoogleCodeExporter commented 8 years ago 
Is this the bug #161 ?
(exiftool trouble thru synchronizeXmp)

Original comment by manat...@gmail.com on 8 Jun 2011 at 2:53

GoogleCodeExporter commented 8 years ago 
Concerning comment 2 ... yes, I believe so. And I believe the solution proposed 
in bug #129 (eliminating exiftool altogether) is the only sane solution.

Original comment by matej.c...@gmail.com on 4 Jul 2011 at 3:07

GoogleCodeExporter commented 8 years ago 
Is this issue now fixed with revision r335 which closed bug #129

Original comment by r...@wallace.gen.nz on 7 Jul 2011 at 5:45

GoogleCodeExporter commented 8 years ago 
Sorry for not answering, earlier, but yes, it is a duplicate of bug #129 and 
was fixed by r335 (test done on same images OK).

Original comment by chartier...@gmail.com on 12 Jul 2011 at 5:44

GoogleCodeExporter commented 8 years ago 
=> to be closed

Original comment by chartier...@gmail.com on 12 Jul 2011 at 5:45

GoogleCodeExporter commented 8 years ago 
Thanks for the update, closing

Original comment by r...@wallace.gen.nz on 12 Jul 2011 at 11:26