Goal

To define the metadata required for re-coloring assets in the HitHub App. Maybe to actually implement a color shift in assets via Pillow.

Notes

Last time I was able to get assets loaded into and accessed within the HitHub App. Also I found out that madmax was able to get a dev server up and running! Nice!

I ended up coming up with the following default for a new JSON field called color_data. Instead of explicitly defining the R, G, B, and A channels as their own integer fields, I figured it would make more sense to just use an object with easily accessible values that could be accessed and changed easily. The default for this color_data value is the following:

color_data_default = {
        "auto_find_colors": True,
        "primary_color": [0, 0, 0, 0],
        "secondary_color": [0, 0, 0, 0],
        "secondary_color_rel": [0, 0, 0, 0],
        "tertiary_colors": {
            #"color_1": [0, 0, 0, 0], # Default to None, but colors can be added in this form
            #"color_1_rel": [0, 0, 0, 0],
        },
        "constant_colors": {
            #"white": [255, 255, 255, 1], # Default to None, but colors can be added in this form
            #"black": [0, 0, 0, 1],
        },
        "independent_color_shift": {
            #"detail_1": [0, 0, 0, 0] # Default to None, but colors can be added in this form
        },
        "is_color_shifted": False,
        "shifted_primary_color": [0, 0, 0, 0],
    }

With the following intended use cases:

• auto_find_colors
  • I have a function that can automatically determine the primary color of an asset by simply considering the pixel counts of each color then using the most frequent color as the primary color. . I'm thinking I can default to allowing that to determine the primary color if the user doesn't explicitly mention it. Otherwise it will be turned off and the artist can decide what they want to use as the primary color.
• primary_color
  • The main color of the object. All other colors will be shifted around this color. This color (like all other colors) will follow the format of [R, G,
• secondary_color
  • The secondary color of the object. Typically used for the first layer of shading / first layer of detail
• tertiary_colors
  • Any number of other colors, typically used for fine details / minor emphases. Intended to be stored as another collection of colors via a dictionary
• _rel suffix
  • The color's [R, G, B, A] value relative to the primary color. For instance, if the primary_color was [225, 235, 245, 1] and the secondary_color was [255, 255, 255, 1], the secondary_color_rel would be [30, 20, 10, 1].
• constant_colors
  • Colors that remain constant no matter how the color is shifted
• independent_color_shift
  • Colors that are eligible for their own independent random color assignment regardless of the overall color shift of the primary, secondary, and tertiary colors
• is_color_shifted
  • Whether or not the primary color has been shifted (can be found by checking whether any RGB values in shifted_primary_color are non-zero)
• shifted_primary_color
  • The new primary color of the asset

This should give both the artist and myself a good amount of flexibility as to how we shift the colors both in code and when designing the art. I decided to keep things like tertiary_colors, constant_colors, and independent_color_shift as empty dictionaries and left examples of how they might be populated in comments in the fighters/models.py code. The tertiary_colors should be found programmatically anyways if the user leaves the default of auto_determine_primary_color.

I decided to work on building out the auto_find_colors function first, because that one will be the most useful to this project. This would be best placed in a fighters/signals.py file. That way, when a cosmetic is saved we can calculate its primary, secondary, and tertiary colors.

I'll keep any color shifting functions in the fighters/utils.py file because I think it might be useful to have any auxiliary functions kept there. At the end of the day we can move the location of them if required.

The last thing I did today was wrote a function in fighters/utils.py that was able to read in the cosmetic's image field and let Pillow determine its color frequency. I'll need to think about whether I should color correct different assets, but for now I know how to access the image object and manipulate it with python. This is a great start!

Results

• Designed new cosmetic metadata
• Added the fighters/signals.py file to execute commands on Cosmetic save
• Added in fighters/utils.py functions to read and manipulate different functions

Next Time

• Automatically read in and set color_data values via the fighters/utils.py's determine_cosmetic_colors function
• Add a validator to make sure that uploaded cosmetics are 112 x 112