https://bugs.kde.org/show_bug.cgi?id=468830
--- Comment #34 from [email protected] --- >Why not to bypass exiv2 when it fails ? (only if user set "delegate to >Exiftool writing operations"). Of course, I have no idea whether such a fix is >reasonably feasible, it is just a suggestion. Because actually we cannot. Internally digiKam use the Exiv2 container to host metadata chunk as Exif. It's due to the story as Exiv2 is a prior solution used by digiKam to deal with metadata. The ExifTool support is a work around to enable extra IO files support that Exiv2 fail. We pass the Exiv2 container to ExifTool and this one flush the chunks to the files. The same mechanism is used to read. There are possible solutions to this problem: 1 - Exiv2 must be fixed to support large Exif chunk. There is an old report in Exiv2 bugzilla about this problem. See comment 6 for details. 2 - Port whole digiKam metadata engine to pure ExifTool. This require a large code to rewrite and test. We don't plan to do it. Also the performance of ExifTool due to Perl usage will be lower than a native C++ library as Exiv2. 3 - Use a work around with ExifTool to patch and merge the Exif large Exif chunk. I don't know if this way already exists. Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
