#Exiftool example how to#
#Exiftool example code#

These designs are all part of my ultimate goal of making ExifTool integration into a Java application seamless, performant and easy. You can set the interval to anything you want or shut off the cleanup thread completely and manage cleanup yourself (just call close()). Also the cleanup thread only executes after extended periods of inactivity, not on a set schedule. In addition to the pre-condition checking, to ensure that usage of the class (namely in daemon mode) doesn't leak native OS processes as well as Input/OutputStreams used to communicate with them, the class provides an auto-cleanup thread that after a specified interval of inactivity (default is 10 mins) will shut down the external process cleanly and the read/write streams, making the idle instance of ExifTool lightweight and easy to keep around for re-use.ДЄll the resources are re-initialized on the next call to the class to parse more metadata so there is no need to throw out and re-create new instances.

#Exiftool example how to#

I knew myself (and anyone else using the class) would need a well designed API to allow for easy error recovery.ДЇor example, attempting to use ExifTool in daemon mode will cause the class to actually check the underlying install of ExifTool for support for that feature and throw an UnsupportedFeatureException with recommendations on how to work around the problem if it isn't supported. I didn't just want to wrap simple Process objects then throw my hands up in the air if something exploded. I was so pedantic with this exception handling and error recovery because the class is designed to allow you to utilize ExifTool in a high-availability environment like a busy web application. In addition to making use of ExifTool simple from Java, the class employs a considerable amount of precautions to minimize runtime issues as well as correctly catching and reporting any and all errors that can arise in well-documented ways (instead of letting surprise exceptions bubble up from core Java classes). The documentation on how to use the ExifTool class is extensive, covering everything from design to performance to thread safety. Using ExifTool in the new 'daemon mode' (-stay_open True cmd line) is also supported and turning on support for it is as easy as creating your ExifTool instance like so: ExifTool tool = new ExifTool(Feature.STAY_OPEN) ' Long: ' + valueMap.get(Tag.GPS_LONGITUDE)) ('Lat: ' + valueMap.get(Tag.GPS_LATITUDE) + Tool.getImageMeta(image, Tag.GPS_LATITUDE, Tag.GPS_LONGITUDE) In this initial release I support reading tag data (will add writing in a future release) and it is as simple as this: File image = // path to some image

#Exiftool example code#

My goal for the library isn't just to abstract out the external process execution code from the caller (like most of the other abstraction layers are seeming to do) but to actually design a wrapper so tightly integration and resilient (I will clarify what I mean here later), that you treat instances of your ExifTool class exactly as you would if ExifTool itself was written in Java. The project is under the commercial-friendly Apache 2 license. I just made the first public release this past week after incubating the project under the imgscalr project umbrella for a while. ExifTool (for Java) is designed to be a simple-to-use and robust Java abstraction of Phil Harvey's ExifTool.