proposal: image: decoding options #27830
There are two broad areas of configuration that are considered. This proposal tackles them both
Avoiding large allocations on unprocessable images
This class of problem is generally caused by faulty or malicious header information in the image file.
Being more tolerant of invalid input
The image decoders in the standard library are strict and fail on invalid input. There are classes
Other options related issues
In addition, the following issues suggest other areas that could benefit from decoding options but are
The primary extensibility point is a new type. Its fields are discussed at the end of this section.
Format decoders are registered via a new package level function
The FormatDecoder interface needs to be implemented by any package providing image format decoding:
A new exported Decoder type is introduced:
with a basic constructor function.
The Decoder type has the following method set:
These Decode methods will sniff the type of the image from the reader and look up an appropriate
To configure decoding the developer will create a new Decoder and then set the appropriate fields
The following options are proposed.
MaxHeight and MaxWidth
MaxHeight and MaxWidth are DecodeOptions fields that set the maximum allowable dimensions of a decoded image.
These options are only used by the Decode method. When a Decoder attempts to decode an image with dimensions
DecodeConfig should return a Config containing the width and height described in the image data stream
ReturnPartial is a DecodeOptions field that instructs the decoder that it may return a partially decoded
The current Decode behaviour is that no image data is returned on error. When this option is true the caller
Backwards compatibility with existing registered formats
Existing callers of RegisterFormat will be supported by adapting the existing
The existing package level
Deprecation of RegisterFormat
RegisterFormat would be marked as deprecated in favour of RegisterFormatDecoder.
The text was updated successfully, but these errors were encountered:
The overall goal seems OK. Some rambling thoughts, major and minor:
I'd suggest forking
For example, the API proposal still doesn't let us see the intermediate stages when decoding a progressive JPEG, when the compressed bytes come in slowly. There is a new
We don't have to solve the progressive JPEG case now, but I'm hesitant to e.g. commit to an API in Go 1.12 that makes it harder to solve that case in Go 1.16.
One possible design approach for that is to use something that's more like a
That's the approach I'm taking in my Wuffs project. It's a little hard to see, but that's what the Wuffs
But using a
A final, minor point. I don't think we need a