You should at least look at the stream and check that it looks like an image in a format the decoder can read.
For PNG, you could maybe argue that given a correct magic number and a correctly-working decoder, the decoder must be able to read all the images or either the decoder or image is broken. Then again, you're not even checking the magic number..
For TGA, though, we don't have an exact magic number. It's entirely possible that we our TGA magic number matches some files that aren't really TGA images but are images in some other format that we can decode. We need QueryCapabilities to disambiguate the decoders in these cases.
For JPEG and TIFF, which are extensible formats, there's also the possibility that an image has something in it that we don't support (and that the corresponding decoder on Windows doesn't support) but some other decoder on the system can.
The method should also invalidate the decoder object, so we don't accidentally introduce code that reuses it.
Vincent Povirk madewokherd@gmail.com wrote:
You should at least look at the stream and check that it looks like an image in a format the decoder can read.
An invalid image format is a completely not related case, that I'd prefer ignore for now.
For PNG, you could maybe argue that given a correct magic number and a correctly-working decoder, the decoder must be able to read all the images or either the decoder or image is broken. Then again, you're not even checking the magic number..
For TGA, though, we don't have an exact magic number. It's entirely possible that we our TGA magic number matches some files that aren't really TGA images but are images in some other format that we can decode. We need QueryCapabilities to disambiguate the decoders in these cases.
For JPEG and TIFF, which are extensible formats, there's also the possibility that an image has something in it that we don't support (and that the corresponding decoder on Windows doesn't support) but some other decoder on the system can.
A not supported stream format is a bug and should be fixed IMO. I believe that an implementation which declares support for all formats is better than a not implemented stub.
For JPEG and TIFF, which are extensible formats, there's also the possibility that an image has something in it that we don't support (and that the corresponding decoder on Windows doesn't support) but some other decoder on the system can.
A not supported stream format is a bug and should be fixed IMO. I believe that an implementation which declares support for all formats is better than a not implemented stub.
I'm not sure. There are plenty of standard TIFF files that native can't handle (though I don't think it's a bug if we can), and there's the possibility of non-standard TIFF files that a corresponding third-party decoder can.
Vincent Povirk madewokherd@gmail.com wrote:
For JPEG and TIFF, which are extensible formats, there's also the possibility that an image has something in it that we don't support (and that the corresponding decoder on Windows doesn't support) but some other decoder on the system can.
A not supported stream format is a bug and should be fixed IMO. I believe that an implementation which declares support for all formats is better than a not implemented stub.
I'm not sure. There are plenty of standard TIFF files that native can't handle (though I don't think it's a bug if we can), and there's the possibility of non-standard TIFF files that a corresponding third-party decoder can.
That's a pretty questionable argument IMO.
-
Dmitry Timoshkov -
Vincent Povirk