Dfool of many colors

[Darth Fool]

I wish i could say it with numbers. Is that clear(er)?

*cough* - how about algebra?

Code: Select all

a mapping from unit png colour to modified team colour that is continuous at boundaries:

Href, Sref, Vref = Hue, Saturation, Value of colour in unit png (e.g. magenta)
Hteam, Steam, Vteam = HSV of team colour
Hout, Sout, Vout = replacement colour

case Vref >= Sref:
  Sout = Sref * Steam
  Vout = Vref - Sref * (1 - Vteam)

case Vref <= Sref:
  Sout = Sref - Vref * (1 - Steam)
  Vout = Vref * Vteam

Hout = Hteam

err, so that would give:
[*] almost white --> almost white
[*] almost black --> almost black
[*] 100% saturation and value --> exact team colour given
[*] everything else mapped linearly in between these 3 points.

HSV <-> RGB algorithms here

This may not be useful, but working it out was kinda fun .

If I am reading this properly, it is almost what we want, but it presumes that the 100% saturation/value should be used as the team color. This is probably a good assumption, but I think it would be good to be able to specify the exact point at which the "team color" should be substituted. Still, if this is what J & E prefer, I can do this.

[Jetrel]

Well, just as a warning (specifically to jetryl) I am planning on making the following change:

Instead of changing the value with the maximum total into the team color, I will change the first color listed into the team color. Colors with rgb totals less then this one will be appropriately shaded towards black, while those that have higher totals will be shifted towards white. I haven't thought about this in terms of HSV values, but I may see if it makes sense to do so, or at least to explain it in terms of HSV. The net result is that either the current images that jetryl has made will need to have their colors changed (an easy, but tediuous task if there are a lot), or we will need to have two versions of the Macro, the one for jetryl's existing images, and one which enables highlights. Hopefully, the code for this will be done sometime this weekend.

I did some long, hard thinking, and I think that yes, you should do this.

However, it's not going to solve our problem, which I believe lies in the team colors "sets" themselves. I say "set" with quotations, because IIAC in guessing what the code does, each team really only has one RGB value specified for it, right?

----

Let's refer to: http://www.wesnoth.org/forum/files/colo ... es_915.jpg

The problem is that the luminosity spans of our Team Colors are not normalized. Certain colors are brighter than others in their highlights. Yellow and white get very bright, and other colors like blue stay dark and muddy. This is what we have, with option A.

However, a strict normalization will result in all team colors approaching white at the top of their spectrum. Against bright colors, like yellow, this will look good, against dark colors like blue, this will look bad, because the highlights will look too harsh - almost washed-out. This is option B.

Option C is actually the way to go to solve this problem, but it needs to be described explicitly, which I can do, fortunately. What really needs to be done is to define, on a Per-Team-Color basis, both the color itself, and the maximum to which the color would rise. Bright colors like yellow would rise all the way to white. Dark colors like blue would rise only up to sort of a sky-blue.

The end effect is roughly that the changes in luminosity (between the bright part of a TC patch and the dark part) are similar in magnitude regardless of what team color you use.

If I am reading this properly, it is almost what we want, but it presumes that the 100% saturation/value should be used as the team color. This is probably a good assumption, but I think it would be good to be able to specify the exact point at which the "team color" should be substituted. Still, if this is what J & E prefer, I can do this.

It may be good to be able to do that (in fact, the more I think about it, it probably is). The problem is that right now, the end result color on the unit in-game is limited to a ceiling of 100% saturation of a specific hue. We need to lift that ceiling, but we need to do it differently for different team color sets, because the darker ones will need a lower ceiling.

[Eleazar]

...it is almost what we want, but it presumes that the 100% saturation/value should be used as the team color. This is probably a good assumption, but I think it would be good to be able to specify the exact point at which the "team color" should be substituted.

Um, are you saying Yobbo's formula:
a) wouldn't work with unsaturated team colors (like white)
b) would make the "target" TColor the maximum saturation?

[yobbo]

oops: to work properly for unsaturated colours, this needs to be added:

Code: Select all

if Steam == 0 or Vteam == 0:
  Sout = 0

That should override the calculated value. Then you get something like the attached image (using magenta as the reference colour, and the colour on the left as the team colour).

EDIT: hmm, tweaked code, maybe it matters, maybe it doesn't

[yobbo]

If I am reading this properly, it is almost what we want, but it presumes that the 100% saturation/value should be used as the team color.

Yep, that's right... I'm gonna attach a diagram of the mapping . wheeee

It just maps the magenta area in SV-space onto the cyan area in SV-space.

As it stands, it is not possible to map to the white area - i.e. the algorithm can't increase the vividness of the team colour. It can, however, increase the value (at the cost of saturation), and the saturation (at the cost of value).

It would be better to be able to define the colour that is mapped to the team colour (in stead of using 100% S/V) - but a bit more complicated .

[Eleazar]

Yobbo, your algebra may not convince me, but your diagrams make me think you are on the right track.

However, if fancy math doesn't end up giving us what our fuzzy-logic minds expect, we could always go the micromanagement way and assign 20-25 RGB values for each team color. Hopefully it won't come to that. It's a lot easier to define 1 RGB value for a new TColor than 20.

[Woodwizzle]

However, if fancy math doesn't end up giving us what our fuzzy-logic minds expect, we could always go the micromanagement way and assign 20-25 RGB values for each team color. Hopefully it won't come to that. It's a lot easier to define 1 RGB value for a new TColor than 20.

How about 3 colors instead of 20 (which is still not as good as one). A Color, and a Max and a Min. Then do a simple linear interpolation in between to get the other colors.

[Jetrel]

How about 3 colors instead of 20 (which is still not as good as one). A Color, and a Max and a Min. Then do a simple linear interpolation in between to get the other colors.

That's basically what I was hoping. You pick one color as the central color, which actually would probably get picked using the way that DFool suggested.

The magenta "to be replaced" set (for which I'm going to use the term TBRS for disambiguation purposes) has absolute/fixed limits. White and black. We could come up with a fancy system of changing this relative to what colors are used in the unit (eg, treating the maximum and minimum values used inside the unit, or used in the color set as the maximum point and minimum point, but this would be a bad thing to have. You want the artist to be able to intuit the range of values he's going to be using as he draws, at least somewhat. By having only one mathematical operation being performed (more or less) on the luminosity of his graphics, he can still do this.


The maximum and the minimum of the TBRS are mapped to the final, used-in-game team color set (TCS).

The max and min of the TCS are different for each TCS. Light ones use higher maxima and slightly higher minima, dark ones use lower maxima, and probably leave their minima at zero. These are defined wherever our current team colors are.

Linear interpolation would work fine, and would be relatively simple to code.

[Darth Fool]

Ok how about the following: instead of a single team color, there is in addition a max and minimum. Pure black will map to the minimum, pure white to the maximum, and the first color in the team_rgb list will be mapped to the team color. Other colors will be linearly interpreted between the three. If no max or min is specified they will default to white and black. Now, the question I have is, can this easily be done in RGB space, or should I do it in HSV space? I can imagine that in HSV space one could reduce the number of parameters since presumably the hue should not change, so you would only need to specify the range for the Saturation and Value(or should I say Brightness?)

[Jetrel]

Ok how about the following: instead of a single team color, there is in addition a max and minimum. Pure black will map to the minimum, pure white to the maximum, and the first color in the team_rgb list will be mapped to the team color. Other colors will be linearly interpreted between the three. If no max or min is specified they will default to white and black.

Yup.

Now, the question I have is, can this easily be done in RGB space, or should I do it in HSV space? I can imagine that in HSV space one could reduce the number of parameters since presumably the hue should not change, so you would only need to specify the range for the Saturation and Value(or should I say Brightness?)

Yobbo, do you want to figure this out, or shall I commence to ciphering?

[freim]

Suggestion:

* Make a new flag with nicer animations, which uses team-color like the ellipses
* Put it in images/misc/
* Remove all the color-hardcoded flags from images/terrain/

[Jetrel]

Suggestion:

* Make a new flag with nicer animations, which uses team-color like the ellipses
* Put it in images/misc/
* Remove all the color-hardcoded flags from images/terrain/

Duh. No really - "Duh."

I'm going to assault this, once I get something else done. I had tried at this earlier (some months ago), but did something rather stupid in the animations, hence I need to start from scratch.

In the meantime, please make the code work for it.

[Eleazar]

So, where are the team colors defined?
Is it something that could be tweaked without recompiling once we finalize the Tcolorizing engine?

Make the flags a bit bigger, taller while you are at it. It never made much sense to me to have a flag fly lower than many of the rooftops.

[Noyga]

Well since they are hardcoded, you must recompile if you change them.

Currently in the sources, file src/team.cpp, around line #916 you have something like this :

Code: Select all

	static const Uint32 sides[] = { 0x00FF0000,
	                                0x000000FF,
	                                0x0000FF00,
	                                0x00FFFF00,
	                                0x00FF00FF,
	                                0x00FF7F00,
	                                0x00898989,
	                                0x00FFFFFF,
	                                0x00945027,
	                                0x0002F5E1,
	                                0x00FF00FF };

These 10 first values are the RGB color values of the team colors (format : 0x00RRGGBB).

Also, the names of these colours displayed while creating MP games is defined in src/multiplayer_ui.cpp around line #78

[Darth Fool]

Amongst the other changes that I am making, it will be possible to define the default colors in WML. I will see about making the village flags properly effected as well.