Cannot parse some png fetched from web
sonictl opened this issue · comments
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!!
If I download the parse_fail into PC and put that png into <project_root>/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.
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?
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?
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.