rgbds: Crash when converting image with alpha channel

Well, the original report had that ball.png which was non-indexed, but it also works with an indexed file:

$ file ball-indexed.png 
ball-indexed.png: PNG image data, 8 x 8, 8-bit colormap, non-interlaced

$ sha1sum ball-indexed.png 
e838fa5b6f3d7f53659920ef257dce98f8bee771  ball-indexed.png

$ ./rgbgfx -vvvvv -c "#FFFFFF,#cfcfcf,#686868,#000000;" ball-indexed.png -o /dev/null
rgbgfx v0.6.1-32-g73e9aac1
Options:
	Bit depth: 2bpp
	Maximum 8 palettes
	Palettes contain 4 colors
	Explicit palette spec
	[
		#ffffff, #cfcfcf, #686868, #000000,
	]
	Input image slice: 0x0 pixels starting at (0, 0)
	Base tile IDs: [0, 0]
	Maximum 65535 tiles in bank 0, 0 in bank 1
	Input image: ball-indexed.png
	Output tile data: /dev/null
Ready.
Using libpng 1.6.37
Reading tiles...
Opened input file
PNG header signature is OK
Input image: 8x8 pixels, 8bpp palette, not interlaced
Embedded palette has 2 colors: [#00000000, #000000ff]
Image colors: [ #000000ff, #00000000, ]
Image contains 1 proto-palette
[ $0000, ]
{ 6739, 35ad, 0000, }
Generating unoptimized tile data...

Thank you for reporting the issue!

I have had a similar bug report via IM, though @datguywitha3ds didn’t have assertions enabled so it instead misbehaved a lot. (So there is at least another reproducer; I don’t have it at hand, can Valentina attach it, please?)

I’m guessing the issue is that the presence of an alpha channel reduces the palette size to 3, but this is not taken into account when validating the palette spec. (Though I don’t think Valen used -c, so the issue may lie deeper.)