Bug #626
Setting IPTC preview corrupts PNG image
| Status: | Closed | Start: | 06 Apr 2009 | |
| Priority: | Normal | Due date: | ||
| Assigned to: | - | % 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 <andi.clemens@gmx.net>:
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
Updated by Andreas Huggel 341 days 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
Updated by Gilles Caulier 341 days 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 <andi.clemens@gmx.net>:
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
Updated by Andreas Huggel 268 days ago
Gilles, do you still see this problem with new PNG write code?
Updated by Gilles Caulier 268 days 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
Updated by Andreas Huggel 268 days ago
- Status changed from New to Resolved
- Target version set to 0.18.2
Updated by Andreas Huggel 267 days ago
- % Done changed from 0 to 100
Updated by Andreas Huggel 263 days ago
- Status changed from Resolved to Closed