The following two guidelines in the standard specific Ranking Criteria don't really do a great job at recommending/advising against what they're intended to do.

osu! Ranking Criteria wrote:

Avoid using combo colours, slider borders or hitcircleoverlays with ~50 luminosity or lower. Dark colours like these impact readability of approach circles with low background dim and the other elements partially give up their functions as borders.

osu! Ranking Criteria wrote:

Avoid using combo colours with ~220 luminosity or higher during kiai times. They create bright pulses which can be unpleasant to the eyes.

Reason being that the in game "luminosity" (the L in HSL), which can be seen when selecting a custom colour, is not actually perceived brightness, but rather the lightness of the colour. This means regardless of hue, a colour with the same lightness will end up having the same "luminosity" (see HSL/HSV in the below picture).



The human eye is naturally more sensitive to green/red than blue, leading to colours like yellow being apparently brighter than blue, something which HSL does not account for.

Because of this, blue colours at the minimum accepted luminosity will be much darker than yellow colours at the same threshold, leading to inconsistencies in the perceived brightness recommended. This does not make sense considering that the intention of both guidelines is to prevent combo colours from being too visually bright or dark in gameplay.

I would propose using the HSP Colour Format instead of the in game one for measuring this. The thresholds specified here are the equivalent to what the old guidelines had. Adding the formula as part of the glossary prevents issues rooting from relying on third party sources.

Proposal wrote:

Perceived brightness: The brightness of the HSP Colour Format is calculated using the following formula:
sqrt(0.299 * R ^ 2 + 0.587 * G ^ 2 + 0.114 * B ^ 2 )

Proposal wrote:

Avoid using combo colours, slider borders or hitcircleoverlays with ~53 perceived brightness or lower. Dark colours like these impact readability of approach circles with low background dim and the other elements partially give up their functions as borders.

Proposal wrote:

Avoid using combo colours with ~233 perceived brightness or higher during kiai times. They create bright pulses which can be unpleasant to the eyes.

Following these changes, colours such as these would no longer be recommended (the brighter ones only in kiai), but are fine according to the current guidelines:


Whereas these would be fine even after the changes:


These are not recommended according to current guidelines (again brighter ones only in kiai):


Whereas those same colours would be fine after the changes, until made like this, at which point they would no longer be recommended:


Only problem with this is that it's much less convenient to find whether some colour is potentially too dark/bright, since you can no longer simply look at the "lum" value in the custom combo colour window, but it is a lot more accurate in determining the brightness, and has neither any false-negatives nor false-positives unlike the current method.

These are guidelines and don't necessarily need to be applied very strictly, so favouring accuracy over convenience would make sense. It is also easier to judge the brightness of combo colours like this using common sense, since they are now literally how bright or dark you perceive them to be, rather than based on some "lum" variable behind the scenes.

how much testing was done on this? the proposed guidelines make sense and can be adopted, because when originally proposed we didnt even have a reference for what the luminosity value in the rgb color picker in edit represents we just tested around to arrive at these numbers

If you mean the thresholds, these are adapted directly from your own findings, and are equivalent to that of the current. Using only black and white, what is too dark using the current guidelines is also too dark using these, only difference is that this also takes into account how bright the colour itself is.

I'm unsure of what exactly was intended with the "too bright" guideline since even completely white colours look fine on my monitor, so I can't really test that properly (although I did try as you can see in the initial post). I've done a fair amount of testing for the darker colours, though, and the proposed thresholds basically stop the colours from getting any darker at the following R, G and B values respectively, compared to the current luminosity based method:

Proposed:


Current:


You'll notice the green is clearly the brightest in the current method, with blue being the darkest, whereas they are all basically the same brightness using the proposed method. The same logic seems to be applicable to brighter colours as well, regardless of whatever threshold is used.

This is hella convoluted don't you think? Even the original guideline, which made sense I guess, was rarely ever brought up or followed. There are a few qualified and ranked maps with combo colors above lum 220 too, no one really checks for these things.

You can define luminosity sure, I'm not saying all this technical jargon is completely unnecessary, but consider how many people are realistically going to follow this. I certainly don't expect BN's to open up the color menu and check individual combo colors, so the thought of having to plug numbers in to confirm if they surpass the "perceived brightness" threshold is even more silly. Your examples already show plenty of combo colors that are difficult to assess. Sure, if the combo color is white, or extremely light, its reasonable to expect BN's to maybe check luminosity, but those green/blue/yellow ones, no one would have even considered them as breaking guidelines even though they do. There'd be no way for anyone to know if the colors they chose have broken some guideline unless they actually calculate brightness on their combo colors. If you tell me people do that, you're lying lmao.

My solution btw, is just removing these guidelines and replacing them with "Don't use combo colors that are to dark / too bright" and letting people decide on limits with whoever is nominating their maps.

I would agree it's extremely unlikely that people would actually calculate all their colours, or even the colours of other maps when nominating, but it's always helpful to have some point of reference when needed, rather than having to rely on something as vauge as "can't be too dark or bright".

Better to have something as guide than to let really dark colours be ranked using the justification that some other map also had equally dark colours or similar. This sort of thing could easily spiral out of control with how many nominators there are, hence why guidelines are important.

Again, being guidelines, they have room for leniency and don't have to be applied very strictly, so people should be able to simply rely on common sense for most of this stuff anyway, and it's not like it's a hard cut-off, as indicated by the "~". These guidelines barely having to be used only supports that.

As for complication, the in game luminosity might as well be equally convoluted, only difference being that the numbers are more accessible. I don't think the Ranking Criteria's accuracy should be hampered by the limitations of the game purely by something being inconvenient. This sort of thing could easily be built into aimods as well, so I don't really see much harm in changing it this way.

To be completely honest I don't think people are going to change the way they check maps based on some minor changes to seemingly unimportant guidelines. So this is essentially your own solution but with the potential of being applied more consistently in the future.

this seems to be such a complicated way to check something that is rather.. well. subjective?

The main problem as you mentioned is that it's a lot less convinient to check these new luminosity values. The most ideal case would be if it was built into the in-game AIMod, but external tools is the next best thing I guess.

I'm fine with having the guidelines becoming more accurate in this regard.

Relaxing the guideline to be vague isn't the right way to go in my opinion, since discussions could needlessly go on forever if we don't have some sort of line to draw (I mean we're just talking about combo colours, let's just draw a line and move on with it).

It does seem complicated, and having such a formula written into the RC page seems pretty intimidating, but the alternative is keeping the current Lum values which can be a bit inaccurate so ¯\_(ツ)_/¯

fwiw im mostly concerned about dark colors in this regard, we noticed exactly that while testing but accepted it as "ah well whatever"

on the topic of bright colors: they only hurt me personally if i'm playing with hidden with no mod all's good so i dont exactly know most of the use cases for this actually applying past uhh loctav i guess

The discussion could go on forever for a lot of other things too: Whether a slider is overlapping on itself too much, whether a slider is borderline burai etc... whether a repeat arrow is considered unreadable due to being too closely overlapped by another object, whether a background is nsfw or not, whether combo colors are too similar or blend with the bg/storyboard/video, etc... Are you guys going to start defining parameters for those ones too? Because we could. For example you could define a minimum difference between combo color hex values in order to keep them apart, or a minimum number of ms between repeat arrow and a preceding object etc...

Like I said, this is just a convoluted way to define something completely unnecessary. Let people work it out amongst themselves. Among many things, the ranking criteria rework was aimed at making rules more accessible and easier to apply for mappers, and this is just a ridiculous amount of verbose jargon meant to sound smart but achieve next to nothing lol.

i think the current guideline in the rc using luminosity is good enough, it covers what it needs to and gives a general guideline (because it is a guideline) of what may be too bright/dark using more solid values for people to refer to if needed. the proposed formula, while more accurate, is also very complicated and sounds unreasonable to expect anyone to check with. even if you were to assume it could be built into third party apps, that would be disadvantageous to users that don't know such apps exist.


if anything, i'd think this formula should be kept in mind and automatically integrated into lazer's combo color choosing window to automatically display a warning for too dark/bright colors.

but... please don't make osu require an algebra major for combo colors



also by the way why is darkness of combo colors only addressed in the osu! rc so specifcally when ctb just has a general vague wording? like can we just steal their wording




by the way by the way, on the topic of combo colors

Nobody is going to want to go through the work to plug their colors into an equation to find out if their color is rankable / follows the guidelines -- I agree this is an overly complicated proposal. Dark colors haven't been a huge problem any time recently tbf. If combo colors really need to be changed, just saying "these colors are too similar" or pointing to the current rc isn't a hard thing to do (some people are saying the 50/220 rule is still to dark/light, so even raising that would be ok).

I appreciate the work that went into analyzing this, but it would work better as a guide to using combo colors effectively, vs. an objectified rule in the rc imo.

Didn't read everything into detail, but considering this has some maths involved (which nobody will do tbh), I think the best way to implement this somehow in the game is through a recommendation coming from the actual editor in the client, which basically means for devs to do some coding.

I don't think anyone will actually do the math or use the formulas, which is why I think having it left up to the nominators' discretion with a guideline of "don't go too dark or too light" would be more realistic. I understand the intention is to make it so that there's a hard line in case there's a big disagreement or something, but I would think this is really an issue that would have that be a common enough problem to warrant the inclusion of this formula. my two cents.

Yeah figured it would be too complicated, whole reason why I even brought this up was because I had already done all of the experimentation for an aimod I'm working on, and convenience definitely isn't an issue there. Just found it amusing how the RC is recommending people to rely on a flawed metric just because it's the easiest to see the value of.

We can keep the current versions though if that's what people are most comfortable with. I suppose changing it this way makes for more than a hassle than it's worth for mappers without external tools and such, and it's not like the inaccuracy of the luminosity values are causing any significant issues anyway.

I 100% support the concept behind what this is, but it's just too complicated for people to reasonably use and reference.
imo this would be fine if implemented as follow the original luminosity guidelines, but in cases of uncertainty use the new guideline

I think the best solution is to add a line that states luminosity is not all-encompassing and that you should use reasonable judgement when using colours around the thresholds

if nobody's going to check it by the new standard (as it seems people in this thread are hinting at), i'd prefer to keep the rc using the old imperfect one because it's close enough to warn people when their combo colors are too dark/light

for a more vital map issue i'd say hard-to-calculate-accuracy > convenience, but combo colors aren't worth the tradeoff

if you provide a means to easily accessibly check for it i wouldnt mind it tbh

Okoratu wrote:

if you provide a means to easily accessibly check for it i wouldnt mind it tbh

this

Okoratu wrote:

if you provide a means to easily accessibly check for it i wouldnt mind it tbh

revive the proposal if this happens

this thread is going to the archive