Open fintelia opened 2 months ago
This seems like a pretty large undertaking, and would be difficult to design in one go and without prototyping first. But long-running branches suck because of editing conflicts.
How about we get started on this in-tree, but gate the whole thing behind a non-default feature such as metadata-I-know-this-is-unstable
? This will let us prototype in-tree and get initial feedback from the interested users, without mega-branch that will burn out the authors with conflicts.
roxmltree
could be a good candidate for XML parsing. It was written for resvg
because other XML parsers were too complex and bloated. It has zero dependencies, 100% safe code, and has been extensively tested as part of resvg
.
That doesn't solve writing XMP because "ro" stands for "read-only". But I guess we can feature-gate the functions relying on the parsed XML (if any) and let the users bring their own XML parser?
Yeah, that could be helpful if we ever need to parse XMP metadata. Though I think we could actually implement a bunch of the basic functionality without ever having to do that. Just having a way for the user to get the blob of XML bytes and telling them to figure out how to parse it if they care what's inside would probably be enough to start with.
I like the idea of experimenting behind a feature flag. For the ImageDecoder::{exif_metadata, xmp_metadata}
(and maybe orientation
) methods, I think the API is clear enough that we could skip that step, but for the bigger pieces it would be a nice assurance that we aren't going to back ourselves into a corner right away.
This crate currently has limited support for handling image metadata. Taking a bit of time to jot down some thoughts on how we might be able to add support for basic image metadata. This is very much still a draft
Structure of metadata
Basing on what what metadata can be stored in PNG images (though other formats are similar) we might want to represent metadata something like:
Decoding API
Conversions
Encoding
TODO