Bug #471

NEF files show strange comment in digikam

Added by bluesceada - almost 11 years ago. Updated over 8 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:Andreas Huggel% Done:

0%

Category:exif
Target version:0.11

Description

If you look at the comment of Nikon .NEF files, there is something like "65 83 67 73 73 0 0 0 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 " as the comment.
It seems to just happen sometimes, but can't tell at the moment what is different to those files when it happens, and when not. I don't know exactly how to test it without digikam, so I'm not exactly sure if it's an exiv2 problem or something different.

History

#1 Updated by Andreas Huggel almost 11 years ago

That is a valid comment. The first 8 bytes read "ASCII\0\0\0" (which defines the charset in accordance with the Exif specs) followed by a number of spaces. Many cameras create similar comments in JPEGs and Exiv2 shouldn't have any problems dealing with these.

You say this happens only sometimes. What does the commment field contain in the other cases?

As for testing this, use the exiv2 (command line) utility or another Exif reader to investigate, eg., Exiftool or exifprobe.

-ahu.

#2 Updated by Andreas Huggel almost 11 years ago

I'm hijacking this bug report for the following, which may or may not be the same problem. Please open a new bug if it isn't.

From Marcel Wiesweg:

I have been tracking down a problem in digikam with the displaying of
UserComments.
The initial problem was that a UserComment which contains only 0x00 data was
displayed as "0 0 0 0...", but only in one place in digikam and not in the
other.

It seems that when the exif data from certain files is loaded from the file,
the UserComment is represented by a Exiv2::DataValue. But when it is loaded
from raw data, it is correctly created as a Exiv2::CommentValue.

Attached is a test program where I extracted the code we use in digikam for
the two places, where the first path does not work, the second does (it
reloads from raw data).

#include "image.hpp"
#include "exif.hpp"
#include <iostream>
#include <iomanip>
#include <cassert>

// Use with file http://digikam3rdparty.free.fr/TEST_IMAGES/RAW/HORIZONTAL/MINOLTA-DYNAX7D-02.MRW

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

if (argc != 2) {
std::cout << "Usage: " << argv[0] << " file\n";
return 1;
}
// load Exif
Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open(argv[1]);
assert(image.get() != 0);
image->readMetadata();
Exiv2::ExifData &exifData = image->exifData();
if (exifData.empty()) {
std::string error(argv[1]);
error += ": No Exif data found in the file";
throw Exiv2::Error(1, error);
}
// find UserComment
Exiv2::ExifKey key("Exif.Photo.UserComment");
Exiv2::ExifData::iterator it = image->exifData().findKey(key);
if (it != image->exifData().end())
{
const Exiv2::Value &value = it->value();
// this fails: the value is of type DataValue
std::cout << "Value from Exifdatum with key " << it->key().c_str() <<
" has type " << typeid(value).name() <<
" which should be " << typeid(Exiv2::CommentValue).name() << std::endl;
}
// get raw data
Exiv2::ExifData& exif = image->exifData();
Exiv2::DataBuf c2 = exif.copy();
unsigned char *data = new unsigned char[c2.size_];
memcpy(data, c2.pData_, c2.size_);
// load from raw data
Exiv2::ExifData exifDataReloaded;
exifDataReloaded.load((Exiv2::byte*)data, c2.size_);
exifDataReloaded.sortByKey();
// find UserComment
it = exifDataReloaded.findKey(key);
if (it != exifDataReloaded.end())
{
const Exiv2::Value &value = it->value();
// this is successful: the value is of type CommentValue
std::cout << "Value from reloaded Exifdatum with key " << it->key().c_str() <<
" has type " << typeid(value).name() <<
" which should be " << typeid(Exiv2::CommentValue).name() << std::endl;
}
return 0;
}
catch (Exiv2::AnyError& e) {
std::cout << "Caught Exiv2 exception '" << e << "'\n";
return -1;
}

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux