search

bitbank2 / JPEGDEC

An optimized JPEG decoder for Arduino
Apache License 2.0
366 stars 47 forks source link

Decoding of a seemingly intact file fails #7

Closed portasynthinca3 closed 3 years ago

portasynthinca3 commented 3 years ago

I'm writing a simple app for ESP32 that would allow me to type in a Wolfram|Alpha query on a PS/2 keyboard and view the results on a display using its Simple API, which returns an image in the GIF format with a single frame containing the result. Unfortunately, I didn't find any GIF libraries (I'm sure I just didn't look close enough). So, because this is just a personal project, I decided to bodge an online GIF-to-JPEG conversion API. I feed it a WA query URL, it returns a link to the resulting JPEG image. ESP32 then downloads this image into SPIRAM and hands it to JPEGDEC to decode. But sometimes this results in a corrupted, not completely drawn image (most of the time it doesn't, but but sometimes it does). Also, I've noticed that if this happens, subsequent attempts at drawing the image will also fail; and if this doesn't happen in the beginning, it won't happen in the future. The CRC32 checksum of the file in the ESP32 RAM matches one of the file I downloaded to my PC. Checksums also stay the same on each callback call (I was testing for memory corruption), and ESP-IDF heap corruption checks always pass.

One particular case I can give is: WA query: plot y=1/(x^2) Resulting JPEG returned by the conversion API: link CRC32 checksum of the file (matches everywhere): 0x76866797 Corrupted Image drawn on the display:

bitbank2 commented 3 years ago

The link you shared doesn't work for me. Please email me a test image (bitbank@pobox.com)

You should know that I have written a GIF animation lib that runs on the ESP32:

http://github.com/bitbank2/AnimatedGIF

It's portable code that can run on Arduino as C++ or any other system as C.

portasynthinca3 commented 3 years ago

Wow, I didn't notice that library at all, thank you, I'll try it. I sent the image in question to your E-Mail.

bitbank2 commented 3 years ago

Found the problem and fixed it (release 1.2.1). The initial reading of image data wasn't filling the input buffer, so the check against the high water mark was failing and allowing the decoder to go past the end of actual data. I tested your image and now it works correctly.