Support writing metadata

[drewnoakes]

Currently metadata-extractor provides a read-only view onto the metadata within files.

Several use cases would benefit from or require the ability to write data back to files, such as comments, GPS location, image orientation, image size...

The implementation of this feature is non-trivial. Not all types of metadata can or should be modified, and of course there is a high cost associated with bugs that occur when people are overwriting their files, should images be lost.

Given that the library supports many types of metadata, it's more realistic to roll out support for writing different types of metadata incrementally. The first type to be attempted should probably be Exif and the first container type would likely be JPEG.

(Migrated from Google Code issue 66)

[lilith]

I think the highest priority (for us) would be copyright/comments exif, as preservation of that data is frequently required by law.

[swolf91]

I would like to have this feature. I'm interested in changing the date of the picture creation. This could eliminate a wrong time which was set with the camera.

[jt-gilkeson]

I ended up using org.apache.commons:commons-imaging:1.0-SNAPSHOT for this functionality, but would definitely prefer if your library provided this functionality.

[saurabheights]

Hi Drew, do you have any design/constratints/requirements etc. to start working on this feature? Any comments will be helpful. I would love to contribute but don't want to step over any progress.

[svaens]

I guess there hasn't been enough demand for this? Too bad! Here's one more "vote"!

I for one would be interested in the ability to modify (add/edit/remove) tags, and basic metadata such as description, title, creation date, author of an image file such as jpg and png. There seems to be no real good library for this.

[drewnoakes]

@svaens there's definitely demand, but unfortunately demand doesn't offset the complexity and effort required, nor the need for higher quality control as we risk damaging people's precious files.

Another big part of the challenge here is how foundational it is. It will likely change the entire nature of the API and its implementation. That might be a good thing, as some of the innards are quite old and designed by a much younger and less experienced verison of yours truly. There have been some initiatives to come up with improved designs, but it'll take a good investment of time.

[StefanOltmann]

Upon further investigation into the architecture of metadata-extractor, I realized that it is more proficient in reading metadata compared to Apache Commons Imaging. However, it became evident that implementing write support would require significant effort, as the current codebase skips crucial data necessary for writing. While metadata-extractor has been instrumental in supporting read operations for my application over the past two years, I now find myself in need of write functionality. Consequently, I initially transitioned to Apache Commons Imaging, and when faced with a similar requirement for iOS, I opted to rewrite the metadata handling portion in Kotlin. I have made my work available on GitHub under the following repository: https://github.com/RealAshampoo/kim

If I had identified a viable approach to integrate comprehensive write support, I would have preferred to port metadata-extractor to Kotlin Multiplatform.

Nonetheless, metadata-extractor remains an invaluable resource for understanding how to handle certain problematic files. I am grateful for this excellent library.

[Webreaper]

I found a good compromise was to use metadata-extractor for reading metadata, and then I use exiftool running as a child process to do the writing. Since the majority of my interaction is RO, that works from a code simplicity and performance perspective, and for RW ops calling out to exiftool gives me the confidence that my app is using the best exif manipulation tool available, and the one least likely to damage users' files.

[StefanOltmann]

I found a good compromise was to use metadata-extractor for reading metadata, and then I use exiftool running as a child process to do the writing. Since the majority of my interaction is RO, that works from a code simplicity and performance perspective, and for RW ops calling out to exiftool gives me the confidence that my app is using the best exif manipulation tool available, and the one least likely to damage users' files.

I fully agree with you here. Exiftool is the best and most reliable tool for writing. That's why I also use it for comparisons. Apache Commons Imaging has indeed an open bug in 1.0-alpha3 that damages the files (as discussed in https://github.com/apache/commons-imaging/pull/275). By porting the code to Kotlin and testing it, I noticed the problem, found the solution, and included that fix in Kim. So, nonetheless, I would have used a fork of Commons Imaging due to this problem.

I hesitated to include Exiftool in my closed-source commercial app due to two reasons: First, there is some uncertainty regarding the license (they talk about Perl Artistic License and how they interpret GPL there), and second, I would have needed some wrapper code for the Perl library. On JVM, I could simply use the binary with Runtime.exec() or some third-party wrapper. But how to solve it on Android and iOS?

A pure-Kotlin Multiplatform implementation is certainly more work at first, but when all the bugs are ruled out and it has matured, I think it's the cleanest solution that requires the least amount of code to run on all platforms.

Is your app only on the JVM? Is it a commercial app?

[Webreaper]

Is your app only on the JVM? Is it a commercial app?

My app is here: http://github.com/webreaper/damselfly - it's an FOSS Blazor app.