-
-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow rgbgfx -c embedded
to accept embedded palettes with extra unused colors
#1064
Comments
No, because they may be expecting the extra colours to end up in the generated palette even if they aren't used. Ignoring extra colours if both |
How would that be a reasonable expectation when the palette is four colors? |
If it's four colours, then they would be used, and emitted in any order unless Grayscale sorting makes more sense by default, since on DMG, palettes are a single byte—not something you'd want to |
I was talking about the GBC palette. How would it be reasonable to expect palette data to contain more than four colors (even if the image does) when the GBC palettes can only contain four colors? |
If it contains 8, it means 2 palettes of 4 colours, for example. |
Though it'd be impossible to actually have pixels using those additional 4-color subpalettes without |
This is the same non-issue as #1074: |
Continuing discussion from #1062:
Currently
rgbgfx -c embedded
expects the PNG's indexed PLTE chunk to define exactly four colors. Some users may have PNGs with more than that (e.g. 256 colors), but only use colors 0-3. Arguably this should be a supported use case.The text was updated successfully, but these errors were encountered: