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