White/gray/black etc does not work as a main color

[Cryslacks]

Currently, colors which all of R G and B are equal, example #FFFFFF or #CDCDCD does not recolor the main red color of the gauntlet. These colors which are grayscale colors ranging from white to black, seem to revert to the original red color. (Mostly, which some shading differ)

Also darker/brighter versions of the same color does not differ, example dark blue (almost black) #26262A and bright blue (almost white) #E4E4FD do not differ.

Example of white and very very bright teal:

Note that all of these do work as a secondary color.

[denaelc]

Thanks for reaching out! Currently, the (primary) color only supports hue shifts. I'm actively working on improving this but can't provide an ETA right now.

[Tobler44]

Came here for the same issue. Is this being worked on? If not do you take pull requests if I tinker with it?

[denaelc]

I'm currently tied up with some irl stuff, but yeah - it is being worked on. You are always welcome to make pull requests (you can dm me on discord if you want to go into specifics). It's surprisingly difficult to allow saturation/brightness changes, since we have very few bits to work with - you tend to loose a lot of detail quickly.

[topi20104]

I'm currently tied up with some irl stuff, but yeah - it is being worked on. You are always welcome to make pull requests (you can dm me on discord if you want to go into specifics). It's surprisingly difficult to allow saturation/brightness changes, since we have very few bits to work with - you tend to loose a lot of detail quickly.

Could you elaborate about "allow saturation/brightness changes"? Does this mean its not allowed to manipulate such values for graphics within Runelite?

[denaelc]

No, you can manipulate them just fine (the plugin handles this for the secondary color).

I'll assume you're familiar with the HSB color system, so here’s what's happening on the development side:

We have a total of 16 bits to represent the final color. Starting from the most significant bit, we allocate 6 bits for hue, 3 bits for saturation, and the last 7 bits for brightness.

Given this, we use a reference color (65452 in decimal), which represents about the average color of the default gauntlet. This breaks down into 63 for hue, 7 for saturation, and 44 for brightness (all in decimal).

Next, the plugin takes the user’s requested color values. For example, if the user provides 23 for hue, 3 for saturation, and 19 for brightness, the plugin calculates the "color difference" between these values and the reference (63 - 23 = 40; 7 - 3 = 4; 44 - 19 = 25). This difference is then applied to every other color in the gauntlet.

For hue, this generally works well because the gauntlet's structures tend to have consistent hue values. However, for saturation and brightness, this can cause issues due to the complexity of the structures (many lit or shadowed parts). This often leads to values falling outside the allowable range, either below 0 or above their maximum bit value. I can't allow these values to loop around, as that would result in bizarre, broken layouts.

As a result, many colors hit their minimum (0) or maximum values for saturation or brightness, which leads to a monochrome gauntlet where objects are indistinguishable.

However, if I limit the saturation and brightness changes to only affect the lit-up parts (which I do for the secondary color), the complexity issue disappears, since these parts usually have more uniform values.

To be clear, this is a solvable problem, but it requires fine-tuning or a different approach. For now, to ensure the plugin is in a usable state, I've opted to restrict changes to only the hue of the primary color.