[kuschku]

Sure, but the goal is that the user sets their brightness for the environment, and not ever for individual software.

The per-application brightness should be done in software, and ideally take into account HDR and colorspace capability of the software.

Otherwise, like the user above had suggested, you have to switch brightness every time you switch between different programs.

[kbutler]

> the goal is that the user sets their brightness for the environment, and not ever for individual software.

...and we've come full-circle:

"Keep high contrast, reduce brightness as desired for your environment."

[kuschku]

Correct, but software then needs to be explicitly mapped with a brightness range.

Otherwise you can't have on the same screen a game simulating a dark night with low contrast, and a guide for that game which uses the full contrast spectrum.

Your suggestions all break if I want to be able to have at the same time extremely low contrast content and text on the same screen, next to another, and want both to look fine.

[kbutler]

> extremely low contrast content and text on the same screen, next to another, and want both to look fine.

With that scenario, you're dealing with physiological limitations, because if you have a bright region next to a dark night region, your eyes cannot perceive detail in the dark region. You'll also be vulnerable to the optical illusion effects of perception (e.g., see http://www.cns.nyu.edu/~david/courses/perception/lecturenote... and other examples in http://www.cns.nyu.edu/~david/courses/perception/lecturenote...), so "look fine" is going to be rather hard to define, much less guarantee.

But this discussion was really about interfaces, potential interest in monochromatic interfaces, and the issues of low-contrast interfaces.

This article from the Nielsen/Norman group clearly describes the usability problems with the currently trendy low-contrast interfaces. https://www.nngroup.com/articles/low-contrast/

[kuschku]

> With that scenario, you're dealing with physiological limitations, because if you have a bright region next to a dark night region, your eyes cannot perceive detail in the dark region.

Correct, that's why you meed a software solution that detects this issue and dynamically adapts.

This isn't complicated either, every modern video game has the issue of UI, text, and HDR content in one frame, and has well-working tonemap curves and dynamic exposure adaption algorithms.

Microsoft is also integrating solutions for this into Windows.

Any OS that plans to ever mix HDR and SDR content on one screen needs this anyway, and if you do that, you can also easily add minor changes to allow text content to be annotated so its contrast can also be dynamically adjusted.