Dyeing/Colorizing Unit Images

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

[redrum]

I've renamed the properties to use "units.transform" instead of "units.color" prefix:

units.transform.color.Germans=FF0000
units.transform.flip.Germans=true
units.transform.color.Russians=00BBBB
units.transform.brightness.Russians=25
units.transform.color.British=00FF00
units.transform.ignore=factory,fighter

@Cernel The ignore needs to apply to flip as well as generally the units you ignore will either be things like factory which appear exactly the same for all nations (not flipped like the rest) or will be damaged BB or AA radar which you'll already manually colorize/flip if you want them to be ignored (wouldn't want to flip them back). I don't think there is really a use in TripleA to be flipping images and not coloring them which is why they share a single ignore unit list. Remember this isn't meant to be an image editing program just give users and map makers the common functions that they would need if creating a shared unit set.

[Cernel]

@redrum Personally, if I would make an Axis vs Allies game, with Axis all facing a side and Allies all facing another side, and I would have something like a capturable emplacement or bunker (a combat infrastructure), I would have that unit too being one the flipped version of the other alliance, like all other units, while, as long as they don't move and always belong to the territory owner, I would leave them generically colourized the same way for everyone. For consistency, I would go the same way with factories, even if they would be non combat infrastructures, but I see that currently in assets the factories are all always the same, no matter where the other units appear to be facing. However, I believe having no colourization is not related to being a non combat units (as if you have mobile factories that can go in allied territories, you need to tell them apart), but to always belonging to the territory owner where the units is, which means being an infrastructure, and currently infrastructures can be combat units too, while this was not the case when Classic and Revised were made.

[Cernel]

@redrum said in Dyeing/Colorizing Unit Images:

@Cernel The ignore needs to apply to flip as well as generally the units you ignore will either be things like factory which appear exactly the same for all nations (not flipped like the rest) or will be damaged BB or AA radar which you'll already manually colorize/flip if you want them to be ignored (wouldn't want to flip them back).

I really would go the same way with such things. If I'm colourizing a unit, I would colourize the same way also his damaged or tech versions (that is why I would not colourize units that have any sub-versions of the same being not monocolour, even if the basic unit is). Besides, elements that are beyond this scheme should rather really be icons that the program overlays.

On this matter, it should be decided if calling "battleship" will call "battleship_hit" and "battleship_r" too, as well as if calling "aaGun" will call "aaGun_r", "rockets" and "rockets_r" too, as well as if calling "fighter" will call "fighter_lr" and "fighter_jp" and "fighter_lr_jp" too etc.. I think all those cases if you are calling the basic unit, all the related damaged or tech variants should be called too. So, for example, if I exclude "bomber", then "bomber_lr", "bomber_hb" and "bomber_lr_hb" should be excluded the same way, as well.

[redrum]

@Cernel Well looking at just about every existing map... it appears no one else agrees with flipping factories and similar units. I think the part you are missing is that the units that generally aren't colored/flipped are 0 movement capturable units which generally represent some sort of building/fortification/etc that it makes more sense for them to never "move" or change orientation as they are just being captured.

Even look at TWW (probably the best map from a graphical standpoint) which has a bunch of these types of units (barracks, factory, rails, airbases, etc) and you'll see they all are uncolored and face the same direction for all nations.

[Cernel]

@redrum Maybe I'm used to 270BC that when you capture a city it immediately becomes a completely different city.:grinning_squinting_face:

[Cernel]

@redrum Quick question: currently, if "factory" is excluded, are "factory_hit", "factory_it" and "factory_it_hit" excluded too?