[Kde-imaging] [Bug 144604] Rotation causes Exif data corruption

[Isaac Wilcox]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=144604         




------- Additional Comments From iwilcox iwilcox me uk  2007-04-27 04:02 -------
It seems we're losing focus here - but I think I've found the bug anyway.  The problem is definitely KExiv2.  Here's why:

The KExiv code Gilles pasted uses QSize::width() and QSize::height(), which return int (i.e. signed int); libexiv2 *really* doesn't care about types, and just uses operator=() overloading to decide what type to give the tag based on the RHS of the assignment.  So when you pass an int, you invoke this libexiv2 function (this is from libexiv2, src/exif.cpp, line 148 ish):
    Exifdatum& Exifdatum::operator=(const int32_t& value)
    {
        return Exiv2::setValue(*this, value);
    }


I think the best way to fix the problem is (strangely) to cast the number to a string first.  From the libexiv2 source it looks like this will force the library to choose the correct type by itself.  Depending on your QT version, something like this should work:
    d->exifMetadata["Exif.Image.ImageWidth"]      = QString::number(size.width()).toStdString(); // QT 4
    d->exifMetadata["Exif.Image.ImageWidth"]      = std::string(QString::number(size.width())); // QT 3


If that doesn't work, use a cast:
    d->exifMetadata["Exif.Image.ImageWidth"]      = (uint32_t)size.width();

I'd attach a patch, but I'd have to do loads of work to set it up, and it's 3am right now, and I've found the bug, and...and... :)

You may well find that Gerhard's GPS types issue is caused by the same kind of operator=() cleverness...

Happy hacking.