Skip to content
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

[Feature request] Specify -c/--colors as a DMG grayscale ordering #1594

Open
Rangi42 opened this issue Jan 3, 2025 · 1 comment
Open

[Feature request] Specify -c/--colors as a DMG grayscale ordering #1594

Rangi42 opened this issue Jan 3, 2025 · 1 comment
Assignees
Labels
enhancement Typically new features; lesser priority than bugs rgbgfx This affects RGBGFX
Milestone

Comments

@Rangi42
Copy link
Contributor

Rangi42 commented Jan 3, 2025

When --colors are not specified, RGBGFX has a complex heuristic for sorting its palettes, which depends on the invisible PNG encoding. (A grayscale image will be converted differently if it has an indexed palette, which can happen by accident; and if there is no indexed palette, the brightness ordering depends on whether it happens to be grayscale or not.)

A common case is to encode four-color grayscale images. This is actually a fragile use case: your PNG might have an indexed PLTE chunk that messes up your expected order; and you may have a pixel error that puts two grays in the same bin, uses RGB mode instead, and sorts by lightness.

The original request for palette specs in #487 also discussed specifying a DMG-style grayscale palette, but it isn't yet a feature.

I think that being able to specify -c dmg:0xe4 would be very useful. It would require RGBGFX to use grayscale mode, so it would just error if that's not possible, instead of silently doing something different. And the user would have control over the order of those hues.

This is something the pret disassemblies (and I think the LADX disassembly as well) would be able to use right away. pret now uses a custom tool to derive appropriate .pal files from colored sprites, which is then passed as -c gbc:custom.pal. But most graphics are just grayscale, which relies on them being encoded as 2-bit grayscale PNG. (We could in theory pass -c #fff,#aaa,#555,#000, but then users who inevitably use inexact colors like #505050 would fail.)

(I could have sworn we really had this option at some point, as something like -d 0xe4. Then again, I also was pretty sure that pret or one of my projects was already passing -c #fff,#aaa,#555,#000, but they're not -- if we ever did, it was removed for... some reason.)

@Rangi42 Rangi42 added enhancement Typically new features; lesser priority than bugs rgbgfx This affects RGBGFX labels Jan 3, 2025
@Rangi42 Rangi42 added this to the 0.9.1 milestone Jan 3, 2025
@Rangi42 Rangi42 self-assigned this Jan 3, 2025
@Rangi42
Copy link
Contributor Author

Rangi42 commented Jan 3, 2025

#575 also discusses this feature and seems approving of it, or at least not citing any reason not to implement it. Looks like it just fell through the cracks as we had so much else to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Typically new features; lesser priority than bugs rgbgfx This affects RGBGFX
Projects
None yet
Development

No branches or pull requests

1 participant