http://bugs.kde.org/show_bug.cgi?id=183171Andreas Huggel ahuggel gmx net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |
[hidden email],
| |
[hidden email]
--- Comment #1 from Andreas Huggel <ahuggel gmx net> 2009-02-04 14:10:34 ---
Comments from Marcel (from bug# 182738, comment 17):
> This means that our current getExif implementation is not
> lossless and not reversible.
Yes, that's correct. The first problem, which was always there,
is that unknown TIFF structures potentially get corrupted on
writing. The ability to write to TIFF images exposed another
problem: In a TIFF image, the metadata is the image and
vice-versa. There is no isolated block of data somewhere to store
the Exif data in. This means that the metadata must potentially
be changed to ensure that the image remains intact.
Therefore, "Encoding ExifData" should now always be thought of
as "encoding ExifData for a given image format" and is
potentially lossy. How lossy depends on the input data, i.e., the
source image format. (This problem doesn't apply to IptcData and
XmpData, these are reversible).
> - what you suggest is storing ExifData, IptcData, XmpData
> directly? This is your intended workflow?
Yes, to keep it in the Exiv2::*Data containers and only encode
it again, using the appropriate Parser class for the target image
format.
> - these classes use std::vector internally, which means copying
> is always a deep copy? (We would have to write a wrapper for
> Qt-style shallow copies)
Currently yes. What's the use-case that requires such a shallow copy?
I agree that copying the containers is also not desired, the simplest
way to avoid this is using references.
> - should ExifParser::encode be used for JPEGs only when you say
> it removes certain tags?
Yes, ExifParser::encode creates a binary block for a JPEG APP segment.
> - there are two ExifParser::encode methods. One has docs and says
> it does not do unintrusive writing, suggesting the other
> method. The other has no docs and requires a byte* buffer. Should
> this method be of any interest to us?
The second method should be used if original binary metadata is
still available. This is the case, eg, if the metadata is read
from a JPEG, modified and written back. (in this case
Exiv2::Image does this internally, you don't need to call the
Parser directly.) I'll add to the documentation.
-ahu.
--
Configure bugmail:
http://bugs.kde.org/userprefs.cgi?tab=email------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
