Open sunipkm opened 4 months ago
Image metadata handling is an area of this crate that I'd certainly like to improve. Our lack of support for image orientation and color profiles have both been longstanding issues.
Exactly what belongs in an ImageMetadata
struct will take some design. EXIF data and color metadata / ICC profiles should probably both be represented in some form, but I don't know exactly what that would look like. For instance, should they be binary blobs or further parsed?
I'd be a bit hesitant about transparently bundling the metadata into DynamicImage
and ImageBuffer
. It seems too likely for people accidentally write images containing out-of-date or sensitive information without realizing it. But I think it would be very workable for certain decoding methods to return a tuple of the image and the metadata, or for encoders to accept both the pixel data and image metadata separately
I can stand behind separating the image and the metadata, and instead providing the information to the encoders/decoders optionally. As for what is contained, we can probably take inspiration from existing formats and innovate in this space since there is no history of image
crate supporting metadata.
I would like to be able to add metadata to the images, e.g. timestamp, what device was used and with what setting to acquire the image, etc. The
image
crate offers a really nice interface to represent image data with a variety of pixel types, and is great as a common output format for an imaging interface. This would make the image crate a great fit for a common interface, similar to theindi
framework in C++.Adding the metadata information to the
image
crate can be done by adding a private membermeta: Option<ImageMetadata>
to theImageBuffer
struct, and exposing the necessary getters and setters forImageBuffer
andDynamicImage
.Additionally, the metadata should be written to the files saved. PNG supports storing metadata, and so do JPEG, WEBP etc. where EXIF metadata headers can be attached.