[Digikam-devel] [Bug 283013] Accelerating writing metadata back to image files

Andreas Huggel ahuggel at gmx.net
Fri Sep 30 07:13:53 BST 2011


--- Comment #3 from Andreas Huggel <ahuggel gmx net>  2011-09-30 06:13:52 ---
The Exiv2 write logic is optimized based on the image format and the kind of
changes to the metadata. The two classes of image formats are TIFF-like images,
where the metadata is not in a specific portion of the image but potentially
spread over the entire image (image == metadata) and images which keep the
metadata in a specific portion of the file (e.g., JPEG, PNG). The type of
changes distinguish "intrusive" and "non-intrusive" changes. If any metadata
tags are added, deleted or an existing metadata field is extended, the change
is intrusive and requires Exiv2 to re-serialize the entire metadata structure.
If an existing field is changed and its size is not extended (it can shrink),
then Exiv2 makes the change in-place, without rewriting the entire metadata.
This has the considerable advantage that the TIFF structure stays intact, even
if Exiv2 can't parse it. A typical examples for a non-intrusive change is
changing the Exif date/time of an image.

Writing works as follows:

                 intrusive    non-intrusive
                 ------------ -------------
TIFF-like      : copy         mmap
Metadata block : copy         copy*

"copy" means the file is re-written and re-named (its size changes)
"mmap" means the file is changed in-place (the file size remains the same)

* In this case, the metadata structure is changed in-place but the file is
copied and in the process, the new metadata block is inserted.

The only further optimization I can see is that in the case of images with a
metadata block and non-intrusive changes, it would be possible to change the
entire file in-place rather than only the metadata block.

For additional considerations (memory related), see

How does rsync work? Does it really operate on portions of a file (not only
modified files + compression)?


Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the Digikam-devel mailing list