search

bitbank2 / PNGdec

Arduino PNG image decoder library
Apache License 2.0
162 stars 25 forks source link

Cannot parse some png fetched from web #8

Closed sonictl closed 2 years ago

sonictl commented 2 years ago

Thanks for this well-coded library! It works well on most png file. However, there's a certain type of png files that I didn't manage to decode properly so far.

I received rc code == 6 when running "rc = png.open()" function in the example of LittleFS_PNG given in this repo.

In developer tool of Chrome web browser, if you look into the data obtained after GET, some differences can be found. === For your re-building this problem === The parse_OK png data can GET from this url The parse_fail png data can GET from this url

The code I used for testing: for PNG fetching: LittleFS_Web_Jpg (modified for png instead of jpg) for PNG parsing: https://github.com/Bodmer/TFT_eSPI/blob/master/examples/PNG%20Images/LittleFS_PNG/LittleFS_PNG.ino The png fetched from url above (http://restapi.amap.com/) is neccessary for me. Any suggestions and fixing method will be very appreciated! Thank you!!

sonictl commented 2 years ago

If I download the parse_fail into PC and put that png into /data, build the littleFS fileSystem and upload it to ESP32. The parse_fail png will be parsed normally.

I need to download the png from web, store it into littleFS, parse it from littleFS file. Then, the parse_fail png data will not be decoded.

bitbank2 commented 2 years ago

So you've isolated the problem to be with LittleFS? Sorry, but it sounds like the PNG library can decode the data and it's a streaming problem outside of my code. Can you explain why you think this is a problem with the PNG decoder?

sonictl commented 2 years ago

diff url cause diff parsing png result. i.e. some urls are OK while some not. Will downloading the fail png into PC change the png data? If yes, maybe the PC re-formated the png file. Such that, if build&upload littlefs filesystem with that png file downloaded from bad url, that png can be correctly decoded.

The fail png has the response headers containing Content-Encoding: gzip, while the parse-ok png fetching has no gzip encoding text contained in HTTP GET response headers. Can it be the gzip causing this issue?

bitbank2 commented 2 years ago

It may be, but my point is that the PNG decoder has no ownership of file handling or streams. The code has callbacks for user code to provide a source of data. If PNG data is delivered to the decoder with the HTTP header preceding the image data, that issue is outside the scope of the PNG decoder.