pyexiv2-developers team mailing list archive

[Olivier Tilloy <olivier@xxxxxxxxxx>]

Hi Lars,

Lars Wirzenius a écrit :
> Hi,
> 
> I'm using pyexiv2 in a project of mine, and I'd like to list my current
> wishlist items. I'm curious if they're happening already, and if not, if
> there's something I can do make things happen faster.

A quick status on pyexiv2: I currently avoid maintaining the 0.1 branch
(the latest release being 0.1.3) because of its known architectural
limitations that make the bugs not easy to solve and regression-prone.
On top of that I have too little time to dedicate to the project so all
my efforts are currently directed towards the 0.2 branch.
The main highlights of this version are:
 - a redesigned architecture that makes it more flexible and robust (and
will eventually be fully unit-tested)
 - full support of XMP
 - fix all the known issues and limitations in the 0.1 branch
 - tested and distributed on windows as well as linux

> * XMP read and write: I would like to import and export image meta data
> in this format to be compatible with other software that uses it.

As mentioned above, XMP will be fully supported in the 0.2 branch (I
already have partial support, but it's pretty experimental at the moment).

> * Parsing of Exif headers: I have not been very happy about the current
> Exif header parsing. My app stores the Exif headers in a database (for
> quick access). Image.__getitem__ returns different kinds of values
> depending on the header, and Image.interpretedExifValue returns a string
> whose formatting I am not always happy with (e.g, "F1.4" instead of
> "f/1.4"). I'd like to have access to less interpreted kinds of values so
> I can format them myself. I may also need to set the Exif headers in
> more flexible ways than currently is possible, but I haven't yet
> experimented with this, so I'm not sure. Possibly this will all apply
> for IPTC headers as well.

The new architecture will give you access to the raw value as returned
by libexiv2 (which is what you seem to be asking for), the interpreted
value converted as a python type, and the human-readable formatted
value. It will also allow you to set either the raw value or the
interpreted value, with changes reflected to either automatically.

> Once these things work I will also need to have them included in
> releases of major Linux distros so my app can easily depend on them.
> Would these features be best done in the 0.2 branch if so, when is that
> expected to land in distros?

Unless you volunteer to maintain the 0.1 branch, that will be in the 0.2
branch, and I don't have an ETA. I've tried to plan this in the past but
I failed to do so because the amount time I can dedicate to the project
is quite unpredictable and varies over time (with the constant that it's
never as much as I would like).

> I'm willing to help on these features, but before I dive into the code,
> I thought I'd ask what the current status and plans are.

The code base in the 0.2 branch is unfortunately not solid enough to
start hacking on it yet, but I'm hopefully not far from a state where I
can invite external contributors to start testing it and writing
patches. I'll sure let you know when that happens.

Cheers,

Olivier