Documentation → Étape 3

Étape 3 — Le modèle de colorisation

Comment une couleur hexadécimale devient un vêtement ombré. Vingt couleurs testées, une fausse piste, et une bande de 8 pixels cachée dans un coin.

La question

Un même layer doit pouvoir prendre n'importe quelle teinte tout en conservant son ombrage. Deux opérateurs classiques se présentent :

• L'addition — écartée d'emblée : sur une base claire elle sature immédiatement (255 + n = 255) et détruit le modelé.
• La multiplication (sortie = base × couleur / 255) — elle préserve exactement les rapports de luminance, et c'est l'opérateur qu'on attend.

Il a donc fallu la tester. Elle ne correspond pas.

1. La multiplication ne rend pas compte des mesures

Si le moteur multipliait, alors un rendu à $ffffff donnerait le gabarit brut, et tout autre rendu s'en déduirait. Test sur top/basic :

Des écarts de cette ampleur ne sont pas des arrondis. Le modèle est faux — mais l'échec est instructif : les valeurs mesurées sont trop claires par rapport à la prédiction, ce qui suggère que le gabarit n'est pas « du blanc ombré ».

2. L'ombrage tient en niveaux discrets

En listant la palette exacte des pixels non transparents plutôt qu'en comparant des images entières, la structure saute aux yeux. Un t-shirt rendu à $808080 ne contient que cinq valeurs de gris couvrant une surface réelle :

Le même layer, cinq teintes, ombrage préservé à l'identique :

3. L'anomalie du bleu, et sa résolution

Un balayage sur 20 couleurs a fait apparaître une incohérence apparemment fatale au modèle. À luminosité et saturation identiques, le rouge et le bleu ne donnaient pas les mêmes rapports :

Rouge et vert s'accordent parfaitement ; le bleu diverge. Une dépendance à la teinte aurait invalidé l'hypothèse d'un simple facteur scalaire, et orienté vers un espace perceptuel (HSL, luminance pondérée…).

En restant sous 190 pour chaque canal, les rapports redeviennent identiques quelle que soit la teinte. D'où la règle de capture : ne jamais mesurer à $ffffff. Le blanc est le pire choix possible — il écrase deux slots l'un sur l'autre.

4. La bande de calibration cachée

En classant les pixels par zone, 8 pixels se comportaient bizarrement : présents dans tous les layers, réagissant à la couleur secondaire même quand le cosmétique déclare uses_secondary_color: false, et occupant un slot chacun.

Leurs coordonnées :

C'est aussi la confirmation la plus directe de l'hypothèse « pixels marqueurs » de départ : le système encode bien de l'information de colorisation dans des pixels dédiés. Simplement, ces marqueurs ne servent pas à délimiter les zones — ils documentent la rampe.

5. Les 8 ratios, mesurés

Ajustement par moindres carrés sur 10 niveaux de gris en entrée (40 à 184), pour éviter aussi bien l'écrêtage haut que la perte de précision en bas :

Un écart maximal de 1 sur 255, sur 10 points de mesure : le modèle multiplicatif à facteur scalaire est le bon, une fois l'écrêtage pris en compte.

Exprimée sur une base 255, la rampe présente une structure nette :

210   223   237   255   290   308   326   344
   +13   +14   +18   +35   +18   +18   +18

Côté clair, des pas rigoureusement constants de +18. Côté sombre, des pas resserrés (+14, +13) — un ombrage volontairement plus doux dans les ombres que dans les hautes lumières. Et un saut double (+35) juste au-dessus du niveau de base, qui laisse penser qu'un neuvième niveau existe dans l'outillage de l'auteur sans être utilisé dans les textures publiées.

6. La formule complète

si le pixel est fixe        → recopier tel quel
sinon                       → couleur = (zone == primaire) ? C_prim : C_sec
                              sortie  = clamp(round(couleur × ratio[slot]), 0, 255)
l'alpha est toujours conservé sans modification

Le gabarit archivé pour chaque layer se réduit donc à trois informations par pixel : alpha, zone (primaire / secondaire / fixe) et index de slot parmi 8. Soit un octet par pixel là où le PNG rendu en consomme quatre — et surtout, une représentation qui redonne le layer générique que l'API n'expose pas.

Bilan