Dyeing/Colorizing Unit Images


  • Admin

    @LaFayette I think you meant option #2 🙂


  • Moderators

    @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).


  • Donators Moderators Admin

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


  • Moderators Admin

    @redrum I vote for the RGB option.


  • Admin

    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.


  • Moderators

    @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).


  • Admin

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


  • Admin

    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


  • Moderators

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


  • Admin

    @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}
    

  • Moderators

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


  • Moderators

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


  • Admin

    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.


  • Moderators

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


  • Moderators

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


  • Admin

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


  • Moderators

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


  • Moderators

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


  • Moderators

    @redrum said in Dyeing/Colorizing Unit Images:

    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.

    In GIMP "transform" means those things like rotating etc., not changing colours, but of course this is just a nomenclature. For coherency with "flip", I suppose the other one should be called "colorize" instead of "color", but, then, it would be not coherent with "brightness", instead (tho this is the same in GIMP too). Maybe it should be rather called "hs", or something hinting that it is changing only the hue and saturation, not sure.


  • Admin

    @Cernel Yes, currently it checks the actual unit name against the ignore list not the specific image. So will ignore transforming for all the unit's various images (_hit, _lr, _it, etc). I figured that probably makes more sense but I'm open if folks feel they would want ignore to list each specific image for a unit.

    Well, "color" fits better with "brightness" and "color" is used in other areas of the map.properties. "flip" is probably the one that's a bit questionable but I think that was the most straightforward name I could think of.


Log in to reply
 

26405
1387
1627
Visitors Today