Decoder metadata interface #2672

197g · 2025-11-26T22:26:52Z

See #2245, the intended ImageDecoder changes.

This changes the ImageDecoder trait to fix some underlying issues. The main change is a clarification to the responsibilities; the trait is an interface from an implementor towards the image library. That is, the protocol established from its interface should allow us to drive the decoder into our buffers and our metadata. It is not optimized to be used by an external caller which should prefer the use of ImageReader and other inherent methods instead.

This is a work-in-progress, below motivates the changes and discusses open points.

ImageDecoder::peek_layout encourages decoders to read headers after the constructor. This fixes the inherent problem we had with communicating limits. The sequences for internal use is roughly:

let mut decoder = …;
decoder.set_limits(…); // Other global configuration we have?

{ // Potentially multiple times:
  let layout_info = decoder.peek_layout()?;
  let mut buffer = allocate_for(&layout_info);
  decoder.xmp_metadata()?; // and other meta
  decoder.read_image(&mut buffer)?;
}

// … for sequences, start again from `peek_layout()`

ImageDecoder::read_image(&mut self) no longer consumes self. We no longer need the additional boxed method and its trait work around, the trait is now dyn-compatible.

Discussion

mstoeckl · 2025-11-27T14:39:51Z

The main change is a clarification to the responsibilities; the trait is an interface from an implementor towards the image library. That is, the protocol established from its interface should allow us to drive the decoder into our buffers and our metadata. It is not optimized to be used by an external caller which should prefer the use of ImageReader and other inherent methods instead.

With this framing, I think Limits::max_image_width and Limits::max_image_height no longer need to be communicated to or handled by the ImageDecoder trait, because the external code can check ImageDecoder::dimensions() before invoking ImageDecoder::read_image(); only the memory limit (Limits::max_alloc) is essential. That being said, the current way Limits are handled by ImageDecoder isn't that awkward to implement, so to reduce migration costs keeping the current ImageDecoder::set_limits() API may be OK.

fintelia · 2025-11-27T18:04:35Z

A couple thoughts...

I do like the idea of handling animation decoding with this same trait. To understand, are you thinking of "sequences" as being animations or also stuff like the multiple images stored in a TIFF file? Even just handling animation has some tricky cases though. For instance in PNG, the default image that you get if you treat the image as non-animated may be different from the first frame of the animation. We might need both a read_image and a read_frame method.

The addition of an init method doesn't seem like it gains us much. The tricky part of our current new+set_limits API is that you get to look at the image dimensions and total output size in bytes when deciding what decoding limits to set. Requiring init (and by extension set_limits) to be called before reading the dimensions makes it basically the same as just having a with_limits constructor.

197g · 2025-11-27T19:06:55Z

Requiring init (and by extension set_limits) to be called before reading the dimensions makes it basically the same as just having a with_limits constructor.

It's a dyn-compatible way that achieves the goal of the constructor so it is actually an abstraction.

The tricky part of our current new+set_limits API is that you get to look at the image dimensions and total output size in bytes when deciding what decoding limits to set.

What do you by this? The main problem in png that I'm aware of is the lack of configured limits for reading the header in the ImageReader path, that motivated the extra constructor in the first place. With png we can not modify the limits after the fact but also we don't really perform any large size-dependent allocation within the decoder.

I'm also not suggesting that calling set_limits after the layout inspection would be disallowed but obviously is decoder dependent on whether that 'frees' additional capacity. I guess if that is sufficient remains to be seen? When we allocate a buffer (with applied allocator limits)´ that allows forwarding the remaining buffer size to the decoder. Or, set aside a different buffer allowance for metadata vs. image data. Whatever change is necessary in png just comes on top anyways, the init flow just allows us to abstract this and thus apply it with an existing Box<dyn ImageDecoder> so we don't have to do it all before. Indeed, as the comment on size eludes to we may want to different limit structs: one user facing that we use in ImageReader and one binding-facing that is passed to ImageDecoder::set_limits. Then settings just need to be

197g · 2025-12-04T12:17:45Z

@fintelia This now includes the other changes including to ImageReader as a draft of what I meant in #2679 (comment). In short:

The file guessing routines and the construction of the boxed decoder are split into a separate type, ImageFile, which provides the previous methods of ImageReader but also an into_reader for the mutable, stateful interface.
ImageReader:
- features all accessors for metadata considering that some formats fill said metadata (or a pointer to it) after an image is decoded.
- has viewbox as a re-imagining of the previous ImageDecoderRect trait but split into two responsibilites: the trait does the efficiency decision on an image-by-image basis with an interface that allows a partial application of the viewbox (in jpeg and tiff we would decode whole tiles); then the reader takes care of translating that into an exact layout. Note that another type of image buffer with offset+rowpitch information could do that adjustment zerocopy—I still want to get those benefits of the type erased buffer/image-canvas someday and this fits in.
The code also retrieves the CICP from the color profile and annotates the DynamicImage with it where available. For sanity's sake the moxcms integration was rewritten to allow a smaller dependency to be used here, I'll split these off the PR if we decide to go that route.
Conceivably there's a gain_map (or similar) that may be queried similar to the metadata methods. For that to be more ergonomic I'd like to seriously consider read_plane for, in tiff lingo, planar images as well as associated and non-associated mask data; and more speculatively other extra samples that are bump maps? uv? true cmyk?. While that does not necessarily all go into 1.* for any output that is not quite neatly statically sorted and sized as an Rgba 4-channel-homogeneous-host-order, I imagine it will be much simpler for a decoder to provides its data successively in multiple calls instead of a contiguous large byte slice. Similar to viewbox we'd allow this where ImageReader provides the compatibility to re-layout the image for the actual user—except where explicitly instructed. Adjusting ImageReader::decode to that effect should be no problem in principle.

RunDevelopment · 2025-12-06T13:41:50Z

I can't speak about image metadata, but I really don't like the new ImageDecoder interface as both an implementor of the interface and a potential user of it. Right now, it's just not clear to me at all how decoders should behave. My problems are:

init. This is just two-phase initialization and opens so many questions.
- Do users have to call it? The docs say "should" not "must" be called before read_image.
- Are users allowed to call it multiple times? If so, the decoder has to keep track of whether the header has already been read.
- Since init returns a layout, what's the point of dimensions() and color_type()? And what if they disagree?
- What should dimensions and co do before init is called?
- If init fails, what should happen to methods like dimensions and read_image? When called, should they panic, return an error, return default values?
- After calling read_image, do you have to re-init before calling read_image again?
viewbox makes it more difficult to implement decoders.
- Now they always have to internally keep track of the viewbox rect if rect decoding is supported.
- After calling viewbox, what should dimensions be? If they should be the viewbox size, should they reflect the new viewbox even before calling init?
- It's not clear what should happen if viewbox returns ok, but init errors.
- What should happen if users supply a viewbox outside the bounds of the image?
When calling viewbox, is the offset of the rect relative to the (0,0) of the full image or the last set viewbox?
What should happen if read_image is called twice? Should it read the same image again, error, read the next image in the sequence? The docs don't say.
- If the intended behavior is "read the same image again", then those semantics would force all decoders to require Seek for the reader (or keep an in memory copy of the image for subsequent reads). Not an unreasonable requirement, but it should be explicitly documented.

Regarding rectangle decoding, I think it would be better if we force decoders to support arbitrary rects. That's because the current interface is actually less efficient by allowing decoder to support only certain rects. To read a specific rect that is not supported as is, ImageReader has to read a too-large rect and then crop the read image, allocating the memory for the too-large image only to throw it away. It is forced to do this, because of the API.

However, most image formats are based on lines of block (macro pixels). So we can do a trick. Decode a line according to the too-large rect, and then only copy the pixels in the real rect to the output buffer. This reduces the memory overhead for unsupported rects from O(width*height) to O(width*block_height). Supported rects don't need this dance and can decode into the output buffer directly. I.e. that's kinda what DDS does.

And if a format can't do the line-based trick for unsupported rects, then decoders should just allocate a temp buffer for the too-large rect and then crop (=copy what is needed). This is still just as efficient as the best ImageReader can do.

For use cases where users can use rowpitch to ignore the exccess parts of the too-large rect, we could just have a method that gives back a preferred rect, which can be decoded very efficiently.

So the API could look like this:

trait ImageDecoder {
    // ...
    /// Returns a viewbox that contains all pixels of the given rect but can potentially be decoded more efficiently.
    /// If rect decoding is not supported or no more-efficient rect exists, the given rect is returned as is.
    fn preferred_viewbox(&self, viewbox: Rect) -> Rect {
        viewbox // default impl
    }
    fn read_image_rect(&mut self, buf, viewbox) -> ImageResult {
        Err(ImageError::Decoding(Decoding::RectDecodingNotSupported)) // or similar
    }

This API should make rect decoding easier to use, easier to implement, and allow for more efficient implementations.

197g · 2025-12-07T20:06:18Z

init. This is just two-phase initialization and opens so many questions.

That was one of the open questions, the argument you're presenting makes it clear it should return the layout and that's it. Renamed to next_layout accordingly. I'd like to remove the existing dimensions()/color_type methods from the trait as well. There's no point using separate method calls for communicating them.

For use cases where users can use rowpitch, […]

That is ultimately the crux of the problem. I'd say it's pretty much the only problem even though that does not appreciate the complexity. A lot of what you put forth is overly specific to solving one instance of it, obviously focusing on DDS. That's not bad but take a step back to the larger picture. There's no good way to communicate all kinds of layouts that the caller could handle: tiled, planar, depths, sample types …. With the information being exchanged right now, no-one can find a best-match between the requirements of image's data types (and Limits) and what the decoder can provide. This won't be solved by moving complexity into the decoders, we need to get structured information out of them primarily, then make that decision / handling the resulting byte data in image's code.
1. viewbox makes it more difficult to implement decoders.
The point of the default implementation in this PR is that it is purely opt-in. Don't implement the method for decoders that can not provide viewbox decoding and everything works correctly. The documentation seems to be confusing, point taken. We're always going to have inefficiencies, I'm for working through the distinct alternative layouts that allow an optimization one-by-one. More importantly for this PR immediately is what outcome a caller may want and what interface would give it to them—in this case I've worked on the use-case of extracting part of an atlas.
However, most image formats are based on lines of block (macro pixels). So we can do a trick.

I'm not designing anything in this interface around a singular "trick", that's the wrong way around. That is how we got here. That's precisely what created ImageDecoderRect, almost to the dot. Falsehoods programmer's assume about image decoding will lead that to this breaking down and to be horrible to maintain. The trick you mention should live in the decoder's trait impl and nowhere else and we can bring it back where appropriate and possible. (Note that if you do it for a specific format, some formats will be even more efficient and not require you decode anything line-by-line but skip ahead, do tiles, … That's just to drive home the point that you do not want to do this above the decoder abstraction but below it in the ImageDecoder impl).
It is forced to do this, because of the API.

The decoder impls is only forced to do anything if we force it via an interface—this PR does not; read_image_rect(&mut self, buf, viewbox) does force a decoder to be able to handle all possible viewboxes—this PR does not. I'm definitely taking worse short-term efficiency over code maintenance problems—the latter won't get us efficiency in the long run either.

When calling viewbox, is the offset of the rect relative to the (0,0) of the full image or the last set viewbox?

It's suppose to be to the full image. Yeah, that needs more documentation and pointers to the proper implementation.

src/io/image_reader_type.rs

fintelia · 2025-12-07T20:21:16Z

src/io/image_reader_type.rs

    }
 }
+
+impl ImageReader<'_> {


nit: it is easier for scrolling through the file if the impl blocks for each struct immediately follow the definitions

src/io/decoder.rs

fintelia · 2025-12-07T22:29:08Z

src/io/image_reader_type.rs

+        self.viewbox = Some(viewbox);
+    }
+
+    /// Get the previously decoded EXIF metadata if any.


The "previously decoded" part here makes me a bit nervous. I think we'll want to be clearer about what the user has to do to make sure they don't get None for images that actually do have EXIF data

This is a bit odd and will depend on the format and metadatum. For instance, XMP is encoded per-image in tiff but only once in gif (despite us representing this as an image sequence) and also only once in png (no word about APNG). Problematically, in gif and png the standard requires absolutely no ordering with any of the other chunks. So it might be encountered before all of the header information is done; or after all the images have been consumed.

The problem with back references is of course the unclear association. And when multiple are included we always have a problem with consuming them 'after the end' since it should need to be buffered or the decoder able to store seek-back points (like png). Encoding all that in the interface is a challenge, i will incur some unavoidable complexity.

Moving the metadata query between peek_layout and read_image doesn't really affect this argument with the variants of MetadataHint that I've found to be necessary. So that is cleaner, see #2672 (comment)

Of course we have last_attributes still remaining since that is information that combines the information the reader has retrieved, e.g. the orientation given directly from read_image together with the fallback of querying it from exif.

src/io/decoder.rs

197g · 2025-12-16T19:17:10Z

Resolving the naming question as peek_layout, hopefully satisfactory for now.

197g · 2025-12-22T22:17:18Z

@fintelia I understand this is too big for a code-depth review but I'd be interested in the directional input. Is the merging of 'animations' and simple images as well as the optimization hint methods convincing enough? Is the idea of returning data from read_image something that works for you? The struct is meant to be Default-able and fills in the information for into_frames() but I'll sketch out some way of putting the metadata indicators in there (i.e. should you poll xmp for this frame, or wait until the end, or is it constant of the file).

As an aside, in wondermagick we basically find that sequence encoding is a missing API to match imagemagick. We can currently only do this with gif, despite tiff and webp having absolutely no conceptual problems with it (avif too, but imagemagick behaves odd, does not match libavifs decoding and the rust libraries don't provide it). It would be nice to make those traits symmetric so the direction here influences the encoding, too.

ronjakoi · 2026-01-06T00:59:10Z

I think it would be nice to have an iterator of all images in a file, where in the case of pyramid TIFFs for example, I could filter for the image with dimensions most closely matching a given need.

mstoeckl · 2026-01-18T15:59:25Z

src/io/decoder.rs

+    /// Consume the header of the image, determining the image's layout.
+    ///
+    /// This must be called before a call to [`Self::read_image`] to ensure that the initial
+    /// metadata has been read. In contrast to a constructor it can be called after configuring
+    /// limits and context which avoids resource issues for formats that buffer metadata.
+    ///
+    /// The layout returned by an implementation of [`ImageDecoder::peek_layout`] must match the
+    /// buffer expected in [`ImageDecoder::read_image`].
+    fn peek_layout(&mut self) -> ImageResult<crate::ImageLayout>;


To better understand how the new ImageDecoder interface works, I've been trying to implement it for the image-extras decoders, and as time permits will add comments as I run into issues and have questions. (Edit: see https://github.com/mstoeckl/image-extras/tree/experiment-deco-meta, still rather rough)

The name ("peek_...") suggests that it is safe to call this multiple times in a row (or zero!); for example: that the sequence self.peek_layout(), self.peek_layout(), self.read_image() should work and would not read two headers from the input. Could this be explicitly documented?

For formats containing a single image, may and/or should calls to peek_layout() return an Error (like ParameterErrorKind::NoMoreData) after read_image() has been called?

should work and would not read two headers from the input. Could this be explicitly documented?

may and/or should calls to peek_layout() return an Error (like ParameterErrorKind::NoMoreData) after read_image() has been called?

Both correctly guessed as was the intention behind the naming. Of course we can touch up the documentation. The decoder should return a useful error as NoMoreData but for any format that is neither is_animated nor is_sequence we don't need to make any strong requirements. It would be nice to make our internal implementations behave more strictly correct which is mostly missing tests, I think.

mstoeckl · 2026-01-18T16:03:29Z

src/io.rs

+#[non_exhaustive]
+pub struct ImageLayout {


External crates would need to construct ImageLayout in order to implement ImageDecoder::peek_layout(), which is tricky because ImageLayout is marked non-exhaustive.

mstoeckl · 2026-01-18T16:12:12Z

src/io/decoder.rs

    /// Returns the color type of the image file before decoding
-    fn original_color_type(&self) -> ExtendedColorType {
-        self.color_type().into()
+    fn original_color_type(&mut self) -> ImageResult<ExtendedColorType> {
+        Ok(self.peek_layout()?.color.into())
    }


original_color_type() might be worth merging into ImageLayout/peek_layout(), because I expect typical format decoders will determine the value of this at the same time that the ImageLayout::color is determined.

Ah yes, I wasn't quite sure what to do with it in the commit where the previous dimensions were finally folded into peek_layout but that is a very reasonable treatment. Just an extra Option<ExtendedColorType> field I suppose?

This was one of the silently broken features when adding the new methods. While reviewing how to address the underlying cause with a clippy fix it became obvious a few other methods were missing, too.

Change ImageDecoder::read_image to `fn(&mut self)`. There are some codecs where metadata and other information is only available after decoding. Add ImageDecoder::init for codecs where reading the header needs to take into account limits and other configuration we are to introduce. This sketch compiles as: `--no-default-features --features=png`

Renames it `peek_layout` to clarify the relation to `read_image`, that it is to be called potentially multiple times for each such call. Document the trait more with this relationship, moving some methods around to clarify.

The latter interface will be something that interfaces and interacts with the underlying decoder. Introduces ImageDecoder::set_viewport as a stand-in for what is intended here: color, subsampling, gain map application will take more interaction, clarification of how the library will request their data, and adjustments to the layout definition by the decoder.

The purpose of the trait is to be careful with the boundary to the `moxcms` dependency. We use it because it is a quality implementation but it is heavy weight for what we need. There's other possible ways to provide transfer functions and color space transforms. Now this also introduces ICC profile parsing but again that could be done with a *much* lighter dependency as we only need basic information from it. The trait should make every little additional cross-dependency a conscious decision. Also it should be the start of a customization point, by feature flag or actually at runtime.

No longer responsible for ensuring the size constraints are met under the new policy and with available of constructing a reader from an instance of a boxed decoder.

This allows us to write a generic iterator which uses the same decoder function to generate a whole sequence of frames. The attributes are designed to be extensible to describe changes in available metadata as well, very concretely some formats require that XMP/ICC/… are polled for each individual image whereas others have one for the whole file and put that at the end. So there's no universal sequence for querying the metadata, and we need to hold runtime information. This will be the focus of the next commit.

This commit is meant to be revertable. The demonstration code was an experiment at improving the protocol between the trait implementation and the user facing `ImageReader`. While successfully showing that the interface would work with extension points as intended the details are not fleshed out and we would like at least some implementations to provide actual `viewbox` internals to add this feature. Also remember: this is not yet tested, `ImageReader::peek_layout` and all its derived methods should very likely consult the viewbox setting.

This method was mostly implemented to acquire EXIF information and retrieve the entry from it. However, that is a weird way of using the trait system with this mutable method. Instead we move the responsibility of extracting and manipulation of EXIF to the ImageReader and have the decoder interface only support its input. The orientation is added as a field to per-image decoded data in case where such information exists outside of EXIF (e.g. in TIFF).

At least the per-image metadata should be retrieved there. This also ensures that there is a consistent location for data available after the header for all images and data that changes per image. The call to `read_image` can then be destructive for all metadata that is only valid for that particular frame (e.g. TIFF) which it needed to delay until the next `peek_layout` before, leading to very odd interactions. Previously, it meant that `read_image` was supposed to cleanup the image data itself but not the metadata. This split responsibility is not super intuitive for many image types..

Having separate methods for these is not very effective in terms of protocol. All the formats we have can determine them at the same sequence point and `peek_layout` has become somewhat central in the definition of the protocol. It defines the buffer requirements for `read_image`—having one method means one source of truth for this length requirement which is far clearer than requiring that the caller run multiple methods and combine their results (with unclear semantics of running intermediate other methods).

RunDevelopment

I love how this came along since the last time I had a look. Awesome work, @197g and everyone involved!

RunDevelopment · 2026-02-01T19:30:57Z

src/io/decoder.rs

+    /// Retrieve animation attributes.
+    ///
+    /// You should check [`DecoderAttributes::is_animated`] before calling this method. It will
+    /// only be available on animated images. Additionally, most file formats store the metadata in
+    /// the header which might not be read until after calling [`ImageDecoder::peek_layout`].
+    fn animation_attributes(&mut self) -> Option<DecodedAnimationAttributes> {


What does "available" mean here? Does that mean that is_animated == false implies animation_attrs() == None?

If so, then I would suggest replacing the first two sentences with: "This method always returns None for non-animated images. Use [`DecoderAttributes::is_animated`] to check whether an image is animated."

Why is this method mut? From its description, this sounds like a pure method that doesn't cause side effects like IO or changing the internal state of the decoder.

I know that GIF needs mut call its ensure_decoder() method, but I don't understand why it calls ensure_decoder() in the first place. animation_attributes is documented as requiring peek_layout, which initializes the GifDecoder::decoder field.

This leaves me wondering. Is animation_attributes allowed to rely on the side effects of peek_layout? If it is, then it doesn't need mut since peek_layout does the side effects.

(I assume that repeated calls are allowed.) Are the DecodedAnimationAttributes returned by this method allowed to change over the lifetime of the decoder? In other words, if it returned Some(x) at some point, is it allowed to return Some(y) for x != y or even None in subsequent calls?

[…]

Aye.

Why is this method mut? From its description, this sounds like a pure method that doesn't cause side effects like IO or changing the internal state of the decoder.

Mainly since all other metadata methods like icc data have the same interface. With the current shape of the trait, every caller is generally expected to have unique ownership over the decoder. There's little reason to make these methods shared then while this allows a few more patterns in the implementation that might otherwise be awkward.

It does not need mut but it also does not need shared.

Are the DecodedAnimationAttributes returned by this method allowed to change over the lifetime of the decoder? In other words, if it returned Some(x) at some point, is it allowed to return Some(y) for x != y or even None in subsequent calls?

In the sense that the interface is not unsafe that is always okay. We probably need more fields in the DecoderAttributes if ImageReader has reason to ever cache these from the decoder object. But there's plenty of extension points left.

In the sense that the interface is not unsafe that is always okay.

I was more so asking about what is correct in terms of the interface. So would we consider behavior like return values changing a bug if a decoder behaved that way?

RunDevelopment · 2026-02-01T20:23:29Z

src/io/decoder.rs

+    /// basic capability information about the format. If, in the future, we added different basic
+    /// methods of retrieving color data then the attributes would indicate the preferred and/or
+    /// possible choices.
+    fn attributes(&self) -> DecoderAttributes {


Could you please explain what kind of attributes this method returns? Right now, it's not clear to me whether the attributes are about the format itself (i.e. static attributes that solely describe the format and its implementation) or about the image file (i.e. attributes that change even within a format depending on which file is read).

Right now, ::is_animated is documented as: "Are there multiple images in this file that form an animation?" However, implementations like GIF contradict this documentation, because they return a constant value irrespective of the image file's contents. I.e. even GIF images with only a single frame return is_animated: true.

RunDevelopment mentioned this pull request Nov 28, 2025

Suggestions: New ImageDecoder and ImageSequenceDecoder APIs #2679

Open

This was referenced Nov 30, 2025

Rip out ImageDecoderRect #2681

Merged

Prevent OOM in ICO due to PNG #2682

Merged

197g force-pushed the decoder-metadata-interface branch from 86c9194 to cdc0363 Compare December 7, 2025 18:22

fintelia reviewed Dec 7, 2025

View reviewed changes

RunDevelopment reviewed Dec 9, 2025

View reviewed changes

src/io/decoder.rs Outdated Show resolved Hide resolved

This comment was marked as outdated.

Sign in to view

This comment was marked as resolved.

Sign in to view

197g force-pushed the decoder-metadata-interface branch 2 times, most recently from 1a114c3 to 306c6d2 Compare December 16, 2025 18:40

This was referenced Dec 18, 2025

Add a -write option Shnatsel/wondermagick#77

Open

Add {ImageBuffer,DynamicImage}::crop_in_place #2701

Merged

197g force-pushed the decoder-metadata-interface branch 7 times, most recently from e8d2713 to 4325060 Compare December 22, 2025 17:54

197g marked this pull request as ready for review December 22, 2025 22:17

197g force-pushed the decoder-metadata-interface branch from f6720de to c677c88 Compare December 29, 2025 16:30

This was referenced Jan 5, 2026

Implement loop_count for AnimationDecoder Trait. #2716

Merged

How to find and decode a specific image in a multi-image TIFF file? #2719

Open

197g mentioned this pull request Jan 7, 2026

Version 1.0 plan #2245

Open

24 tasks

fintelia mentioned this pull request Jan 13, 2026

Support generic image stack decoding + tiff stack decoding #2706

Open

197g mentioned this pull request Jan 16, 2026

Add streaming/incremental decoding support to BMP decoder #2721

Closed

197g force-pushed the decoder-metadata-interface branch from 2f71c9a to a2703f4 Compare January 17, 2026 11:37

mstoeckl reviewed Jan 18, 2026

View reviewed changes

197g added 18 commits January 29, 2026 07:30

Ensure ICO forwards all methods

32bc291

This was one of the silently broken features when adding the new methods. While reviewing how to address the underlying cause with a clippy fix it became obvious a few other methods were missing, too.

Migrate all codecs to init with layout

5e60ca8

Renames it `peek_layout` to clarify the relation to `read_image`, that it is to be called potentially multiple times for each such call. Document the trait more with this relationship, moving some methods around to clarify.

Provide limited metadata decoding with ImageReader

5b677fc

Provide ImageReader::skip

0e1cf0f

Rename ImageFile -> ImageReaderOptions

c123d4f

Fixup gif testing

b0dbf40

No longer responsible for ensuring the size constraints are met under the new policy and with available of constructing a reader from an instance of a boxed decoder.

Adjust tests for ImageReader limits usage

49ffd0e

Add metadata sequence indicators

1438a60

Move metadata hints into decoder attributes

922b533

Remove AnimationDecoder trait

4d151b6

197g force-pushed the decoder-metadata-interface branch from c7a2be7 to 4d151b6 Compare January 29, 2026 07:07

RunDevelopment reviewed Feb 1, 2026

View reviewed changes

		#[non_exhaustive]
		pub struct ImageLayout {

Decoder metadata interface #2672

Are you sure you want to change the base?

Decoder metadata interface #2672

Conversation

197g commented Nov 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Discussion

Uh oh!

mstoeckl commented Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fintelia commented Nov 27, 2025

Uh oh!

197g commented Nov 27, 2025

Uh oh!

197g commented Dec 4, 2025

Uh oh!

RunDevelopment commented Dec 6, 2025

Uh oh!

197g commented Dec 7, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment was marked as outdated.

This comment was marked as resolved.

This comment was marked as resolved.

197g commented Dec 16, 2025

Uh oh!

197g commented Dec 22, 2025

Uh oh!

ronjakoi commented Jan 6, 2026

Uh oh!

mstoeckl Jan 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mstoeckl Jan 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RunDevelopment left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

197g Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

197g commented Nov 26, 2025 •

edited

Loading

mstoeckl commented Nov 27, 2025 •

edited

Loading

mstoeckl Jan 18, 2026 •

edited

Loading

mstoeckl Jan 18, 2026 •

edited

Loading

197g Feb 2, 2026 •

edited

Loading