There are two parts to this bug, both having to do with PMT_READONLY mode not working properly in
PMT. The two parts to this bug are listed next to "1.)" and "2.)" below.
1.) If an Exif Accessor is opened in PMT_READONLY mode (the default), no errors are thrown (even if
throwErrors() = true; is called) when an attempt to call writeMetadata(...) is made. It is true, that the file
on disk is not modified, but an error of some type should be thrown in such cases.
This can be illustrated by copying the following code into the AccessorTest test program. Notice the
code below next to the three exclamation (!!!) points.
#include "PmtDefinitionInterpreter.h"
#include "PmtAccessor.h"
#include "PmtMisc.h"
// Make sure the implementations are linked and
// loaded into the Accessor factory.
#if defined(HAVE_KIESEXIF) || defined(HAVE_OPENEXIF)
PMT_REQUIRE(PmtExifAccessor)
#endif
int main()
{
try
{
string inputImageFile = "Kodak_DC220.jpg";
string outputImageFile = "test2.jpg";
// Create the Logical Defn Interpreter
// and load the default metadata defns.
PmtLogicalDefinitionInterpreter interpreter;
interpreter.load();
PmtCopyFile(inputImageFile.c_str(), outputImageFile.c_str(), true);
PmtAccessorPtr acc = PmtAccessor::create(PMT_FORMAT_EXIF);
PmtMetadataPtr mdRoot = PmtMetadata::create();
PmtMetadataPtr md;
acc->throwErrors() = true;
md = mdRoot->getMetadatum("CaptureConditions.Aperture");
// !!! This is where if PMT_READWRITE is not specified, we would
// expect to get an error (but don't)!
acc->open(outputImageFile.c_str());
//acc->open(outputImageFile.c_str(), PMT_READWRITE);
acc->readMetadata(md);
cout << "Value before write should be 4.5" << endl;
md->show();
md->setValueStr(EK_L("2.8"));
acc->writeMetadata(md);
acc->close();
acc->open(outputImageFile.c_str());
mdRoot->deleteMetadata("CaptureConditions.Aperture");
acc->readMetadata(md);
cout << "Value after write should be 2.8" << endl;
md->show();
}
catch (PmtError& e)
{
cout << e << endl;
exit(1);
}
catch (...)
{
cout << "**** Some Exception caught." << endl;
}
return 0;
}
2.) If the file is not closed, after a writeMetadata(...) call, a subsequent call to readMetadata(...) returns
the incorrect value. It acts as if the writeMetadata(...) was successfull. This is incorrect because a.) the
file does not really have the value returned from readMetadata(...), and b.) the value returned is probably
cached in the Kies toolkits memory.
See the following code below, noting the three exclamation points (!!!)...
#include "PmtDefinitionInterpreter.h"
#include "PmtAccessor.h"
#include "PmtMisc.h"
// Make sure the implementations are linked and
// loaded into the Accessor factory.
#if defined(HAVE_KIESEXIF) || defined(HAVE_OPENEXIF)
PMT_REQUIRE(PmtExifAccessor)
#endif
int main()
{
try
{
string inputImageFile = "Kodak_DC220.jpg";
string outputImageFile = "test2.jpg";
// Create the Logical Defn Interpreter
// and load the default metadata defns.
PmtLogicalDefinitionInterpreter interpreter;
interpreter.load();
PmtCopyFile(inputImageFile.c_str(), outputImageFile.c_str(), true);
PmtAccessorPtr acc = PmtAccessor::create(PMT_FORMAT_EXIF);
PmtMetadataPtr mdRoot = PmtMetadata::create();
PmtMetadataPtr md;
acc->throwErrors() = true;
md = mdRoot->getMetadatum("CaptureConditions.Aperture");
acc->open(outputImageFile.c_str());
md->setValueStr(EK_L("2.8"));
acc->writeMetadata(md);
mdRoot->deleteMetadata("CaptureConditions.Aperture");
acc->readMetadata(md);
//!!! This value should NOT be 2.8, since modification of the file
// will not happen on disk. The returned value of 2.8 is only
// laying around in the memory of the Kies toolkit.
cout << "Value after write should NOT be 2.8" << endl;
md->show();
}
catch (PmtError& e)
{
cout << e << endl;
exit(1);
}
catch (...)
{
cout << "**** Some Exception caught." << endl;
}
return 0;
}
Logged In: YES
user_id=112680
In the #2 case, the toolkit should not be getting updated with the writeMetadata(...) values at all. This could
probably be nipped in the bud by inspecting the value of the open flag (PMT_READWRITE, etc.).
Also, as a potential third part to this bug, find out if Kies needs to be fixed too. If so, let someone know.
Logged In: YES
user_id=112680
Also, as a fourth part to this issue, inspect the TIFF and XML Accessors for similar issue. If there are issues in
the other Accessor, open new bugs up for each of them. If APS comes into the picture, inspect its behavior too.