Bug #626

Setting IPTC preview corrupts PNG image

Added by Andreas Huggel almost 8 years ago. Updated almost 8 years ago.

Status:ClosedStart date:06 Apr 2009
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:image format
Target version:0.18.2

Description

Andi,Andreas,

I can confirm that problem come from exiv2...

In libkexiv2 i have a small test program to update/create iptc preview
image in file:

http://lxr.kde.org/source/KDE/kdegraphics/libs/libkexiv2/test/setiptcpreview.cpp

Like you can see this code is very simple : it open file, create iptc
preview and save it to file. If you run it to a PNG image (not
corrupted, PNG CRC chunk where exif, iptc and xmp are stored become
wrong. Using showfoto to load image via libpng return error :

[test]$ exiv2 Forest.png
Exiv2::PngChunk::parseChunkContent: Failed to decode Exif metadata.
File name       : Forest.png
File size       : 1472580 Bytes
MIME type       : image/png
Image size      : 1024 x 768
Camera make     :
Camera model    :
Image timestamp : 2005:04:25 00:00:00
Image number    :
Exposure time   :
Aperture        :
Exposure bias   :
Flash           :
Flash bias      :
Focal length    :
Subject distance:
ISO speed       :
Exposure mode   :
Metering mode   :
Macro mode      :
Image quality   :
Exif Resolution :
White balance   :
Thumbnail       : None
Copyright       : (c) Darrell Gulin/Photodisc Red/Getty Images
Exif comment    : 3 �toiles

[test]$ ./setiptcpreview Forest.png
Exiv2::PngChunk::parseChunkContent: Failed to decode Exif metadata.
<unknown program name>(13989)/ KExiv2Iface::KExiv2::setImagePreview:
JPEG image preview size: ( 768  x  1024 ) pixels -  161145  bytes
<unknown program name>(13989)/ KExiv2Iface::KExiv2::save: File
Extension:  "png"  is supported for writing mode
Exiv2::PngChunk::parseChunkContent: Failed to decode Exif metadata.

[test]$ showfoto Forest.png
...
showfoto(14002)/digikam (core) Digikam::DImg::load:
"/home/gilles/Documents/Devel/SVN/trunk/kdegraphics/libs/libkexiv2/test/Forest.png" 
 : PNG file identified
libpng warning: zTXt: CRC error
libpng warning: zTXt: CRC error
libpng warning: iTXt: CRC error

I'm sure that i have tested indeep chunk writting mode with Exiv2 when
0.18 release have been done. Something is broken in current
implementation of Exiv2 from svn.

This is the PNG chunk layout documentation :

http://www.w3.org/TR/PNG/#5Chunk-layout

In Exiv2, CRC are computed to

http://dev.exiv2.org/repositories/entry/exiv2/trunk/src/pngchunk.cpp

Lines 514, 539, and 593...

Best

Gilles Caulier

2009/4/1 Andi Clemens <>:

Now I'm even more confused. The file I converted with imagemagick worked
before, now if I use it again with the RemoveRedEyes plugin, it produces the
error again and the red eyes disappear only when opened in the editor.

Right now I have to do other things, maybe tonight or tomorrow I will change
the metadata and check it again...

Andi

On Wednesday 01 April 2009 20:07:05 you wrote:

2009/4/1 Andi Clemens:

Ok so changing the metadata as you suggested is only for testing the CRC
error?

yes...

I thought it has something to do with the wrong displaying of the image
in AlbumUI but maybe it has?)...

I will alter the metadata now and see if the CRC error appears.

ok

Gilles

History

#1 Updated by Andreas Huggel almost 8 years ago

Gilles,

This is a small Exiv2-only program to do something similar. I can't
reproduce the issue with this and valgrind is happy (Note:
writeMetadata() writes a warning "Exiv2::PngChunk::parseChunkContent:
Failed to decode Exif metadata" but that doesn't seem to be related.
Tested with buf sizes between 30000 and 4000000. Can you see any
relevant difference to your program/KExiv2? Does valgrind complain
when you run your program?

#include <exiv2/image.hpp>
#include <exiv2/iptc.hpp>
#include <iostream>
#include <iomanip>
#include <cassert>

int main(int argc, char* const argv[])
try {

   if (argc != 2) {
       std::cout << "Usage: " << argv[0] << " file\n";
       return 1;
   }

   Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open(argv[1]);
   assert(image.get() != 0);
   image->readMetadata();
   Exiv2::IptcData& iptcData = image->iptcData();

   Exiv2::DataBuf buf(4000000);
   memset(buf.pData_, 0x0, buf.size_);
   Exiv2::DataValue val;
   val.read(buf.pData_, buf.size_);
   iptcData["Iptc.Application2.Preview"] = val;
   iptcData["Iptc.Application2.PreviewFormat"]  = 11;
   iptcData["Iptc.Application2.PreviewVersion"] = 1;

   image->writeMetadata();
   return 0;
}
catch (Exiv2::AnyError& e) {
   std::cout << "Caught Exiv2 exception '" << e << "'\n";
   return -1;
}

Regards,
Andreas

#2 Updated by Gilles Caulier almost 8 years ago

Andreas Huggel wrote:

Andi,Andreas,

I can confirm that problem come from exiv2...

In libkexiv2 i have a small test program to update/create iptc preview
image in file:

http://lxr.kde.org/source/KDE/kdegraphics/libs/libkexiv2/test/setiptcpreview.cpp

Like you can see this code is very simple : it open file, create iptc
preview and save it to file. If you run it to a PNG image (not
corrupted, PNG CRC chunk where exif, iptc and xmp are stored become
wrong. Using showfoto to load image via libpng return error :

[...]

I'm sure that i have tested indeep chunk writting mode with Exiv2 when
0.18 release have been done. Something is broken in current
implementation of Exiv2 from svn.

This is the PNG chunk layout documentation :

http://www.w3.org/TR/PNG/#5Chunk-layout

In Exiv2, CRC are computed to

http://dev.exiv2.org/repositories/entry/exiv2/trunk/src/pngchunk.cpp

Lines 514, 539, and 593...

Best

Gilles Caulier

2009/4/1 Andi Clemens <>:

Now I'm even more confused. The file I converted with imagemagick worked
before, now if I use it again with the RemoveRedEyes plugin, it produces the
error again and the red eyes disappear only when opened in the editor.

Right now I have to do other things, maybe tonight or tomorrow I will change
the metadata and check it again...

Andi

On Wednesday 01 April 2009 20:07:05 you wrote:

2009/4/1 Andi Clemens:

Ok so changing the metadata as you suggested is only for testing the CRC
error?

yes...

I thought it has something to do with the wrong displaying of the image
in AlbumUI but maybe it has?)...

I will alter the metadata now and see if the CRC error appears.

ok

Gilles

Andreas,

Sorry for my late response about this problem, but i have been very busy last week end.

I will investiguate indeep soon

Gilles Caulier

#3 Updated by Andreas Huggel almost 8 years ago

Gilles, do you still see this problem with new PNG write code?

#4 Updated by Gilles Caulier almost 8 years ago

Andreas Huggel wrote:

Gilles, do you still see this problem with new PNG write code?

No, no, it fixed now with current Exiv2 code...

Gilles

#5 Updated by Andreas Huggel almost 8 years ago

  • Status changed from New to Resolved
  • Target version set to 0.18.2

#6 Updated by Andreas Huggel almost 8 years ago

  • % Done changed from 0 to 100

#7 Updated by Andreas Huggel almost 8 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux