For Latte I am using a different way to determine Luminance..

https://en.wikipedia.org/wiki/Relative_luminance

something like

property real luminance = 0.2126*r + 0.7152*g + 0.0722*b

values above 0.65 threshold I consider them light and lower I consider them dark...

In the internet some are proposing 0.7 as threshold...

In color picker I use:

// formula for luminance according to https://www.w3.org/TR/2008/REC-WCAG20-20081211/#relativeluminancedef

                        var a = [color.r, color.g, color.b].map(function (v) {
                            return (v <= 0.03928) ? v / 12.92 :
                                                    Math.pow( ((v + 0.055) / 1.055), 2.4 );
                        });

                        return a[0] * 0.2126 + a[1] * 0.7152 + a[2] * 0.0722;

@broulik do you know why this part is needed?

var a = [color.r, color.g, color.b].map(function (v) {
                return (v <= 0.03928) ? v / 12.92 :
                                        Math.pow( ((v + 0.055) / 1.055), 2.4 );
});

See https://www.w3.org/TR/2008/REC-WCAG20-20081211/#relativeluminancedef

What will it look like now? Screenshot?

With dark button background as it used to

Seems pretty good!

+1

In D11262#224062, @Pitel wrote:

With dark button background as it used to

but if you choose some crazy combination (like black text on green background) it will also work (without this patch the background here would be still black)

Would you be interested in producing similar patches for the Lock and Login screens, which suffer from the same issue?

• Login screen: https://bugs.kde.org/show_bug.cgi?id=388622
• Lock screen: https://bugs.kde.org/show_bug.cgi?id=369676

In D11262#224113, @ngraham wrote:

Would you be interested in producing similar patches for the Lock and Login screens, which suffer from the same issue?

• Login screen: https://bugs.kde.org/show_bug.cgi?id=388622
• Lock screen: https://bugs.kde.org/show_bug.cgi?id=369676

Those two seem to be a bit more complicated because the logout screen covers the desktop by some color overlay so we know how the background looks. But with login & lock screen there is only picture on the background and no color overlay.

Adding color overlays on them seems unnatural and ugly. Other thing I tried is to add Glow effect. It solves readability problem but I do not like how it looks and documentation says it also needs OpenGL.

Using background dependent color would require to calculate an "average color" of an image in qml and I do not see how to do that. So the only solution I see right know is to add config options to select text color for lock & login screens.

I see that relative luminance formula is more correct but I would like to point out that we do not need here to calculate precise luminance. The point of the ?: statement is to collapse colors close to back to real black because gray overlay with 50 % opacity does not look good. So the current formula looks good enough for me and I would even think about moving the threshold down a bit to 0.4 or 0.3. (Generally not collapsing to black is the save way, it may not look so good but the text will be still easy to read.)

For reference a screenshot with gray background (similar to default breeze) without collapsing it to black:

In D11262#224843, @Pitel wrote:

I see that relative luminance formula is more correct but I would like to point out that we do not need here to calculate precise luminance. The point of the ?: statement is to collapse colors close to back to real black because gray overlay with 50 % opacity does not look good. So the current formula looks good enough for me and I would even think about moving the threshold down a bit to 0.4 or 0.3. (Generally not collapsing to black is the save way, it may not look so good but the text will be still easy to read.)

yep, gray background definitely doesn't look good.
can you try with the luminance formula and put a screenshot on how it looks?

I finally got to do some testing and it is not looking good for luminance formula 0.2126*r + 0.7152*g + 0.0722*b.

Screenshot with background color #5500FF (blueish, button background on picture), you can see that black text is readable on it, but it has luminance only 0.14 so in overlay it is replaced by black.

So I would rather stay conservative, and used formula max(r, g, b). I am still not sure whether the threshold should be 0.5 or a bit lower...

In D11262#235414, @Pitel wrote:

I finally got to do some testing and it is not looking good for luminance formula 0.2126*r + 0.7152*g + 0.0722*b.

Screenshot with background color #5500FF (blueish, button background on picture), you can see that black text is readable on it, but it has luminance only 0.14 so in overlay it is replaced by black.

So I would rather stay conservative, and used formula max(r, g, b). I am still not sure whether the threshold should be 0.5 or a bit lower...

You can adjust the coefficients. Please check color (0, 0, 128), which is - according to the committed way - considered a light color.

Maybe try something like (r+2*g+b) > 0.8.

I guess I should have renamed it from isLightColor to something like isNotAlmostBlack... The point was to replace almost black colors with real black because it looks better with opacity. IMHO (0,0,128), which is deep blue, is far enough from black to not mess with it because font colors readable on deep blue background might not be readable on black one.

This seems to be a bugfix - Plasma/5.12 branch as well?

It is meant as one. I am still kinda new here, so I am not exactly sure how to that (without confusing Phabricator).

In D11262#237032, @Pitel wrote:

It is meant as one. I am still kinda new here, so I am not exactly sure how to that (without confusing Phabricator).

Cherry-pick the commit into the destination branch, merge into master and push both.

Since it was already committed to the master branch, wouldn't just need to be cherry-picked into the Plasma/5.12 branch at this point?

In D11262#237036, @ngraham wrote:

Since it was already committed to the master branch, wouldn't just need to be cherry-picked into the Plasma/5.12 branch at this point?

That's exactly what I wrote?

I meant, we wouldn't need to subsequently merge it into master because in this case, it's already in master.

But yes, for the future, committing to the branch and merging to master is the preferred approach. You can actually use arc for this, for future reference: https://community.kde.org/Infrastructure/Phabricator#Landing_on_the_.22Stable_branch.22

5.12.4

Way too dark. A guy posted a 5.8 vs 5.12 on Neon's G+.

Ray, this fix hasn't made it into a release yet; it was just committed this morning. So we wouldn't expect someone using 5.12.4 to benefit from the fix yet.

Okay, Nate. It's good to know there's hope.

Will this also fix the aliasing in the logout screen?

https://plus.google.com/communities/105101838887387505413

@ragreen I am sorry to disappoint but this patch does not remove the (usually black) half-opaque overlay the G+ post refers to. It only changes its color to button background color in the case that button background color is too far from black to make sure the text is readable. I guess the readability of text was the reason to introduce the overlay in the first place because only blurring the background (like 5.8 seems to do) is not enough in general.

I am not sure what artifacts is he referring to (but I am usually blind to this kind of issues)...

It also should be in Plasma/5.12 now.

I guess the readability of text was the reason to introduce the overlay in the first place because only blurring the background (like 5.8 seems to do) is not enough in general.

@Pitel I'm sorry to say this but they had nailed it in 5.8, then they ruined it in 5.12.

I am not sure what artifacts is he referring to (but I am usually blind to this kind of issues)...

I'm not.

@ragreen, this isn't the right place for that kind of discussion. Phabricator Differential is used for patch and code review, not commentary on larger design decisions. If you'd like to start a conversation about whether the current UX is a regression (and I would agree with you, FYI), it should be done in an applicable Bugzilla ticket or Phabricator Task, such as T7682.

@ngraham You're right. Thanks for the heads-up.

In D11262#237099, @ragreen wrote:

I am not sure what artifacts is he referring to (but I am usually blind to this kind of issues)...

I'm not.

I did not mean that I want to ignore them, I just need them pointed out for me to start seeing them.

In D11262#237017, @Pitel wrote:

I guess I should have renamed it from isLightColor to something like isNotAlmostBlack... The point was to replace almost black colors with real black because it looks better with opacity. IMHO (0,0,128), which is deep blue, is far enough from black to not mess with it because font colors readable on deep blue background might not be readable on black one.

Ah okey. I had the impression this was used to decide if light or dark text needs to be used. I wouldn't want to see black text on dark blue buttons :)

It looks like that in Kubuntu 18.04 ...