Use ST palette for PNG screenshots if possible #30
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Added support for GenConvert so high resolution, TT, Falcon, etc. are capable of using the palettes too. Tested PNG AVI output as well, which appears to have no problem with indexed PNGs, even if their palette changes over time. |
|
I now had a quick look at your patches here, and I think the whole PixelConvert_16to8Bits() should not be necessary anymore. Hatari now always uses 32 bpp for indexed ST screens (see commit 4d78e24). Also, could you please rebase your patches to the current upstream master branch (and squash the typo fix and the other fixes into the corresponding patches)? Thanks! |
huth
pushed a commit
that referenced
this pull request
Jan 15, 2024
Notes from Brad Smith (#30) : This allows PNG screenshots to use the ST palette where possible. A palettized image has a few advantages. The file size is slightly smaller. Any graphics program that can view the palette can now be used to see what the ST's 16-colour palette looked like at the time of screenshot. It makes palette-based editing of the image easier (e.g. changing colours). Conversion into an ST-ready image format is also more straightforward. This automatically falls back to a full RGB image if the image contains any colours outside the current ST palette. This means that modes with more colours, or mid-screen palette changes will still produce valid screenshots as full RGB. This works for low res and med res video modes. NOTE 2 : As the Hatari UI also uses its own colors, you need to check "Crop Statusbar" in the "Hatari Screen" menu to ensure the status bar is not included in the screenshot. If not, it will use more colors than the emulated screen and resulting PNG will be saved as RGB image and not as palettized image.
|
Looks like @npomarede went ahead and included your patch (with the fixes squashed). Thus I think we can close this pull request now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tried this out in response to a discussion from the mailing list. It allows PNG screenshots to use the ST palette where possible.
A palettized image has a few advantages. The file size is slightly smaller. Any graphics program that can view the palette can now be used to see what the ST's 16-colour palette looked like at the time of screenshot. It makes palette-based editing of the image easier (e.g. changing colours). Conversion into an ST-ready image format is also more straightforward.
This automatically falls back to a full RGB image if the image contains any colours outside the current ST palette. This means that modes with more colours, or mid-screen palette changes will still produce valid screenshots as full RGB.
In the case where the palette has multiple colours that are identical, they will all be remapped to the first colour with that index. So, if all 16 colours are unique, it will be a 1:1 mapping to the ST in-memory image, but if there is ambiguity it will still show the correct colour, just with potentially the wrong index. A "perfect" version would maybe use the current video memory contents to disambiguate this case, but that would be a bit more complicated to accomplish. This PR instead does the best it can with only the output image and current known palette.