Closed clbr closed 5 years ago
Interesting, may I ask for a 2-bit test file? One possibility is that the error lies with the PNG library (LodePNG) used, in which case I'll:
It's not completely unlikely the the error is in my code either, of course! ;) Also, thanks for showing interest in the tool!
PNG_TRANSFORM_PACKING is needed when using the official libpng; that converts 1, 2 and 4-bit images to 8-bit for easier handling. Perhaps lodepng has a similar loading flag.
Sample: https://sub.god.jp/f/yooaen.png
There is indeed a bug in my code. LodePNG handles the image just fine (and certain other codepaths in superfamiconv has no problem with it either). Good catch! ;)
Just updating, the same bug happens with 4-bit PNGs.
I finally got around to fix this bug (as per commit https://github.com/Optiroc/SuperFamiconv/commit/864d673913d485692f1e80f8321cacc28ff146e8) I don't have any software that can save out a 2/4-bit PNG, so I have only been able to test with the 2-bit image you sent me. I do believe 4-bit images should work too, though.
Gimp is free and available for every OS.
I gave it a shot (GIMP-2.10, OSX), but was unable to find these options. With an image in indexed format, but the export PNG dialog will still only list 8/16bpc color pixel formats.
My Gimp is older, 2.6, and doesn't have that dropdown at all. Try the "automatic" option in it anyway, maybe it matches the old behavior.
https://mail.gnome.org/archives/commits-list/2017-January/msg00084.html Yes, the automatic option will do that. For an indexed image with <= 4 colors, 2-bit; for <= 16 colors, 4-bit.
I got it working, and fixed 4-bit image loading. Curiously, the LodePNG library did not like the CRC of 4-bit PNGs saved by GIMP. I'm not sure who's in the wrong here, but I disabled the CRC check.
When twobit.png is 2-bit (as seen by "file", Gimp saves them like that if they have 4 colors), the output is all corrupted. When I convert it to 8-bit, superfamiconv correctly converts it, and test.png looks good.