Some PNGs decode and others don't

[cbitterfield]

This has been driving me half crazy. Some PNG Files work and some don't. I am using https://notisrac.github.io/FileToCArray/ to convert the files.

file1: Works (MacOS Screenshot) file2: Doesn't work. (Created with Krita and a simple circle)

I have tried pngcheck, ImageMagick and other tools to figure this out.

  chunk IHDR at offset 0x0000c, length 13
    98 x 93 image, 32-bit RGB+alpha, non-interlaced
  chunk sRGB at offset 0x00025, length 1
    rendering intent = perceptual
  chunk eXIf at offset 0x00032, length 98: EXIF metadata, big-endian (MM) format
  chunk iTXt at offset 0x000a0, length 468, keyword: XML:com.adobe.xmp
    uncompressed, no language tag
    no translated keyword, 447 bytes of UTF-8 text
  chunk IDAT at offset 0x00280, length 1650
    zlib: deflated, 32K window, superfast compression
    row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
      1 2 2 2 2 2 4 0 0 0 1 0 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 4 4 4 2 4 4 4 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 4 4 0 2 2 4 4 4 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 4 1 0 0 0 1 1 2 2 2 2 (93 out of 93)
  chunk IEND at offset 0x008fe, length 0
No errors detected in file1.png (6 chunks, 93.7% compression).```

```File: file2.png (12871 bytes)
  chunk IHDR at offset 0x0000c, length 13
    340 x 240 image, 32-bit RGB+alpha, non-interlaced
  chunk iCCP at offset 0x00025, length 366
    profile name = icc, compression method = 0 (deflate)
    compressed profile = 361 bytes
  chunk cHRM at offset 0x0019f, length 32
    White x = 0.3127 y = 0.329,  Red x = 0.64 y = 0.33
    Green x = 0.3 y = 0.6,  Blue x = 0.15 y = 0.06
  chunk bKGD at offset 0x001cb, length 6
    red = 0x00ff, green = 0x00ff, blue = 0x00ff
  chunk pHYs at offset 0x001dd, length 9: 2834x2834 pixels/meter (72 dpi)
  chunk tIME at offset 0x001f2, length 7: 11 Sep 2023 11:06:56 UTC
  chunk IDAT at offset 0x00205, length 12145
    zlib: deflated, 32K window, maximum compression
    row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
      1 2 2 2 2 2 2 2 2 2 1 4 1 1 1 1 1 1 1 1 1 4 4 4 4
      1 4 4 4 4 4 4 4 4 2 2 4 2 2 4 2 2 2 2 2 2 2 2 2 2
      2 4 4 4 4 4 4 4 4 4 4 2 4 2 4 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 4 4 4 4 4 4 4 4 4 4 4 4 4 2 2 2 2 2 2 2 2
      2 4 2 4 4 2 4 4 4 4 4 4 4 4 4 4 4 4 4 4 1 1 4 1 1
      1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 (240 out of 240)
  chunk tEXt at offset 0x03182, length 37, keyword: date:create
  chunk tEXt at offset 0x031b3, length 37, keyword: date:modify
  chunk tEXt at offset 0x031e4, length 38, keyword: icc:copyright
  chunk tEXt at offset 0x03216, length 29, keyword: icc:description
  chunk IEND at offset 0x0323f, length 0
No errors detected in file2.png (12 chunks, 96.1% compression).```

[bitbank2]

Provide the actual files and I'll take a look. Are you checking the return codes? Perhaps your second file uses the interlaced option which isn't supported due to the higher RAM requirement on MCUs.

[cbitterfield]

The files are not interlaced. But let me put together some test code and examples later today

——————————————————— Colin A. Bitterfield Mailto: @.*** Mobile: (571) 533-4700 ———————————————————

On Sep 17, 2023 at 8:03 AM -0400, Larry Bank @.***>, wrote:

Provide the actual files and I'll take a look. Are you checking the return codes? Perhaps your second file uses the interlaced option which isn't supported due to the higher RAM requirement on MCUs. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[cbitterfield]

It looks like the issue was self inflicted. I did not see the display "MAX_SIZE" parameter. Changing that fixed my issue. However I was able to get larger images sometimes. I also set the profile as sRGB/BuiltIn and model RGB/Alpha

Recommendations:

1. MAX_SIZE automatic determination for display.
2. Example from SD Card (pulling file, and a example with a subdirectory for the image)
3. Using ImageMagick, a convert statement that takes an image and puts in the proper form. (I would have a resize parameter in the example)

If I get industrious, I'll right a python3 function for the #3 and to create the .h file. The one I downloaded was old and had issues.

[bitbank2]

I try to avoid using external dependencies in my C libraries (e.g. malloc) because they're written to run on MCUs with no OS. This is why I prefer to pre-allocate static blocks of RAM at compile time.