Dyeing/Colorizing Unit Images

[redrum]

And now the Germans are fleeing! (flipped)

Properties

units.color.Germans=FF0000
units.color.British=00FF00
units.color.hsb.Russians=180,100,25
units.color.flip.Germans=true
units.color.ignore=factory,fighter

Result

[redrum]

And for those technically inclined here is the PR: https://github.com/triplea-game/triplea/pull/5192

[redrum]

So I have a properties proposal that I'm hoping to get some input on. While the main use case of this feature is to specify a color and the engine apply the hue and saturation from it to colorize unit images, I'm also allowing users to specify changing the brightness as well. This could be done with a separate brightness property or could be done by allowing users to specify HSB values instead of color code. Here are 2 equivalent examples of changing the Russian units to a light blue and brightening (+25) them:

Option #1

units.color.hsb.Russians=180,100,25

Option #2

units.color.Russians=00BBBB
units.color.brightness.Russians=25

Examples of Adjusting Brightness

No Change (0)

Increase (+25)

Decrease (-25)

[Cernel]

@redrum Sorry for leaving your proposal aside, but I still surely suggest not offering the brightness option. That is something that should be fixed on the image itself only, if wanted. Fixing, or anyways changing, it on the program's display instead of on the source would really make little sense (in my mind), and if a mapmaker can manage to do it via TripleA, it should be smart enough to do it via an image editor, and vice versa. This option is also going to be confusing, as, in the moment you see in a map a unit with a brightness level you don't like, you'll have also to wonder if that comes from the image itself or from the settings.

On top of that, I see that you have added this element: "It also ignores any pixels that are close to black (brightness < 10%) as especially if increasing brightness these get faded and make images look less sharp.".

That feels really patchy and definitely arbitrary, and also inconsistent, in the moment the opposite doesn't happen if you lower the brightness (I know that doesn't really matter). Rather, if you really want to avoid that phenomenon on a consistent basis, I suggest you have the contrast increasing of the same amount for any absolute variations of brightness. Meaning that if you increase the brightness by 25, then the contrast gets increased by 25 too (on the same scale). On the other hand, if you decrease the brightness by 25, the contrast would get increased (not decreased) by 25.

With this said, now that, at least with that patch you are adding, I start understanding what you are getting at (I see you don't really want to make the objects generally brighter, like if they are glowing), I guess I have the right answer for that, if you can do it. This answer is the "gamma": just use the "gamma", instead of the "brightness" (and, of course, getting rid of that 10% always black thing, as well), in what you are doing, and you'll probably see results very much in line with what I guess you want.

If you are not sure about what the gamma is, you can open an image with GIMP and follow these instructions, for testing:
https://docs.gimp.org/2.10/de/gimp-tool-levels.html
(the gamma is the upper middle slider, when you have the channel on "value", after opening Colours/Levels)

Also, regarding the brightness or whatever, please make clear if we are dealing with a percentage or a 0-255 scale. Maybe you have said it somewhere I overlooked, but point is everything must be very clear to the maker (just saying it eventually when this will be documented in pos2; haven't checked if it already is).

I, of course, agree applying only hue and saturation for colourizing via colour code, but that doesn't seem right as a process, as you are inputting something having a number of information implied, and using only some of those information. This means that there are a (big) number of such values giving the exact same result, in term of hue and saturation. However, since the ownerships colours are defined that way, I see a reason for it, but I would rather have a boolean option for simply setting the units at the hue and saturation defined for the ownership colour of the same player.

Also, anyways, if you are not going to remove that option too (as I suggest), can you please confirm me that inputting a color code value will give exactly the same result as setting the HSB with hue and saturation only at the values implied by that colour code, right?

Also, in any cases, can you please clarify whether the results of these options are going to work alike to complete colourization or alike to Hue-Saturation changes (in GIMP term, are we doing Colours/Colourize or Colours/Hue-Saturation (for example, the first one would colourize a factory, the second one wouldn't (as I said, I suggest the second one)))? Practically, are these options going to add saturation (colour) to an image like the factory or not?

[Hepps]

@redrum I'm inclined to say option 1

[ff03k64]

I vote for option 0. I don't now anything so whatever you do is fine with me!

[Cernel]

@redrum If option 1 gets rid of that thing of using the colour code to specify hue and saturation only, then I prefer that one. Can the matter be detailed? I assume that all the pixels of the image will be set at the defined hue. What will happen, instead, for each pixel with the saturation and the brightness (I assume the brightness just changes the value), relatively to their starting values? Maybe it should be rather called "HSV", instead?

[LaFayette]

I'd advocate for option 1.

Looking at an existing maps.properties files, there are already RGB codes:

#Color settings for the map
#values must be a 6 digit hex number
color.British=8B4513
color.Americans=488214
color.Russians=36648B
color.French=0000EE
color.Austrians=FFB00F
color.Ottomans=CD0000
color.Germans=999999
color.Italians=006400
color.Neutral=dd5500
color.Impassable=D2B48C

#default unit scale
#value must be one of the menu options
units.scale=0.8333

#does the map have relief images
map.hasRelief=true

Keeping RGB for unit colors would stay consistent.

Second, I find it hard to work with HS unless you're using a color picker. For example, a HS of 180,30 or HS of 240,100, I could not tell you what those colors are.

Third, IMO RGB is intrinsically simpler. HSB is comma delimited vs a value that can be parsed directly in java compared to being split. The range of values of HSB depend on the position, while RGB is consistent hex codes, each 0-F, while HSB is 0-360 or 0-100.

I personally think humans deal better with RGB. Notably it's the de-facto standard on the web. HSB OTOH is really good for image editting, I've used it there. Having the control to only change saturation or brightness is powerful as you can make colors more 'intense' by adjusting a single slider rather than increasing RGB values while maintaining a specific ratio

[redrum]

@LaFayette I think you meant option #2

[Cernel]

@LaFayette said in Dyeing/Colorizing Unit Images:

I'd advocate for option 1.

RGB is option 2 (except that it is just taking hue and saturation out of RGB info).

[prastle]

@redrum Anything that allows tweaking for my colour blindness I am willing to learn

[Panther]

@redrum I vote for the RGB option.

[redrum]

I've decided to move forward with Option #2, thanks for everyone's feedback. I think this is easier for players to use since they already need to understand color codes when changing territory ownership colors.

[Cernel]

@redrum So, how does the saturation work?
If you define a RGB value, that value has a specific saturation value implied.
Are all pixels in the units images, then, set to that same saturation value (like I assume it happens for the hue)? If not, how does it work?

I think that, at this point, the most important item would be having a way of changing the hue without effecting the saturation, of the images (meaning each pixel in them keeps its original saturation value, only the hue changing).

[LaFayette]

@Cernel I'd note that the HSB version would specify 'saturation' as well and would not be just a hue shift. Having both brightness and saturation be additional parameters would be nice, in this way a person could have a hue-only shift if desired and/or increase saturation explicitly. I think though we're getting to an over-engineering level. Adjusting unit color will still need manual work to make sure that it looks good, a hue only shift may not guarantee that the results will always look good. I don't think offhand it's that easy for the code to adjust 'hue' only.

[redrum]

Properties Description

# Unit color settings (apply effects similar to colorize functions of image editing tools)
#units.color.<player> applies the given color's hue and saturation to the player's units
#units.color.Russians=00BBBB
#units.color.brightness.<player> allows the brightness (-100 to 100) to be adjusted when above unit color is set 
#units.color.brightness.Russians=25
#units.color.flip.<player> flips the player's units horizontally
#units.color.flip.Russians=true
#units.color.ignore provides a comma delimited list of units that aren't impacted by the above units.color properties
#units.color.ignore=factory,fighter

POS2 PR: https://github.com/triplea-maps/the_pact_of_steel/pull/33

[Cernel]

@redrum Strange that you have to set the other thing to be able to use the brightness option.

Even without any intentions of having anything flipping the units vertically, I believe the name should specify that the flipping is horizontal. Also probably not color. So like: units.transform.flip.horizontal.

[LaFayette]

@Cernel said in Dyeing/Colorizing Unit Images:

Even without any intentions of having anything flipping the units vertically, I believe the name should specify that the flipping is horizontal. Also probably not color. So like: units.transform.flip.horizontal.

I strongly agree with you Cernel on color adjustment and image rotation not necessarily being related. These properties once defined are probably going to stick around for a very long time.

I'd also agree brightness and color would also be ideally decoupled, for now it's difficult on the backend. If there is a reason to need the feature, it could be a nice enhancement to see added later.

With regards to coupling, I've also been wondering if the 'ignore' of coloring and image flipping should be decoupled. Is it always the case that any unit where we want to ignore coloring, we will also always want to ignore image flipping? In other words, should a map maker be allowed to say "flip this image, but do not color it".

The cost of enabling that is likely duplication, ie:

units.color.ignore=factory,fighter
units.color.flip.ignore=factory,fighter

But the above would allow for something like the following where, for example, 'fighters' are colored but not rotated:

units.color.ignore=factory
units.color.flip.ignore=factory,fighter

For property names, I'd recommend keeping them singular and prefixing with "unit.image", as a suggestion:

unit.image.color.<Player>=FF00FF
unit.image.brightness.<Player>=100
unit.image.rotation.flip.horizontal={true|false}

Or:

unit.image.color.<Player>=FF00FF
unit.image.brightness.<Player>=100
unit.image.rotation.flip={horizontal|none}

[Cernel]

@LaFayette Ah, right. It's important that the ignore thing will not effect the flipping; the two matters are really not related, and I can see you should not be normally wanting of not flipping the units you don't want to colourize. That's probably an even bigger reason than my purely self-consistent considerations.

[Cernel]

@LaFayette said in Dyeing/Colorizing Unit Images:

With regards to coupling, I've also been wondering if the 'ignore' of coloring and image flipping should be decoupled. Is it always the case that any unit where we want to ignore coloring, we will also always want to ignore image flipping? In other words, should a map maker be allowed to say "flip this image, but do not color it".

The cost of enabling that is likely duplication, ie:

units.color.ignore=factory,fighter
units.color.flip.ignore=factory,fighter

But the above would allow for something like the following where, for example, 'fighters' are colored but not rotated:

units.color.ignore=factory
units.color.flip.ignore=factory,fighter

I believe that ignoring units for colourization should not effect flipping.
I would not have an option for ignoring units for flipping.