search

lvgl / lv_lib_png

PNG decoder for LVGL
MIT License
66 stars 26 forks source link

invalid ADLER32 while drawing image #23

Closed glory-man closed 2 years ago

glory-man commented 2 years ago

I try to draw attached png on the screen and received error 58 - invalid ADLER32 encountered. At the same time, this image is normally opened by any desktop-image-viewer. Is this an image problem? Is it possible to fix it? car

kisvegabor commented 2 years ago

Maybe the image is slightly corrupted and full featured desktop viewers can handle it.

I suggest opening and saving the image. Hopefully it'll fixes it.

glory-man commented 2 years ago

Maybe the image is slightly corrupted and full featured desktop viewers can handle it.

I suggest opening and saving the image. Hopefully it'll fixes it.

I thought about it, but unfortunaly not helped. I was able to draw image by disabling adler32 checking.

glory-man commented 2 years ago

By the way errors 57 & 58 description tells that - (checking CRC can be disabled) / (checking ADLER32 can be disabled). So in lodepng.h may be added code like this

#ifdef LV_PNG_IGNORE_ADLER32 #define LODEPNG_IGNORE_ADLER32 1 #else #define LODEPNG_IGNORE_ADLER32 0 #endif

#ifdef LV_PNG_IGNORE_CRC #define LODEPNG_IGNORE_CRC 1 #else #define LODEPNG_IGNORE_CRC 0 #endif

So in decompress initialization function may be used LODEPNG_IGNORE_CRC/LODEPNG_IGNORE_ADLER32 instead of 0/1. In this case we don't need edit sources to configure library.

kisvegabor commented 2 years ago

I've just downloaded the image form your first post and it worked for me.

lodepng was update a couple of month ago. Do you use the latest version from the master branch?

glory-man commented 2 years ago

I've just downloaded the image form your first post and it worked for me.

lodepng was update a couple of month ago. Do you use the latest version from the master branch?

I use lvgl_v7 as part of zephyr os. I made zephyr-module lv_lib_png based on commit 7ff6168764893d658375a9c3173337506ff4eb1b. As far as I understand later commits mades for lvgl_v8 which is incompatible with lvgl_v7

kisvegabor commented 2 years ago

What if you overwrite lodepng.c/h with the latest versions? There shouldn't be v8 related stuff there.

It might also worth a try to download the image from your post. Maybe GitHub converted it.

glory-man commented 2 years ago

What if you overwrite lodepng.c/h with the latest versions? There shouldn't be v8 related stuff there.

It might also worth a try to download the image from your post. Maybe GitHub converted it.

I'll try it. Thanks.

glory-man commented 2 years ago

What if you overwrite lodepng.c/h with the latest versions? There shouldn't be v8 related stuff there.

It might also worth a try to download the image from your post. Maybe GitHub converted it.

I tried latest version of lodepng.c. This file uses lv_fs_seek(&f, 0, SEEK_END) with 3 params (inside lodepng_filesize), while in lvgl_v7 it has only 2 params. So I use lv_fs_size(&f, &size); to detect size of file. But file still not opened without disabling adler32 checking.

kisvegabor commented 2 years ago

And have you downloaded the image from GitHub (from your first comment)?

glory-man commented 2 years ago

And have you downloaded the image from GitHub (from your first comment)?

Yes. I tried with image downloaded from github. In debugger unsigned ADLER32 = lodepng_read32bitInt(&in[insize - 4]); called in _lodepng_zlibdecompressv function gives me 0xC0C64FFD, while unsigned checksum = adler32(out->data, (unsigned)(out->size)); gives 0xBF592DC8, out->size = 0x230

kisvegabor commented 2 years ago

I have no idea :slightly_frowning_face:

I've tested it again and out->size = 0x230 for me too but checksum = 0xc0c64ffd.

glory-man commented 2 years ago

I have no idea 🙁

I've tested it again and out->size = 0x230 for me too but checksum = 0xc0c64ffd.

I founded a problem. I use custom allocator function, where lodepng_realloc was incorrect. Fixed by using lv_mem_realloc.

kisvegabor commented 2 years ago

Glad to hear that!