Exiv2

Hi Malcolm,

Something like

std::string val = tag.print(&exifData);

should do the trick. See this post for details.

Andreas

Duh! Perfect, thank you!

This is all quite a change from Perl and Exiftool. My C++ is rusty to say
the least, and to makes matters worse, I'm much more familiar with CString
than std::string (which I think is more of a handicap than a help here).

tag.print() should allow me to finish prototyping this part of my app. Then
I'll start looking at some other libraries I need and then make a decision on
what String/Array/Map classes to use.

I'll need to study some performance characteristics and I have noticed
some weirdness -- recursing over a directory structure of files, it
periodically slows down while memory usage increases dramatically.
Then memory falls back and processing accelerates again. Maybe it's
a debugger thing but I might be back if I can get the issue more
fully characterized.

I will be looking for some tools to handle and render JPEGs (including those
embedded within RAW files which I believe I can extract with exiv2). I also
want to resize, make thumbs, scale (with interpolation) and add color
management (LCMS?). Longer term, maybe a database (SQLite?).

Any general pointers on tools that play nice (or otherwise) with exiv2
very much appreciated. It seems like you guys have already walked a
similar path ;-)

some weirdness -- recursing over a directory structure of files, it
periodically slows down while memory usage increases dramatically.

The only known performance issue I am aware of is #677. It's related to Nikon Makernotes and only exists in 0.19. So make sure you use version 0.20. In any case, if you do think this has anything to do with Exiv2 please let us know.

-ahu.

Thanks for that. I am already running 0.20.

Definitely seeing some large (100MB) memory surges when recursing over many
thousands of files, extracting EXIF/IPTC (no XMP and no write operations).
These are mainly NEF and JPEG but there are some other oddball files and I am
catching/ignoring a few exiv2 exceptions on those. Currently about 50
exceptions on 20,000 files.

I will at least take those bad files out of the equation tomorrow and see what
happens. If memory usage is still weird I'll see what else I can find.

Well, the wild memory usage is definitely coming from some non-image file type.
Limiting my processing to NEF and JPEG files solved that problem. I will get
back to this and see exactly which files are causing the issue; looks like
it's something that should be handled more elegantly. In the meantime...

I have cut my code right back to this:

Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open("C:\\ZIP\\DSC_0002.jpg");
image->readMetadata();
image = Exiv2::ImageFactory::open("C:\\ZIP\\DSC_0005.jpg");
image->readMetadata();

If I paste this into the sample exifprint program, all is well.

However, if I paste this code into a MFC application and execute it,
it seems to leak memory. I used a default MFC template as created
by VS2008. I have tried linking to the static and DLL versions of
exiv2.lib and it seems to happen with both. I think I have followed
all of the rules per README-MSVC.txt.

Any suggestions on how to find the cause of this?

I did notice that the dumped blocks contain a lot of URL references
(http://...) and perhaps they will provide some clue! I have
attached a listing.

Just to close the loop on the wild memory usage...

This is caused by some GPS track logs in the .gpx file format,
which is XML based.

Opening a largish (5MB) .gpx file causes a trivial app to grab
some 250MB of memory. The problem was made much worse because
I had failed to check for exifData.empty(). My bad :-(

I'm not sure if a formal report would be appropriate or not.
I'd be happy to submit one together with a sample file if
requested.

yes please attach a file. I suspect it somehow gets passed to xmp-sdk. For the memory leak, make sure you call XmpParser::terminate in case the XMP parser was used.

Excellent, thank you so much for that kind sir.

Calling XmpParser::terminate() does indeed fix the leak!

I have attached a sample GPX file (Zipped because it's quite compressible).

If you try to extract EXIF/IPTC from this file, exiv2 should grind for a
while and chew up gobs of memory in the process.

Malcolm

It sounds as though this XmpParser::terminate business is plugging the leak.

I'm rather surprised by what you're doing here. Are you reading the GPX file using XMP (hosted by exiv2)? I didn't know you could do that.

I wrote some python scripts a couple of years ago for geotagging. I read the GPX file with python's xml.dom.minidom module. I use exiv2 (via pyexiv2) to get the photo date and then write the exif GPS tags to the photos. Details and code at: http://clanmills.com/articles/gpsexiftags/

Robin

Robin,

It was an accident really. I was recursing over a large image collection and found
some GPX files mixed in with that. exiv2 kinda choked on those; I'm guessing
it saw XML and tried to interpret them like XMP. I've solved that problem
simply by filtering on the file extension. I probably should have done that
from the start by this was just a prototyping exercise.

I have been tagging my images using Perl, Exiftool and derivative of:

http://www.carto.net/projects/photoTools/gpsPhoto/

However, my plan is to move everything (including the tagging) to C++ and exiv2.

I'm quite sure that exiv2 will do everything I need. Now I just have to
figure out how to handle/render the actual images. Then I can tackle the
user interface and other grunt work ;-)

Ah. So you're saying library ate the .GPX and almost leaked memory in the process. How interesting. That explains why pyexiv2 used to ignore the GPX and now he's a little confused and thinks it's an image (so I added an extension filter to my script to ignore GPX).

Thanks for the pointer to the carto.net web site. I think Mr Carto was ploughing the same field in 2008 in Perl/exiftool that I ploughed in python in April 2008.

Although I don't know exactly what you're doing, I'm confident in the exiv2 library to deliver performance and functionality. I wrote my stuff 2 years ago and it's working well on Mac/Linux/Windows. I occasionally rebuild to keep up with Python (I'm now 2.6) and exiv2 (now at 0.21) and pyexiv2 (now at 0.2). A variant of my code ships in Phatch (an open-source photo batch processor).

So good luck with your C++ approach. Let me know if you need help.

The gpx file - and for that matter any XML file - is mistaken as an XMP sidecar file because it starts with .
I don't see a quick fix for this, will need to read up on how XMP sidecar files are supposed to look like to see if there is a more specific test. Suggestions welcome!