Re: [hatari-devel] Screenshots in NEO format

On Wednesday, January 3rd, 2024 at 00:18, Brad Smith <rainwarrior@xxxxxxxxx> wrote:

I ended up taking a quick look at the simpler proposal I mentioned. When saving a PNG screenshot, this compares the output image against the current 16-colour ST palette, if there are any mismatches it just does the RGB image as before, but if they all fit it creates a palettized PNG instead. The changes are fairly minor:

https://github.com/hatari/hatari/pull/30

So, for most ST screenshots this will give a PNG with palette that matches the original exactly, and provides insight about the original 16-colour palette used, in their correct order etc., allows palette-based editing, has a smaller file size.

In cases where there are raster effects or modes with more colours it just falls back to RGB as before.

There's an "imperfect" case where the palette has duplicate colours. In that case it will just use the first colour in the palette that matches. So, these cases will still look correct and use the correct colours, at least, and would still be valid to convert into an ST-ready image.

-- Brad Smith

On Tue, Jan 2, 2024 at 3:18 PM Brad Smith <rainwarrior@xxxxxxxxx> wrote:
Resizing or resampling should be easy to avoid. In the current state of things, I think the easiest way to resolve this is to set Hatari to 320x200 output so there is no border or pixel doubling, then your screenshots will already be in the shape you need. Otherwise if you need to deal with doubled pixels any image conversion program should be able to resize by simply discarding every second one, usually called something like "nearest neighbour" or "no filter" resampling.

The separate problem is getting the original palettized form of the screen. NEO format aside, I think it would also be useful if we could output a 16-colour PNG with the original palette with the image using their original pixel colour indices. With that we could do a 1:1 conversion to any other desired format. It would also be helpful when debugging or working with ST graphics to be able to inspect the original indexed image data.

Screenshots generically need to be able to handle anything going on, every resolution, mid-screen palette changes, etc. so the current method of just dumping the SDL output to a PNG is sensible, but it does mean that we're abstracted from the original screen data at that point.

We could take the SDL screen pixels, compare with the current ST palette, and re-index the colours of the output if they all fit that palette, and otherwise fall back to RGB output, before outputting the PNG image. That would almost cover the need, though cases where the same colour is used twice in the palette couldn't be disambiguated this way. Perhaps the current video buffer could be checked and correlated to pick up that case as well.

Alternatively a separate feature could be created, like screenshot, but instead just dumps palette+video memory to a file, exactly what Jeff is doing manually. This would deliberately fail to consider mid-screen changes, and would be more of a technical tool for someone who needs that, perhaps. Maybe NEO format is suitable, though it seems slightly rigid as a format.

-- Brad Smith