how far is support of exiv2 0.18?

Asked by Matěj Cepl

I would like to package pyexiv2 v. 0.3.2 for RHEL 6, but unfortunately it contains only exiv2-0:0.18.2-2.1 and given it is RHEL it is quite unlikely that RHEL package would be rebased just because of its Python bindings. How difficult it would be to make pyexiv2 working with exiv2 0.18?

Question information

Language:
English Edit question
Status:
Solved
For:
pyexiv2 Edit question
Assignee:
No assignee Edit question
Solved by:
Matěj Cepl
Solved:
Last query:
Last reply:

This question was reopened

Revision history for this message
Olivier Tilloy (osomon) said :
#1

I just had a go at compiling pyexiv2 0.3.2 against libexiv2 0.18.2 on Ubuntu Natty (libexiv2 0.18.2 won’t compile on Ubuntu Oneiric because gcc 4.6 is stricter by default than gcc 4.5).

The one feature that was introduced in pyexiv2 0.3.x that bumped the dependency on libexiv2 to ≥ 0.19 is exposing the IPTC charset as a property (see bug #461847 for details). After commenting out this feature, the code compiles and most of the unit tests pass: unsurprisingly three unit tests related to the IPTC charset property fail, and more puzzling, 4 other tests are in error state with a traceback similar to this:

    Traceback (most recent call last):
      File "/tmp/pyexiv2-0.3.2/test/exif.py", line 195, in test_convert_to_python_sshort
        tag = ExifTag('Exif.Image.TimeZoneOffset')
      File "/tmp/pyexiv2-0.3.2/src/pyexiv2/exif.py", line 103, in __init__
        self._tag = libexiv2python._ExifTag(key)
    KeyError: "Invalid tag name or ifdId `TimeZoneOffset', ifdId 1"

There are therefore two issues:
   1) Figuring out whether the IPTC charset functionality can be implemented in pyexiv2 itself instead of relying on libexiv2’s implementation.
   2) Understanding the cause for the error of the 4 other unit tests, and fix it.

Unfortunately this appears to be rather non-trivial. I’d recommend upgrading to libexiv2 0.19 if that’s an option.

Revision history for this message
Matěj Cepl (mcepl) said :
#2

"given it is RHEL it is quite unlikely that RHEL package would be rebased " ... it is in RHEL means that it is in the part maintained by Red Hat employees. So, unless some paying customer (large enough to ask for rebase) is involved, there is no chance this happeninig. Would it be possible to at least provide somewhere a failing patch, please, so I have something to start on.

Revision history for this message
Olivier Tilloy (osomon) said :
#3

I understand that…
Here is a minimal patch that fixes the compilation against libexiv2 0.18.2:

=== modified file 'src/exiv2wrapper.cpp'
--- src/exiv2wrapper.cpp 2011-08-20 10:15:11 +0000
+++ src/exiv2wrapper.cpp 2011-11-14 10:47:38 +0000
@@ -521,15 +521,7 @@
 const std::string Image::getIptcCharset() const
 {
     CHECK_METADATA_READ
- const char* charset = _iptcData->detectCharset();
- if (charset != 0)
- {
- return std::string(charset);
- }
- else
- {
- return std::string();
- }
+ return std::string();
 }

Obviously, this breaks the functionality of the iptc_charset property. More clever patches are more than welcome!

Revision history for this message
Matěj Cepl (mcepl) said :
#4

With the patch at http://mcepl.fedorapeople.org/tmp/exiv-0-18-2.patch I am able to get all the way down to this failed test, but I am not sure I should just blindly remove them. Isn't Exif.Image.DateTimeOriginal supposed to be supported? What's going on here?

======================================================================
ERROR: test_mutablemapping (metadata.TestImageMetadata)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/matej/archiv/2011/projekty/pyexiv2/pyexiv2-0.3.2/test/metadata.py", line 655, in test_mutablemapping
    tag_date = ExifTag(key, correctDate)
  File "/home/matej/build/BUILDROOT/pyexiv2-0.3.2-1.el6.x86_64/usr/lib64/python2.6/site-packages/pyexiv2/exif.py", line 103, in __init__
    self._tag = libexiv2python._ExifTag(key)
KeyError: "Invalid tag name or ifdId `DateTimeOriginal', ifdId 1"

---------------------------------------------------------------------

Also, tests test_convert_to_python_sshort and test_convert_to_string_sshort are actually not testing Exif.Image.TimeZoneOffset, but just data conversion. Would you have some better key to use for testing?

Revision history for this message
Launchpad Janitor (janitor) said :
#5

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Olivier Tilloy (osomon) said :
#6

Re-opening, the Launchpad Janitor was too swift in marking it expired, I haven’t had time to take a look at Matej’s findings yet.

Revision history for this message
Olivier Tilloy (osomon) said :
#7

Sorry for the very late answer. I took a look at the remaining failing tests (still testing in Ubuntu Natty, compiling pyexiv2 0.3.2 against libexiv2 0.18.2) and I managed to come up with a patch that fixes them all. Here it is: http://tilloy.net/dev/pyexiv2-0.3.2-exiv2-0.18.2.patch

With this patch all the unit tests pass, but note that the iptc_charset property won’t work (it’s basically left unimplemented). So you probably want to:
 - either make it very clear in the package’s documentation
 - or (even better) find a way to re-implement it in pure python

I hope this helps!

Revision history for this message
Matěj Cepl (mcepl) said :
#8

Yes, looks like working. Thank you

Revision history for this message
Matěj Cepl (mcepl) said :
#9

I understand that property iptc_charset won't work with pyexiv2 because it uses functionality unsupported in the old exiv2. But why cannot I set Iptc.Envelope.CharacterSet property directly to the magic value '\x1b%G' Shouldn't just pyexiv2 not care in such situation?

When I try to do so I get traceback like in https://bugzilla.redhat.com/show_bug.cgi?id=749473#c6:

mitmanek:~ $ jbrout
The psyco module does not seem to be installed. It is not necessary, however it
can speed up performance.
/usr/share/jbrout/jbrout.py:949: DeprecationWarning: Use the new widget
gtk.Tooltip
  self.tooltips = gtk.Tooltips()
/usr/share/jbrout/jbrout/winshow.py:108: DeprecationWarning: Use the new widget
gtk.Tooltip
  self.tooltips = gtk.Tooltips()
Traceback (most recent call last):
  File "/usr/share/jbrout/jbrout/winshow.py", line 217, in
on_WinShow_key_press_event
    currentNode.addTag(tag)
  File "/usr/share/jbrout/jbrout/db.py", line 745, in addTag
    if pc.add(tag):
  File "/usr/share/jbrout/jbrout/tools.py", line 392, in add
    self.__majTags()
  File "/usr/share/jbrout/jbrout/tools.py", line 481, in __majTags
    self.__maj()
  File "/usr/share/jbrout/jbrout/tools.py", line 486, in __maj
    self.__info.writeMetadata()
  File "/usr/share/jbrout/jbrout/pyexiv.py", line 47, in writeMetadata
    self._md["Iptc.Envelope.CharacterSet"] = ['\x1b%G',] # set Charset as UTF8
  File "/usr/lib64/python2.6/site-packages/pyexiv2/metadata.py", line 271, in
__setitem__
    return getattr(self, '_set_%s_tag' % family)(key, tag_or_value)
  File "/usr/lib64/python2.6/site-packages/pyexiv2/metadata.py", line 232, in
_set_iptc_tag
    tag = IptcTag(key, tag_or_values)
  File "/usr/lib64/python2.6/site-packages/pyexiv2/iptc.py", line 102, in
__init__
    self._set_values(values)
  File "/usr/lib64/python2.6/site-packages/pyexiv2/iptc.py", line 208, in
_set_values
    self.raw_value = map(self._convert_to_string, values)
  File "/usr/lib64/python2.6/site-packages/pyexiv2/iptc.py", line 171, in
_set_raw_values
    self._tag._setRawValues(values)
ValueError: Invalid value
mitmanek:~ $

Revision history for this message
Olivier Tilloy (osomon) said :
#10

This looks like it’s an issue with libexiv2 itself. I can observe the error with version 0.18.2, but the same code works fine with libexiv2 0.19 and above.

Looking at libexiv2’s changelog, revision 1975 (http://dev.exiv2.org/projects/exiv2/repository/revisions/1975) may be related.

Revision history for this message
Matěj Cepl (mcepl) said :
#11

OK, I gave up. In the end there are so many problems with trying to make pyexiv2 0.3.* working with old exiv2, and in the same time pyexiv2 0.1.* is missing so much stuff that in the end I have rather created a parallel installable version of exiv2 0.22 for RHEL-6.