Draft: Add OpenRaster (*.ora) decoder #10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a minimal OpenRaster decoder that just checks the file format and decodes the
mergedimage.pngcomposite image. (OpenRaster images are ZIP files that contain PNG layers, an XML file describing how to compose the layers, a thumbnail image, and a composite image.) The format is specified at https://www.openraster.org/baseline/file-layout-spec.html and is supported by ImageMagick.I created the test image and license it to match
image-extras. In general, multi-layer OpenRaster files can be exported by Krita and Gimp.This is marked as a draft for now, because
register_decoding_hookhas no way to specify the encoding limits in advance, and I am still thinking about how best to handle this on theimageside. (Probably by addingimage::hooks::register_decoding_hook_with_limits...)This adds an (optional) dependency on the relatively complicated
zipcrate andouroboros. These dependencies could be avoided with a few hundred to thousand lines of code to scan the ZIP headers and extract the relevant subfiles -- the OpenRaster spec only permits basic (deflated, stored) ZIP compression methods, so directly parsing it is not impossible if thezipcrate proves too inflexible.This is fourth on the list of formats I would like
image-extrasto support (XPM>XBM>SGI>ORA), since I don't really run into this file type in practice (I mostly made this PR to see how it exercises theimagecrate's abstractions, at which point making it usable wasn't too much work).