Imagesharp: Progressive jpeg with missing EOI marker throws EOFException

[JimBobSquarePants]

_From @gdoron on October 31, 2016 12:57_

Hi James @JimBobSquarePants,

This specific image:

fails when trying to load it.

Stacktrace:

ImageProcessorCore.Formats.JpegDecoderCore+EOFException: Exception of type 'ImageProcessorCore.Formats.JpegDecoderCore+EOFException' was thrown.
at ImageProcessorCore.Formats.JpegDecoderCore.Fill()
at ImageProcessorCore.Formats.JpegDecoderCore.ReadByte()
at ImageProcessorCore.Formats.JpegDecoderCore.ReadByteStuffedByte()
at ImageProcessorCore.Formats.JpegDecoderCore.EnsureNBits(Int32 n)
at ImageProcessorCore.Formats.JpegDecoderCore.DecodeHuffman(Huffman huffman)
at ImageProcessorCore.Formats.JpegDecoderCore.Refine(Block b, Huffman h, Int32 zigStart, Int32 zigEnd, Int32 delta)
at ImageProcessorCore.Formats.JpegDecoderCore.ProcessStartOfScan(Int32 n)
at ImageProcessorCore.Formats.JpegDecoderCore.DecodeTColor,TPacked

Any clue?

By the way, checkout this story: https://yooocan.com/Story/329/Having-Wheels-Has-Its-Perks
Amazing people, and you're helping them James!

THANKS A LOT!

_Copied from original issue: JimBobSquarePants/ImageProcessor#505_

[JimBobSquarePants]

_From @dlemstra on October 31, 2016 13:7_

Can you add a link to the original jpg file? Github changed it into a PNG file. Is this the correct link: https://yooocanlive.azureedge.net/images/98bc0f36fcc4444e9889e152aa4ceb5d?

And can you move your issue to the new repo: https://github.com/JimBobSquarePants/ImageSharp? The Core branch has been renamed.

[JimBobSquarePants]

_From @gdoron on October 31, 2016 13:14_

@dlemstra
Try this one:
http://yooocan.com/images/temp/bad%20image.jpeg
(For future readers, this image will be deleted, I had to upload it to our server)

Thanks!

[JimBobSquarePants]

_From @gdoron on October 31, 2016 13:19_

BTW, in case you delete go to the link and read the story,
This is a Halloween costume a father made for his disabled _{I hate this word} kid.
They "dressed" the wheelchair in a Ghostbusters car costume. AMAZING STUFF!.

[JimBobSquarePants]

@gdoron Great story, really heart-warming! 😄

I'm going to move this issue over to the correct repo as I have moved everything. We can continue the discussion there.

[JimBobSquarePants]

Ok, @gdoron,

I used jpegsnoop to analyse the image and it is technically corrupt as it's missing an EOI (End Of Image) marker.

Theoretically it would still be possible to decode the image (Windows can) by calculating the number of expected MCU's (Minimum Coded Unit) if we are able to read the height and the width from the image header and stopping decoding once we have reached that value. Typically those are 8x8 units but can also be 16x8 or 16x16 depending on the subsampling.

More info on MCU's can be found here

It's not going to be easy to fix but I'll give it my best shot.

[gdoron]

Thanks James!
I'm curios, how images getting corrupt like that, considering no one manually played with the raw bits in the image.

[JimBobSquarePants]

@gdoron Whatever originally encoded the image probably has a bug. Or maybe even something has happened during file copy in some instance. It happens often enough.

[gdoron]

It happens often enough

Yeah, we are getting many images like that lately... 😢

[JoepDiskTuna]

Indeed no end marker. Added one.

[gdoron]

@JoepDiskTuna Welcome to GitHub...! 🎆 (it says you joined today).
Thanks for fixing the image, but we'll need a fix for the problem as we're getting more and more corrupted images like this one.

[JoepDiskTuna]

Ah, ok. I understand. I was just looking into JPG corruption and errors and all that and that's how Google got me here.

In the end, the file was 'corrupt'. Just minor of course. Just check start and end markers for a start would be a good thing. But I don't have to tell you that.

[vaindil]

@JimBobSquarePants I have some time in the near future, I'm going to see if I can figure out how to bypass this. I'll keep you updated here; I assume you want to close #83 as a dupe.

[gdoron]

Great @vaindil! It's our top 1 bug on our website... 👍 👍 👍
Thanks mate!

[vaindil]

This probably isn't ideal, but for the moment I can work around it like this:

try
{
    var imageTest = new Image(stream);
}
catch
{
    stream.Seek(-2, SeekOrigin.End);
    stream.WriteByte(0xff);
    stream.WriteByte(0xd9);
}

stream.Seek(0, SeekOrigin.Begin);
var image = new Image(stream);

[JimBobSquarePants]

Yeah that's nasty!

We should have an MCU count in the decoder, working out whether to throw should be a case of checking against that count. If you could have a look that would be awesome. I would suggest looking at the source code for JpegSnoop on GitHub, that can detect missing EOI markers, warn and successfully decode them.

[vaindil]

I spent a good amount of time looking over it, and I cannot for the life of me figure out how to properly get the correct location of the EOI marker. I found a ton of resources but can't find a definitive way to get the info of where the file should end. :/

[JimBobSquarePants]

No worries, thanks for trying. It's on my list of thinks to work through so will get it done eventually.

[tocsoft]

renaming to make the 2 issues different as one seems to be more easily fixable then the other.

[tocsoft]

@gdoron I just merged a fix for none-progressive jpegs... updating to the latest ImageSharp.Formats.Jpeg should help stop some of the issues your seeing, probably won't fix them all but it should help a bit.

[antonfirsov]

@gdoron It seems we managed to fix this.

Yeah, we are getting many images like that lately...

I would be very happy if you could provide some feedback about the situation with your inputs based on our latest build! :smile:

[gdoron]

I'll upload a new version of our application tomorrow with the latest build and let you know.

Thank you all!

[gdoron]

@antonfirsov So far it's cool 👍
Thanks a ton mates!