Bug #663

Failure to write to Jpeg from Canon Ixus - digikam bug 214636

Added by Marcel Wiesweg almost 12 years ago. Updated over 5 years ago.

jpeg parser
Target version:
Start date:
20 Dec 2009
Due date:
% Done:


Estimated time:


Exiv2 fails to write to the sample images provided with digikam bug 214636
( )
Output on command line:

exiv2 -M "set Xmp.dc.subject XmpBag Cuisine,Test" "/media/fotos/Digikam Sample/JPEG/BugTag-214636/Photo2-beforemodif-tagCuisine.JPG"

Warning: Directory Image, entry 0x0001 has unknown Exif (TIFF) type 0; setting
type size 1.
Exiv2 exception in modify action for file /media/fotos/Digikam
Input data does not contain a valid image

See also


Related issues

Related to Exiv2 - Bug #533: Support multiple APP13 Photoshop 3.0 segments in a JPEGClosed


Associated revisions

Revision 1961 (diff)
Added by Andreas Huggel almost 12 years ago

#663: Removed check for complete PS data.

Revision 1963 (diff)
Added by Andreas Huggel almost 12 years ago

#663: Reverted change made in r1961.



Updated by Andreas Huggel almost 12 years ago

  • Category set to jpeg parser

The image Photo2-beforemodif-tagCuisine.JPG has a weird JPEG structure: It contains two APP1 segments with XMP data (when there should be only one) and two APP13 Photoshop 3.0 segments, both of which are "invalid or incomplete" but (at least) one of them contains valid IPTC metadata. The worst is that it says 'digiKam' in all of the metadata, so I wonder whether Exiv2 was involved in creating this... but I'm not sure and have certainly never seen Exiv2 create such a mess.

Marcel, do you have any idea what happened to that picture? Any way to reproduce this?

I have checked-in a quick "fix", with which the command in the bug report works and which doesn't break any existing tests. As a result, the two APP13 segments are concatenated and written to only one APP13, but it still has invalid IRB data. Both Exiv2 and Exiftool seem to be able to deal with the resulting image.

Michael, Volker, could you please review whether that simple change is acceptable?



Updated by Michael Ulbrich almost 12 years ago

Hi Andreas, all,

the original Photo1-beforemodif-tagLyon.JPG and Photo2-beforemodif-tagCuisine.JPG in both basically contain the same - "weird" as Andreas says, and I second that - metadata structure:

APP0, APP1 (EXIF), APP1 (XMP), APP13 (only IPTC IRB), APP13 (only IPTC IRB), APP1 (XMP).

APP13 / IRB / IPTC-Tag structure and lengths of both APP13 markers in Photo1 are correct, while IRB length of the first APP13 marker in Photo2 is wrong, which is the reason for the trunk version of exiv2 bailing out on this one. A fixed version Photo2-beforemodif-tagCuisine_corr.JPG is attached.

But that's a minor problem, the real problem IMHO lies in the "magic" duplication of APP markers.

Before we start to find a way how to gracefully modify this metadata structure, we should try to find out where and why this data originated. The situation is promising: Why not ask the author of the original report at about the particular steps of his workflow. If - and that's my assumption - after camera download these images' metadata has only been modified by digicam/exiv2, it should be fairly straight forward to find the bug in the software packages involved.

So much for now ... Michael


Updated by Volker Grabsch almost 12 years ago

The change introduced in revision 1961 is dangerous and should be reverted immediately.

The change disables a security mechanism which ensures that broken (or better: non-understood) APP13 sections are never overwritten. Without that mechanism writing IPTC metadata will cause data loss, because it would remove the non-understood APP13 sections.

Instead, we need to find the cause of the trouble. We need to clarify where exactly the broken APP13 marker was generated.



Updated by Andreas Huggel almost 12 years ago

Thanks for the feedback, Michael and Volker. I've asked on the digiKam bugtracker and since it's more important to find out if there is a bigger problem here, I'll back out the change and we'll wait and see if more such images with duplicated segments show up.



Updated by Andreas Huggel almost 12 years ago

  • Status changed from New to Feedback

Updated by Robin Mills about 6 years ago

  • Target version set to 53

Updated by Robin Mills over 5 years ago

  • Target version changed from 53 to 1.0

I haven't studied this matter. I'd dumped it in "Review", however I'm going to move it to Target 1.0. It might get attention in v0.27. I haven't opened target v0.27 yet. I'm hoping to close most of the review items, however this issue deserves attention.

Also available in: Atom PDF