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

Colorblindness filters (possibly implemented as additional palettes) #146

Open
Lehmanator opened this issue Jun 10, 2024 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@Lehmanator
Copy link

Is your feature request related to a problem? Please describe.

As a colorblind dev, I often would like to know how a certain color would appear to people with normal color vision.

Designers and developers often want to know how their colors would look to colorblind users.

Describe the solution you'd like

Not entirely sure of a good UI for this feature, but I think a minimal effort implementation could reuse the existing palettes UI to display this information.

There are two implementations that could neatly integrate with the palettes UI:

  • One row, displaying both the filter for the colorblindness type and its inverse
  • Two rows, one for the filter for the colorblindness type, one for its inverse.

so basically, the palettes UI could have either three or six additional rows.

This would help both:

  • users with normal color vision understand the colors perceived by colorblind users.
  • users with colorblindness understand the colors perceived by users with normal color vision.

Combined Rows

Rows would correspond to:

  1. Protanopia
  2. Deuteranopia
  3. Tritanopia

Each row would have to have an odd number of colors with a minimum of 5 colors for there row to have one-to-one correspondence with filter and its inverse.

Swatch colors would correspond to:

  1. Max severity
  2. Average severity
  3. User-selected color
  4. Average severity inverse
  5. Max severity inverse

If UI horizontal space permits, rows could show additional colorblindness strengths, with values chosen according to:

  • Constant sized scale ranging from [0, max] strength.
  • Equidistant midpoints between [0, avg] & [avg, max] strengths, with average always being between these ranges.
  • Common values according to population prevalence, sorted by strength. (idk if colorblindness severity is multi-modal or normally distributed). If prevalence is multi-modal, values could correspond to modes. If severity prevalence follows a normal distribution, values could correspond to standard deviations of severity.

This heuristic would also apply if implemented with individual rows for colorblindness filters and filter inverses.

Individual Rows

Rows would correspond to:

  1. Protanopia
  2. Deuteranopia
  3. Tritanopia
  4. Protanopia (inverse)
  5. Deuteranopia (inverse)
  6. Tritanopia (inverse)

Swatch colors would correspond to:

  1. User-selected color
  2. Average severity
  3. Max severity

with additional values chosen following one of the heuristics described above.

Describe alternatives you've considered

There are probably a lot of other ways this feature could be implemented in UI, but my described behavior would probably be the easiest to implement and require the fewest UI changes. It also could integrate with the export functionality of the palettes feature.

Filter strength sliders or filter strength value settings would be desirable, but would require additional UI changes.

Even better would be to also implement screen/window/region selection like GNOME's screenshot functionality and apply a colorblindness filter. Obviously, that would require a lot more work and is potentially out-of-scope for this application.
DaltonLens implements this behavior, but it would be nice to have a GNOME native UI for this sort of thing.

Additional context

Some resources:

@Lehmanator Lehmanator added the enhancement New feature or request label Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant