mix() returns wrong result for added colors.

[dtinth]

When sending a color created from adding two colors together to the mix() function,

This is reproducable in LESS 1.4.1 and 1.5.1.

Test case 1

a {
  color: mix(#008 + #800, #FFF, 50%);
}

Expected result:

color: #c480c4;

Actual result:

color: #880088;

Test case 2

@a: #222;      // #222
@b: @a + #224; // #446
@c: #888;      // #888

a {
  a: @a;
  b: @b;
  c: @c;
  d: mix(@b, @c, 50%); // should be #667
}

Expected result:

d: #666677

Actual result:

d: #444455

Some more tests:

// These example should all equal #999

mix(#333, #fff, 50%) // #999999
mix(#222 + #111, #fff, 50%) // #333333
mix(#333, #eee + #111, 50%) // #FFFFFF
mix(#222 + #111, #eee + #111, 50%) // #999999
mix(#333 + #000, #fff + #000, 50%) // #999999

[seven-phases-max]

Interesting. I found that the problem is in alpha channel. Basically, an addition (or any other op) of two colors with alpha = 1 results in a color with alpha = 2, thus unexpected result when the result color passed to certain functions.

[lukeapage]

Great spot.

[lukeapage]

@seven-phases-max assume this is now fixed?

[seven-phases-max]

Yes, it is fixed.

[tomek-he-him]

@seven-phases-max, I'm expecting mix(@a, @b, 25%) to return the same result as overlaying @a with 1/4th of its opacity over an original-opacity-@b in any image editor. I guess this goes inline with the discussion in #2291. Do I get this right?

Now, the spec coming from our designer says that #2274AC + 25% black should equal #195781. I've double-checked in Inkcape and GIMP, getting exactly the same results:

And even so, less.js v2.3.1 returns #1a5781:

$ echo "a { b: mix(black, #2274AC, 25%); }" | lessc -
a {
  b: #1a5781;
}

I know it's only one unit in one channel – but enough to be another color than that from the spec. It does make a difference in our case.

[seven-phases-max]

@tomekwi

Let's see:
mix(black, #2274AC, 25%); ->
25% * black + 75% * #2274AC ->
75% * [34 167 129] -> [25.5 87 129] and
round(25.5) -> 26 -> 0x1a.

I.e. Less uses canonical rounding for non-integer color channel values when producing their hexadecimal representation while those graphics editors you mentioned seem to use floor for some reason. That's it. Note the rounding is not even a part of the mix function but the property of any rgb to hex conversion, e.g.:

div {
    color: (rgb(34, 116, 172) * 0.75); // -> #1a5781
}

So I can't see any issue here or anything that should or may be fixed at all (at Less side ;)

[tomek-he-him]

@seven-phases-max, thanks for clearing this out – could've checked myself actually :) To be honest, I only noticed that the difference is so small at the very end of writing the comment.

I'm almost certain our designer has used Photoshop for the conversion. So maybe it's some kind of standard amond image editors? If it is so, would you consider adjusting LESS's color rounding algorhithm?

I admit it doesn't make sense to floor the values. But you do aim to mimic the behaviour of image editors, don't you?

[lukeapage]

Is there a reason gimp uses different rounding though? If every other tool
has a different rounding method, shouldnt we change?

[lukeapage]

Reported before. Seems sass also floors.
#552

[lukeapage]

Cant find any more info. I suspect flooring may have become the norm
because the first implementation cast a float to an int which floors right?