Add `rgbgfx -c png` to specify palette specs as visible images

[Rangi42]

Each color would be a single pixel, read top to bottom, left to right. (So for two palettes a user might supply a 1x8 png, or 8x1, or 4x2, or even 2x4.) The png's encoding wouldn't matter, only the individual pixels' colors.

[evie-calico]

Why top to bottom? Left to right first seems more intuitive

[Rangi42]

I mean the standard row-by-row order of English reading, electron gun scanning, etc.

[aaaaaa123456789]

If we're going to do this, it might be worthwhile to also allow something like -c png42 to indicate that each color is represented by a 42×42 box instead of 1×1 (for any value of 42, of course). The reason for this is that many visualization tools will only reduce large images, but not expand small ones (or what's worse, use some sort of bilinear filtering when expanding small ones, creating lots of blur), which makes small images very hard to visualize outside of editing tools.

[Rangi42]

That sounds useful too, although it could be a follow-up issue once this one is resolved.

[evie-calico]

On second thought, i still think it would be worth being able to embed the palette in the first or last row of the image. For images which have unique palettes, I don’t see the point in creating a separate file with the palette definitions only for it to be used once. It only makes it more cumbersome to modify the palette, needing to do so in two files rather than one.

[ISSOtm]

I would make -c png:image.png determine the box size automatically (inferring it from the amount of identical consecutive pixels on the first row), and -c png,42:image.png/-c png@42:image.png (not : to avoid parsing ambiguities) to enforce a specific size.

For images which have unique palettes, I don’t see the point in creating a separate file with the palette definitions only for it to be used once. It only makes it more cumbersome to modify the palette, needing to do so in two files rather than one.

It's for consistency: if you are using -c png generically, it's okay; if you aren't using it for specific images, you might as well use at-files.

[Rangi42]

For images which have unique palettes, I don’t see the point in creating a separate file with the palette definitions only for it to be used once. It only makes it more cumbersome to modify the palette, needing to do so in two files rather than one.

Also you don't have to create a separate file; you should be able to pass rgbgfx -c input.png -o output.2bpp input.png.

[evie-calico]

But then it’ll read the image as a palette… that doesn’t make sense. if you make the first line of the image the palette you want to use, that line will show up in the output

[Rangi42]

Ah, you're right, I was thinking in terms of an indexed palette, but that's what embedded is already for.

[aaaaaa123456789]

I think what you're describing is some imaginary mode -c from:foo.png where the palette is taking from another file's indexed palette.

[ISSOtm]

At the very least, this should be compatible with the PNGs generated by contrib/view_palettes.sh.