Établir une référence couleur et HiDPI sur un Mac distant

Après une connexion à un Mac dans le cloud, le gris d’une maquette peut tirer vers le bleu et les contours du texte dans le simulateur paraître plus flous qu’en local. Il ne faut alors ni modifier les valeurs de couleur ni remplacer les images. L’affichage d’un bureau distant est le résultat final d’une chaîne dans laquelle « le rendu de l’application est transmis, puis affiché sur l’écran local ». Chaque étape peut introduire une mise à l’échelle, une compression ou une conversion colorimétrique. La bonne méthode consiste à conserver d’abord les fichiers originaux générés dans le cloud, puis à isoler chaque niveau pour localiser l’écart.

Séparer d’abord les trois niveaux de variables

Toute validation visuelle à distance comprend au moins trois niveaux :

1. Les pixels réellement générés par le Mac dans le cloud, notamment ceux des fenêtres d’application, des captures du simulateur et des fichiers exportés.
2. La mise à l’échelle, la conversion de profondeur de couleur et la compression appliquées à l’image par la connexion distante.
3. La mise à l’échelle de l’affichage local, le profil colorimétrique de l’appareil et les dimensions de la fenêtre du client.

Si l’on capture uniquement l’écran distant, les deuxième et troisième niveaux se retrouvent mélangés dans la même preuve. Il devient alors impossible de déterminer l’origine du problème. Pour chaque validation, il est recommandé de créer un répertoire distinct contenant les informations système, les captures originales du cloud et les observations effectuées en local.

mkdir -p "$HOME/visual-baseline"/{system,source,notes}
system_profiler SPDisplaysDataType \
  > "$HOME/visual-baseline/system/displays.txt"
system_profiler SPColorSyncDataType \
  > "$HOME/visual-baseline/system/colorsync.txt"
sw_vers > "$HOME/visual-baseline/system/macos.txt"

Ces fichiers ne servent pas à comparer les performances. Ils permettent de répondre à trois questions essentielles : quelle version du système était utilisée, quelle était la définition de sortie du bureau et quels profils colorimétriques étaient reconnus par le système.

Le bureau distant convient aux opérations courantes et aux vérifications rapides, mais l’appréciation visuelle de l’image transmise ne peut pas remplacer les fichiers originaux générés dans le cloud.

Fixer la relation entre définition et mise à l’échelle

Le flou provient le plus souvent non pas d’une définition insuffisante des ressources, mais d’un rapport non entier entre les dimensions logiques, les pixels physiques et la fenêtre du client. Commencez par sélectionner un réglage fixe dans les paramètres d’affichage, notez les dimensions logiques indiquées comme espace d’affichage apparent, puis vérifiez le nombre réel de pixels de sortie dans le rapport système. Évitez de changer fréquemment de définition pendant la validation.

Côté client, privilégiez un affichage à l’échelle 1:1. Si l’image ne tient pas dans la fenêtre, une mise à l’échelle temporaire peut faciliter les opérations, mais il faut revenir à la taille d’origine avant de produire une capture de référence. Lorsque le client propose à la fois les options « Adapter à la fenêtre » et « Étirer pour remplir », il faut les distinguer : la première conserve généralement les proportions, tandis que la seconde peut déformer les cercles, les polices et la grille de pixels.

Préparer un écran de test réutilisable

L’écran de référence doit réunir du texte en petite taille, des lignes d’un pixel, des angles arrondis, des ombres transparentes, une échelle de gris et des dégradés continus. Une page d’accueil aux couleurs vives ne suffit pas : les grandes zones fortement contrastées révèlent difficilement les erreurs de mise à l’échelle. Le contenu et les dimensions de la fenêtre de test doivent rester fixes, et la révision ayant servi à les générer doit être consignée.

Pour valider une interface iOS, exportez de préférence une capture originale directement depuis le simulateur en cours d’exécution :

mkdir -p "$HOME/visual-baseline/source"
xcrun simctl io booted screenshot \
  "$HOME/visual-baseline/source/simulator.png"
sips -g pixelWidth -g pixelHeight -g profile \
  "$HOME/visual-baseline/source/simulator.png"
shasum -a 256 "$HOME/visual-baseline/source/simulator.png"

Le hachage permet de vérifier que tous les membres de l’équipe disposent du même fichier. Il ne signifie pas que deux images visuellement identiques doivent nécessairement avoir le même hachage : un simple réenregistrement peut modifier les métadonnées ou l’encodage.

Déterminer le niveau du problème à partir de la capture originale

Commencez par télécharger en local le fichier simulator.png généré dans le cloud, sans passer par l’aperçu d’une messagerie ni par un réencodage. Ouvrez-le dans un outil capable d’afficher les pixels à l’échelle 1:1, puis examinez les contours du texte, les traits fins et les dégradés.

Si le fichier original est net alors que le bureau distant est flou, l’application n’a pas besoin d’être modifiée : le problème se situe au niveau de la transmission ou de la mise à l’échelle du client. Si le fichier original est lui aussi flou, vérifiez le facteur d’échelle des ressources graphiques, le positionnement éventuel de la mise en page sur des fractions de pixel, le mode de rastérisation du texte et l’appareil ciblé par la capture. Si les couleurs ne semblent incorrectes que sur un écran local particulier, comparez le profil colorimétrique du fichier aux réglages de cet écran au lieu de modifier directement les couleurs de la maquette.

Les éléments peuvent être archivés dans l’ordre suivant :

01-source.png        Image originale générée directement par l’outil dans le cloud
02-remote-view.png   Image affichée par le client distant
03-local-view.txt    Écran local, mise à l’échelle et réglages du client
04-system.txt        Environnement d’affichage et de couleur du Mac dans le cloud

Lors des comparaisons, ne modifiez qu’une seule variable à la fois. Par exemple, conservez la même définition dans le cloud et changez uniquement la mise à l’échelle du client. Après avoir vérifié le résultat, testez une autre profondeur de couleur ou un autre niveau de compression. La modification simultanée de plusieurs réglages empêche de reproduire les conclusions.

Corriger un décalage colorimétrique sans altérer la référence système

Pour analyser un problème de couleur, vérifiez d’abord si le fichier contient des informations de profil. La commande sips -g profile permet d’identifier rapidement le profil associé à une image, mais elle ne prouve pas que l’ensemble de la chaîne de transmission est correct. Si l’outil d’exportation permet de choisir l’espace colorimétrique de sortie, fixez ce choix dans les règles du projet et appliquez la même convention aux tâches automatisées comme aux exportations manuelles.

Ne remplacez pas arbitrairement le profil d’affichage par défaut du système dans le cloud dans le seul but de rendre l’aperçu distant « plus proche de l’affichage local ». L’image pourrait sembler correcte sur un client tout en affectant les captures d’écran, les exportations vidéo ou la session d’un autre membre de l’équipe. Il est plus fiable de maintenir une référence stable dans le cloud, de consigner le mode d’affichage du client local et de fonder la décision finale sur les fichiers originaux.

Les ombres semi-transparentes et les dégradés sombres peuvent également subir un effet de bandes dû à la compression distante. Agrandissez l’image originale pour le vérifier : si le dégradé y est régulier, mais présente des ruptures sur l’écran distant, il n’est pas nécessaire de modifier le dégradé dans l’application. Ce n’est que si les bandes sont déjà visibles dans l’original qu’il faut examiner la profondeur de couleur des ressources, les paramètres d’exportation ou la chaîne de rendu.

Intégrer la validation à la liste de contrôle de transfert

L’équipe doit associer la référence visuelle à une version du code au lieu de dépendre de la mémoire d’une personne pour les réglages du client. Après chaque changement de version du système, de client distant, de définition d’affichage ou d’appareil ciblé par les captures, générez un nouveau jeu de fichiers de référence.

Avant tout transfert, vérifiez au minimum les points suivants :

• La version du système dans le cloud et le rapport d’affichage ont été enregistrés.
• Le bureau distant utilise une définition fixe et le client n’applique aucun étirement non proportionnel.
• Le simulateur ou l’application a généré directement une capture originale.
• Les dimensions en pixels, le profil colorimétrique et le hachage de l’image originale ont été consignés.
• Le rendu original, l’image transmise et l’affichage local ont été vérifiés séparément avant de conclure à un flou ou à un décalage de couleur.
• Le rapport de défaut comprend la révision, l’appareil cible, les réglages du client et les étapes minimales de reproduction.
• Tous les fichiers de test temporaires ont été retirés du répertoire des livrables afin d’éviter leur intégration à l’archive définitive.

Lorsque cette procédure est appliquée sur un Mac distant de VMOak, il faut également séparer la qualité de la connexion de la validation des livrables : la première concerne la fluidité des opérations, tandis que la seconde vérifie que les fichiers générés dans le cloud respectent les spécifications. Tant que l’analyse commence systématiquement par les fichiers originaux, la compression distante, la mise à l’échelle HiDPI et les véritables défauts de rendu ne seront pas confondus en un seul problème.

Questions fréquentes