go: image/jpeg: unexpected EOF when decoding image file

Try func (*os.File).Seek(offset int64, whence int) (ret int64, err error) before decoding.

package main

import (
	"image"
	_ "image/jpeg"
	"os"
)

func main() {
	f, err := os.Open("1.jpg")
	if err != nil {
		panic(err)
	}
	defer f.Close()
 
        f.Seek(0, 0)
	_, _, err = image.Decode(f)
	if err != nil {
		panic(err)
	}
}

I figured this because some image file from Samsung Galaxy Panorama Image, which does not have EOI marker from this adobe forum.

https://community.adobe.com/t5/lightroom-classic-discussions/samsung-s9-panoramic-jpeg/td-p/10379560

And solved it by appending two bytes at the end of the buffer before passing it to .Decode

        // MEMO: Workaround for Samsung Galaxy Panorama, by appending EOI marker
	// MEMO: JPEG Spec doesn't define file format, so extra data is OK
	buf = append(buf, 0xff, 0xd9)

Yeah, duplicate of #10447

I figured this because some image file from Samsung Galaxy Panorama Image, which does not have EOI marker from this adobe forum.

https://community.adobe.com/t5/lightroom-classic-discussions/samsung-s9-panoramic-jpeg/td-p/10379560

And solved it by appending two bytes at the end of the buffer before passing it to .Decode

        // MEMO: Workaround for Samsung Galaxy Panorama, by appending EOI marker
	// MEMO: JPEG Spec doesn't define file format, so extra data is OK
	buf = append(buf, 0xff, 0xd9)

it works fine for me , thanks for saving my day

As for (1), that is a duplicate of #10447, as previously mentioned. Even if we ‘fixed’ (2), we can’t solve your underlying problem (you want as much of the JPEG as you can still decode, even if it’s overall technically an invalid JPEG) without solving (1).

As I said, and as you can clearly see, because you are an active participant of that issue, there is no mention of unexpected EOF as a result of processing possibly “corrupted” file. We spent quite some time investigating it, and our case is real-world scenario, and we searched through open and closed issues related to image before posting it. So I disagree it is “duplicate”, if you think it’s similar situation underneath (which is not that clear from the error text, it sounds more like a bug of a library) then you could copy my case to #10447 thread, so it would become an “addition” not just “duplicate”, to help others who may encounter the same situation. Instead you decided to just close my case.

As for (2), io.ErrUnexpectedEOF still seems reasonable to me. We asked jpeg.Decode to do something, passing an io.Reader.

What’s the point? You are talking about some internals of image, which I don’t care. I don’t even use image directly! Processing of images is tightly coupled with receiving a data (i.e. imaging lib does both for us, opens a file and manipulates it). How do I know that io.ErrUnexpectedEOF has anything to do with “wrong” JPEGs? How do I handle this error? What exactly I, as a caller, should do and how do I distinguish this from I/O errors? Is this a problem with web socket or TCP stream? Or NFS? Should I re-instantiate connection or close it? Should I report a caller that file needs to be resent? There is nothing pointing to the fact that file was analyzed and library could not decode it, the only fact you know is that something is wrong with I/O.

It couldn’t do it, because it hit a premature end (an EOF) of the data stream. Sounds like an unexpected EOF to me.

You just said what it sounds: “premature end of [something you just processed] JPEG”.

The compress/zlib package will return io.ErrUnexpectedEOF if it’s invalid ZLIB. …

Ok, nice. I don’t know if their use of io.ErrUnexpectedEOF correct or not, because I don’t have experience report for that, but what I know for sure is that it’s wrong in this particular case.

And, again what’s the point to referring to them? So if, lets imagine, their use of io error was wrong would they refer to image/jpeg and say the problem will not be fixed because it’s used in the same way in image/jpeg? Vicious circle? If it’s wrong or bad design, than it should be fixed, as simple as that.

@inliquid, in fact, I’m with you 🤝 . I wish image/jpeg could be more tolerant with not perfect images too! But the fact is that @nigeltao is very overloaded 🤗 . I guess he has a very big backlog, and this feature doesn’t get the chance to enter the top.

In my opinion, this issue can not be addressed without #10447 being addressed, and it doesn’t help to just leave this one open. #10447 is tagged as NeedsDecision, to push things forward, I think we need someone experienced in image processing to create a proposal first. I wish I could help, but it’s sad that I’m not familiar with image processing.

Image Magic is de-facto industry standard for all sorts of image processing. It’s an addition to a quite decent list of software which doesn’t treat that image as “invalid”.

Use the identify tool (shipped with ImageMagick) on the file and it will tell you that the JPEG file is corrupted/truncated. See an earlier comment where this was already done (using the GraphicsMagick fork of ImageMagick).

@ZekeLu also pointed out that your problem is already discussed in issue #10447.