Skip to content

Conversation

@Rangi42
Copy link
Contributor

@Rangi42 Rangi42 commented Dec 1, 2025

Fixes #1863

image

@Rangi42 Rangi42 added this to the 1.0.1 milestone Dec 1, 2025
@Rangi42 Rangi42 requested a review from ISSOtm December 1, 2025 19:46
@Rangi42 Rangi42 added docs This affects the documentation (web-specific issues go to rgbds-www) rgbgfx This affects RGBGFX labels Dec 1, 2025
@Rangi42
Copy link
Contributor Author

Rangi42 commented Dec 1, 2025

@quinnyo Do you think the above rewrite is more clear?

Copy link
Contributor

@quinnyo quinnyo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your efforts!

This is certainly an improvement, but it seems to be a better description of what I understood/expected the feature to be. It doesn't clarify the behaviour that caught me out.

The observed behaviour (#1863) indicates that the transformation is not applied when outputting palettes, but more universally to all colour inputs. The behaviour that surprised me is that this includes colours from a palette in the native format of the target platform.
Given a palette in the native format of the target platform, it would not be unreasonable to assume the palette is in the native colour space of the target platform.

Additionally, the phrase "when outputting palettes" may imply that the behaviour is conditional on whether or not a palette file is being written out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs This affects the documentation (web-specific issues go to rgbds-www) rgbgfx This affects RGBGFX

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RGBGFX badly describes the effect and purpose of --color-curve

2 participants