go: image/jpeg: add options to partially decode or tolerantly decode invalid images?

In case, anybody does care, I have forked now the jpeg package and fixed some of the issues with the help of the code of @whorfin

https://gitlab.com/golang-utils/image2

So to recap:

1. This issue is now 8 years old and have never been fixed.
2. It is a showstopper for any use of the image library on a server where random images are uploaded.
3. This library behaves worse than any reasonable image processing software out there.
4. The issue could have been easily fixed, by returning a proper error message and the processed image up to the point where the unexpected error happened.
5. The maintainer was not sure about what to do and avoided any decision for 7 years.
6. In this time nobody from the Go developers stepped up to help our fix the issue by himself.
7. After the maintainer prevented any solution from happening for 7 years, he now is unassigned from the issue.
8. Now nobody is assigned to the issue and nobody fixed it.

Great job!

go version go1.13.4 windows/amd64 this problem still exists.

All of the failing testcases here and others that I’ve found are truncated. They don’t have complete SOS segments, don’t contain an EOI, and raise warnings with other decoders. In @elsonwu’s case, it’s fixed by appending \x00\xff\xd9. The others are missing more data.

Still, there is a bug in that there’s no way to decode truncated images, which seem relatively common and are readable with most other decoders.

My first thought is to return a partially decoded image (if there is one) along with the error; see https://github.com/special/go/commit/c7a05f392ca604f6070009364827b04535293974. I don’t mind adding docs/tests and submitting that if the approach is ok.

Otherwise, it seems slightly inappropriate to silence legitimate decoding errors, and there’s no API for decoding options, so I’m not sure what else to do.

I’d rather have a different package instead of adding TryToDecode to the standard library for the rest of Go 1.x’s lifetime. As a bonus, such a package wouldn’t be bound by the standard library feature freeze that we’re currently in.

I don’t know if any such package already exists, and I won’t have time to make one any time soon. Sorry.

I guess it’s out of scope of go-lang to nicely handle such case?

Yeah, I’d still say what I said a couple of years ago: https://github.com/golang/go/issues/10447#issuecomment-310585843

We could possibly change jpeg.Decode (and the other image codecs) to return (non-nil Image, non-nil error) with partial results if it encounters an error, although that’s unusual in general for functions returning (T, err), and certainly not going to happen for Go 1.8.

As for matching whatever browsers do, what browsers do influences how far down the Postel’s law slope we slip, but I’m wary of the slippery slope, and according the JPEG spec, these are invalid images.