Closed cbjeukendrup closed 6 months ago
The question is, should any color that is not black or white remain as it is, or be inverted as well? (For example, should red stay red or should it become cyan?) It would probably make more sense to not invert all the colors besides black and white, but then the name "Invert score" might be a bit misleading.
What I might suggest is to convert the values to HSV and preserve the "hue" and "saturation", but invert the "value". The idea being, someone might have selected a relatively dark red to stand out nicely on white, but that same red won't stand out so well on black, so replace it with a light red. Mid-value colors would remain unchanged. Probably there is some algorithm out there for this.
@cbjeukendrup could you please use American English spelling, at least for the title ? I knew this issue exists but had difficulties finding it (to mention it in https://musescore.org/en/node/345925)
Yes, changed it. (It's my auto-correct that turns everything into British English...)
@MarcSabatella I think you mean to swap the 'saturation' and the 'value'. In that case bright red stays bright red while dark red and pink swap places. If you just mirror the 'value' then bright blue (on white) becomes black (on black), which is likely not what you intent. Or equivalently, if you use a 'hue', 'saturation', 'lightness' model and then you can mirror the 'lightness'.
The way I learned it in art classes, value is lightness. So yes, I want to turn a dark color into a light color, while keeping the hue (red vs blue) and saturation (= intensity; pure color vs dull).
@MarcSabatella Okay, then we agree. From draw/types/color.cpp I think the colour is stored in rgb (and ɑ), so then a possible (simple) algorithm is (for r,g,b values 0 to 255):
This formula looks a bit odd, but correctly rescales M to (255 - m) while keeping the chroma C = M-m fixed. The lightness L is M - C/2 and that becomes (255 - m) - C/2 = 255 - L, so that should look about how you intended it. Please do check if this is what you meant; there are other ways of inverting the lightness but this is the only linear model.
Edit: Removed an 'if'; that was there to avoid division by 0, but the division disappeared after simplifying.
When in doubt, try it out. Then post images of the result ;-)
This is what the above linear algorithm looks like. The odd columns are input, increasingly dark colours on a white background. The even colours are output, increasingly light colours on a black background. To check that the algorithm works for arbitrary colours, here is the same table but with the top row of odd columns randomly generated:
Images made in Mathematica.
OK, now is seems time to implement that in MuseScore
This looks cool! Can I work on this?
@limse10 Your implementation seems to correctly work for custom colours, but note that it also changes the default colour from the slightly grayish white to white. Was this intentional? I didn't account for that in my pseudocode (which was intended for custom colours, sorry for that), but you could e.g. check if x is 255 and if so set it to 220 instead? Or you could also argue that anything above a certain brightness should then also be dulled and use an inequality?
Anyway personally I don't mind if you leave it like this, but I thought I should let you know that this is changing the default behaviour for people who don't use colour.
@PepijndeMaat You're right, it was an oversight on my part. I've updated it so that if the resulting color is pure white, it sets it to the dulled white instead. Values in between 220 and 254 are left as is. I would justify it as "if the user wanted to change colors, they are allowed to do so" but default behavior should not be modified. Thanks for letting me know!
Should an in-house design person look over the colours, @Tantacrul?
@limse10, I think we should get @jessjwilliamson (our colour genius) to take a look at this. Jess, once you've had a peek, we can quickly discuss to make sure everything else is hunky dory? Also @bkunda for visibility.
By the way, your fix for tablature BG colours is really cool. However, I would suggest you submit that in a separate PR. In particular, we need to make sure that PDF export / transparent PNG export does not contain those colours.
By putting them together, it means that the PR is harder to review and if there's a major problem with one thing, we have to reject everything.
Came up again in https://musescore.org/en/node/362222
To Reproduce Steps to reproduce the behavior: