There's one more change I think needs to go into libexif in this next
release. Since the last release, libexif has gotten a lot smarter about
adding mandatory tags and removing illegal tags in files when the data type
is not explicitly set. Few applications likely set the data type, including
the exif front-end, so users upgrading to 0.6.18 may be surprised that
some tags are now appearing and disappearing when they didn't used to.
It's also a bit misleading to users of the exif front-end since it now
shows tags that appear to have come from a JPEG file when they were
actually synthesized by libexif itself.
I'm planning on adding a --no-fixup option to the exif front end that stops
libexif from messing with the tags when loading them and restores something
closer to the previous behaviour. The implementation seems simple:
call exif_data_unset_option() on the
EXIF_DATA_OPTION_FOLLOW_SPECIFICATION options. Unfortunately, due to an
API deficiency, this is impossible to do when using an ExifLoader. These
options have to be unset on an ExifData, but by the time the app gets one
back from exif_loader_get_data() the damage has already been done.
There are two ways of fixing this. One is to add this function:
/*! Return the data read by the loader. The loader must
* already contain data from a previous call to #exif_loader_write_file
* or #exif_loader_write. The returned pointer is only guaranteed to be
* valid until the next call to a function modifying this #ExifLoader.
* \param[in] loader the loader
* \param[out] buf read-only pointer to the data read by the loader, or NULL
* in case of error
* \param[out] buf_size size of the data at buf
* \return allocated ExifData
void exif_loader_get_buf (ExifLoader *loader, const unsigned char **buf,
This provides another way to get data out of an ExifLoader (right now, the
only way is by creating an ExifData). This is really an API deficiency in
its own right and this function should probably be added regardless,
but it can also be used to solve the above problem since the user can then
create his own ExifData with the right options unset and pass in the
data from the ExifLoader through exif_data_load_data().
Another solution is to create exif_loader_get_data_opt() that works like
exif_loader_get_data() but takes in the ExifDataOption and ExifDataType
values to use instead of the defaults. This should work, but I'm not sure
the app will always know the ExifDataType before the EXIF data is read.
It also creates a new way of setting options, which somehow seems impure.
The last way is to create a exif_loader_get_data_pure() function that looks
exactly like exif_loader_get_data() but uses no or UNKNOWN values for
ExifDataOption and ExifDataType. The user can later call exif_data_fix()
after setting the options the way he wants to do the fixup. I dislike
this solution because it's possible some option in the future may need
to be set before the data is loaded from the file for it to work.
So, I think I'll implement exif_loader_get_buf() and see how that goes.
Hopefully, that will be sufficient and the other two functions won't be
needed, but I'd like to hear other people's opinions.
http://www.MoveAnnouncer.com The web change of address service
Let webmasters know that your web site has moved