PNG files are exported with 2 extra 00 bytes at the end.

[steveschnepp]

A fresh exported file is :

$ xxd.exe New\ Piskel.png 
00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452  .PNG........IHDR
00000010: 0000 0010 0000 0010 0806 0000 001f f3ff  ................
00000020: 6100 0000 5249 4441 5438 4f63 64a0 1030  a...RIDAT8Ocd..0
00000030: 52a8 9f81 6606 fc07 ba8c 28c3 b129 225a  R...f.....(..)"Z
00000040: 33c8 fbe8 06a0 6b06 f1b1 a983 071d 2103  3.....k.......!.
00000050: 400a f11a 82cd 0062 5c86 d305 3009 645b  @......b\...0.d[
00000060: 4972 017a b220 18a0 4445 15be c436 6a00  Ir.z. ..DE...6j.
00000070: 91e9 1d5f 2002 006f de0b 1198 4bbf 8300  ..._ ..o....K...
00000080: 0000 0049 454e 44ae 4260 8200 00         ...IEND.B`...

One can notire the 2 extra 00 after 44ae 4260 82.

Using OptiPNG fixed it.

$ optipng.exe -nb -nc -np -nx -v -fix New\ Piskel.png
OptiPNG version 0.7.8
Copyright (C) 2001-2023 Cosmin Truta and the Contributing Authors.

** Processing: New Piskel.png
Warning: Extraneous data found after IEND
16x16 pixels, 4x8 bits/pixel, RGB+alpha
Recoverable errors found in input. Fixing...
Input IDAT size = 82 bytes
Input file size = 139 bytes

Trying:
  zc = 9  zm = 8  zs = 0  f = 0         IDAT size = 42
  zc = 9  zm = 8  zs = 1  f = 0         IDAT size = 42
  zc = 1  zm = 8  zs = 2  f = 0         IDAT too big
  zc = 9  zm = 8  zs = 3  f = 0         IDAT too big
  zc = 9  zm = 8  zs = 0  f = 5         IDAT too big
  zc = 9  zm = 8  zs = 1  f = 5         IDAT too big
  zc = 1  zm = 8  zs = 2  f = 5         IDAT too big
  zc = 9  zm = 8  zs = 3  f = 5         IDAT too big

Selecting parameters:
  zc = 9  zm = 8  zs = 1  f = 0         IDAT size = 42

Output IDAT size = 42 bytes (40 bytes decrease)
Output file size = 99 bytes (40 bytes = 28.78% decrease)

** Status report
1 file(s) have been processed.
1 error(s) have been encountered.
1 erroneous file(s) have been fixed.

The file doesn't contain any extra data in the end.

$ xxd.exe 'New Piskel.png'
00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452  .PNG........IHDR
00000010: 0000 0010 0000 0010 0806 0000 001f f3ff  ................
00000020: 6100 0000 2a49 4441 5438 cb63 6018 b6e0  a...*IDAT8.c`...
00000030: ffa0 d1fc 9f54 03ff e310 fb4f 8a01 ffa9  .....T.....O....
00000040: e12d 6483 fe53 122e ff19 46c1 1000 0032  .-d..S....F....2
00000050: e90f f147 8eb3 e500 0000 0049 454e 44ae  ...G.......IEND.
00000060: 4260 82                                  B`.

[aaaaaa123456789]

Having been shown this issue due to a parsing library I wrote, I feel obligated to point out that every PNG file must end at the IEND chunk: in other words, the last 12 bytes of every valid PNG file must be 00 00 00 00 49 45 4e 44 ae 42 60 82.

[aaaaaa123456789]

Some further testing from @steveschnepp has shown that files always get zero-padded to a multiple of three bytes. That would point to me towards a potential base 64 deserialization bug, where the trailing = characters are treated as zeros (i.e., A) instead of being treated as the padding they are. (Base 64 strings are usually padded to a multiple of four characters, i.e., three bytes after deserialization.)

Unfortunately, I'm not good enough at JS to locate the bug, but maybe that would be something to investigate?

[grosbouddha]

After some quick testing, I couldn’t reproduce the issue (the exported PNG ends with the expected hex ae 42 60 82, no extra padded 00).

Could you share/attach the original culprit .piskel file here so we can check if it’s platform-related (we use platform/browser APIs like canvas/blob/dataURI to convert to PNGs) or specific to the artwork?

Thanks!

How to export to a .piskel file:

[steveschnepp]

It is rather easy to reproduce :

1. Use a sample from the homepage https://www.piskelapp.com/p/create/sprite/?spriteKey=losange-pattern
2. Click on "Export"
3. Choose "Selected frame Export"

You'll download pattern-1.png.png that has 2 trailing 00

$ xxd pattern-1.png.png
00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452  .PNG........IHDR
00000010: 0000 0020 0000 0020 0806 0000 0073 7a7a  ... ... .....szz
00000020: f400 0000 7349 4441 5458 47ed 94c1 0d00  ....sIDATXG.....
00000030: 2108 04a1 418a a541 4f4d 3036 708c 8f35  !...A..AOM06p..5
00000040: 3112 3f0e ecae 6e66 636e 8b88 759c 9599  1.?...nfcn..u...
00000050: bbfe fbde 7180 d9e1 9ec0 eab8 baed acbd  ....q...........
00000060: 000a a263 ecb7 acef 0074 8efd 7e8b 37a1  ...c.....t..~.7.
00000070: 52a0 14e0 1f11 6e42 1c00 9740 29c0 25c0  R.....nB...@).%.
00000080: 4d88 03e0 1228 05b8 04b8 0971 005c 02a5  M....(.....q.\..
00000090: 0097 0037 210d f001 0ede a867 299d 8a21  ...7!......g)..!
000000a0: 0000 0000 4945 4e44 ae42 6082 0000       ....IEND.B`...

[steveschnepp]

Note, if I use Edge, I have a different file, but still the bug.

$ xxd.exe  'pattern-1.png (1).png'
00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452  .PNG........IHDR
00000010: 0000 0020 0000 0020 0806 0000 0073 7a7a  ... ... .....szz
00000020: f400 0000 a449 4441 5478 01ec d64b 0ac3  .....IDATx...K..
00000030: 300c 8461 9303 fab0 be60 9a6f 31c6 9bee  0..a.....`.o1...
00000040: 5c07 8a20 8386 3fa0 c88f 815c adb5 9b7a  \.. ..?....\...z
00000050: eff7 2a8c 56c6 63c4 afc2 6865 3c46 fc2a  ..*.V.c...he<F.*
00000060: 8c0c f0d4 f79e eb99 aad1 1863 4ec1 63c4  ...........cN.c.
00000070: e705 8f11 bf83 cf1d 4853 8df9 34e7 31e2  ........HS..4.1.
00000080: 77f3 3940 1a9f ae73 80ac d02a f90c c263  w.9@...s...*...c
00000090: c4ef e697 a6e4 0369 ce63 c4ff 92cf 1dc8  .......i.c......
000000a0: 474e d74a c1fb 4790 33cf 8573 e9f8 53bc  GN.J..G.3..s..S.
000000b0: 5250 29a8 1454 0a2a 0595 824a 41a5 a052  RP)..T.*...JA..R
000000c0: f0ff 29c8 bfe5 b7fa 0100 00ff ffb4 c5fb  ..).............
000000d0: 7200 0000 0649 4441 5403 007e 93a8 87d7  r....IDAT..~....
000000e0: d59a 0a00 0000 0049 454e 44ae 4260 8200  .......IEND.B`..

The comment from @aaaaaa123456789 is interesting since xxd always shows that it is padded

[aaaaaa123456789]

Those two files are being padded to 174 and 240 bytes respectively — both multiples of three.