MudColor: Add Lerp

[ScarletKuro]

Description

Adds Lerp function to MudColor: https://en.wikipedia.org/wiki/Linear_interpolation

Would be useful for: #10263

After looking, I feel like these can be very useful to be inside the MudColor. Lerp is very common thing when working with colors.

How Has This Been Tested?

Unit tests, checked with other lepr online tools that output is tolerable

Type of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation (fix or improvement to the website or code docs)

Checklist

• The PR is submitted to the correct branch (dev).
• My code follows the code style of this project.
• I've added relevant tests.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.52%. Comparing base (9d51a38) to head (520b3f4).
Report is 6 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev   #10275      +/-   ##
==========================================
- Coverage   91.52%   91.52%   -0.01%     
==========================================
  Files         414      414              
  Lines       12989    12996       +7     
  Branches     2452     2452              
==========================================
+ Hits        11888    11894       +6     
  Misses        555      555              
- Partials      546      547       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[ScarletKuro]

I highly doubt that the human eye can perceive the difference between 0.058823529411764705 and 0.06.

Reasons to avoid fractions:

1. They are not human-readable.
2. I haven't come across any online tools that work with fractions.
3. In real-world color scenarios, no one would create a color with such a fraction.

This is why, in the math operation:

MudBlazor/src/MudBlazor/Utilities/MudColor.cs

Line 567 in b551df2

public static MudColor operator +(MudColor color1, MudColor color2)

I also avoid creating MudColor with high precision alpha fractions. Otherwise, when performing color math, the A value often ends up as a fractional number, which would rarely match with any blending tool from real world which makes it hard to compare it with real world colors.

@danielchalmers @henon opinion?

[henon]

I am pretty sure these high precision values were copy-pasted from a color swatch tool. I am ok with two digit alpha values.

[danielchalmers]

How about 2 sig figs: 0.059, a difference of 0.3% instead of 2% @ScarletKuro

[ScarletKuro]

The idea was that APercentage

MudBlazor/src/MudBlazor/Utilities/MudColor.cs

Line 86 in e1476a6

public double APercentage => Math.Round(A / 255.0, 2);

Already rounds to two decimal places, so I thought it would make sense to apply this rounding to the string representation as well. I also looked at the W3C CSS Color Module and only saw precision with two decimal places. I'm not an expert in Chroma.js, it seems that the .css() function also returns only two decimal places. That's why imo this default behavior is optimal for human perception, storage, and practice?
Thoughts?
But either way idm three decimal places as well. It was more to rise that current ToString definitely shoudn't have this much decimals.

[danielchalmers]

I think one extra digit is worth it for the accuracy since it's still significantly more readable. Diminishing returns after that.

[danielchalmers]

But your way is definitely common as well

[ScarletKuro]

Hmm, I tried using 3-digit precision, and a few issues came up.

1. It would be logical to make APercentage use 3-digit precision as well, but this breaks more existing tests.
2. I noticed that even our color picker is using two decimal places of precision.
   

So, what should we do? Here are the options:

1. Leave MudColorOutputFormats.RGBA with 2-digit precision, as I originally did. This way, everything will align.
2. Change MudColorOutputFormats.RGBA to 3-digit precision, but leave APercentage with 2 digits. The APercentage and alpha in RGBA will then be inconsistent.
3. Change both MudColorOutputFormats.RGBA and APercentage to 3-digit precision and update all the tests. This would be the most time-consuming path and would also visually change the color picker, as it would now display alpha with 3-digit precision.

[henon]

I think two digits are fine. It means we have 100 different levels of opacity. I am pretty sure that no one can judge the difference between 0.53 and 0.525 opacity with the naked eye.

[ScarletKuro]

I also think methods like GetTint and GetShade makes a lot of sense, This would also make GeneratePalette method to easy to implement and GeneratePalette and static method for MudColors.
Having common color operations like Lerp/Tint/Shades make a lot of sense to me considering there is HSL built in the MudColor.

[ScarletKuro]

I also think methods like GetTint and GetShade makes a lot of sense, This would also make GeneratePalette method to easy to implement and GeneratePalette and static method for MudColors. Having common color operations like Lerp/Tint/Shades make a lot of sense to me considering there is HSL built in the MudColor.

Ohhhh, the built-in ColorLighten and ColorDarken already do exactly this, the words Tint and Shared are just more common in tools, so I didn't pay attenion. So yeah this make sense to add GeneratePalette after this PR.

[ScarletKuro]

Not sure -+* operators are useful considering the range 0-255, can do Lerp without them

[henon]

Not sure -+* operators are useful considering the range 0-255, can do Lerp without them

They don't hurt, so let's keep them.

[ScarletKuro]

Reverted 3 precision for now. because of this post #10275 (comment), waiting for final decision:

Hmm, I tried using 3-digit precision, and a few issues came up.

1. It would be logical to make APercentage use 3-digit precision as well, but this breaks more existing tests.
2. I noticed that even our color picker is using two decimal places of precision.
   

So, what should we do? Here are the options:

1. Leave MudColorOutputFormats.RGBA with 2-digit precision, as I originally did. This way, everything will align.
2. Change MudColorOutputFormats.RGBA to 3-digit precision, but leave APercentage with 2 digits. The APercentage and > > alpha in RGBA will then be inconsistent.
3. Change both MudColorOutputFormats.RGBA and APercentage to 3-digit precision and update all the tests. This would be > > the most time-consuming path and would also visually change the color picker, as it would now display alpha with 3-digit precision.

Anyways this is ready for review. The palette generator based on tints and shades I will do separately.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ScarletKuro]

I'm reverting the precision completely. This will be done in a separate PR.
After analyzing the fractions, I have some new thoughts, and I think @danielchalmers is right—three decimal places would be more optimal than two.

Alpha is just an integer from 0 to 255, so if we divide it by 255 to see the fractions, this is what we get:

0 / 255 = 0.000
1 / 255 = 0.0039
2 / 255 = 0.0078
3 / 255 = 0.0118
4 / 255 = 0.0157
5 / 255 = 0.0196
6 / 255 = 0.0235
7 / 255 = 0.0275
8 / 255 = 0.0314
9 / 255 = 0.0353
10 / 255 = 0.0392
11 / 255 = 0.0431
12 / 255 = 0.0471
13 / 255 = 0.0510
14 / 255 = 0.0549
15 / 255 = 0.0588
16 / 255 = 0.0627
...

As we can see, with only two decimal places of precision, some integer values will return the same percentage. For example, both 12 and 13 would round to 0.05. This means that if we wanted to reverse the result, we would never be able to get back to one of these specific integer values. However, with three decimal places of precision, we can differentiate them.
Also some tools use 0-255 instead of two digit decimals percentage, so I think it would be fair to support these two cases.

[danielchalmers]

Don't forget (regarding 2% being imperceptible)

Researchers estimate that up to 12 percent of females have four cone types in their retinas, rather than three. These individuals have the potential to perceive 100 times more colors than the rest of us.

https://www.aao.org/eye-health/tips-prevention/how-humans-see-in-color