Help save net neutrality! Learn more.

#110 Adding Geolocation removes MakerNotes from Pentax imgs

libexif (62)

This is mainly a _suspected_ bug in libexif, as I cannot verify it myself atm directly.

Here's what happens:

An application which uses libexif, i.e. Eye-Fi Helper, corrupts the Exif information in imgs generated by a Pentax K-5.
The corruption occurs when Eye-Fi Helper adds Geolocation data, by then removing the entire "Pentax" section as well as the "Lens ID" information, making automatic lens detection impossible with such modified imgs.

Of course, it's not 100% sure that this isn't a fault of some other component. As I'm not the developer of the Eye-Fi software, I can only deduct that there's a good possibility this is caused by libexif.

To see the results of what happens, see this forum thread (started by me):

As you can use the orginal img from that post, you could verify whether it's actually libexif that's at fault here.
(I've attached the sample imgs to this report as well.)

Of course, it would be great if the Eye-Fi development team would take care of this, looking into the cause of this bug and maybe even fix it in this open source themselves, but I am not that optimistic.

I also like to point out that the "exittool" by Phil Harvey doesn't suffer from such a corruption when adding geoloc data.



  • Thomas Tempelmann

    Sample img, before and after corruption

  • Dan Fandrich

    Dan Fandrich - 2012-03-02

    There's something definitely wrong with the MakerNote in the "geotagged" image. But when I compare the output of exif --show-mnote on the original picture and one modified by the exif tool, it's identical. I'm not yet convinced that it's a libexif problem until I know more about how Eye-Fi has modified the image.

    We have a test suite with some tests that look for exactly this problem, but I don't recall if there are any Pentax images in the suite. If you send me an original, raw image from this camera and disclaim copyright in it (a low-resolution, all-black image for reduced size is best), I'll add it to the test suite and this kind of problem (if there is one in libexif) should be caught in the future.

  • Thomas Tempelmann

    I had already attached a sample img for exactly that use. It's quite blank, and you are welcome to reduce it further, e.g. in size. It has no copyright note in it, just my name as creator. You have hereby my permission to use that attached sample for any purposes you like to use it for. There's nothing of value in that picture.

    I have also gotten a reply from Eye-Fi, confirming the issue.

    I have tried to build and test libexif on my OSX system, and while I could build the lib, I could not get the exit cmdline tool to build, due to undeclared macros during the configure phase.

  • Thomas Tempelmann

    • status: open --> closed-invalid
  • Thomas Tempelmann

    Good news!
    Eye-Fi support figured out that the issue doesn't appear with an older version of their Helper app (3.4.10 works, 3.4.26 doesn't).
    Both versions include the very same binary of "libexif.dylib", which suggests that the fault is not inside libexif.
    I guess, until proven otherwise, this bug can therefore be closed.

  • Dan Fandrich

    Dan Fandrich - 2012-03-05

    Thanks for following up on this. The image helped in diagnosing this specific problem, but I'm hesitant about adding it to the test suite since it's clearly been manipulated by an external program to change its size. If a bug in that external program has changed or corrupted the tags, then it will take time to debug and diagnose the problem if the test suite fails because of it, when the problem isn't in libexif at all. For that reason, I would rather have unadulterated images in the test suite for the camera compatibility tests.


Log in to post a comment.