musescore / MuseScore

MuseScore is an open source and free music notation software. For support, contribution, bug reports, visit MuseScore.org. Fork and make pull requests!
https://musescore.org
Other
12.29k stars 2.66k forks source link

[MU4 Issue] Colored notes (and other elements) don't appear colored when "invert score colors" is enabled #16506

Closed cbjeukendrup closed 6 months ago

cbjeukendrup commented 1 year ago

To Reproduce Steps to reproduce the behavior:

  1. Change the colour of some note or other element using the Properties panel or a plugin -> the coloured note appears coloured correctly
  2. Go to Preferences > Appearance and enable "invert score" -> the coloured note appears just white
GabeS573 commented 1 year 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.

MarcSabatella commented 1 year ago

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.

Jojo-Schmitz commented 1 year ago

@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)

cbjeukendrup commented 1 year ago

Yes, changed it. (It's my auto-correct that turns everything into British English...)

PepijndeMaat commented 1 year ago

@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'.

MarcSabatella commented 1 year ago

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).

PepijndeMaat commented 1 year ago

@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.

Jojo-Schmitz commented 1 year ago

When in doubt, try it out. Then post images of the result ;-)

PepijndeMaat commented 1 year ago

image

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:

image image

Images made in Mathematica.

Jojo-Schmitz commented 1 year ago

OK, now is seems time to implement that in MuseScore

limse10 commented 1 year ago

This looks cool! Can I work on this?

PepijndeMaat commented 1 year ago

@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.

limse10 commented 1 year ago

@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!

RobFog commented 1 year ago

Should an in-house design person look over the colours, @Tantacrul?

Tantacrul commented 1 year ago

@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.

Jojo-Schmitz commented 6 months ago

Came up again in https://musescore.org/en/node/362222