Gestion colorimétrique entre tablette et moniteur calibré : flux de travail ?

@CelestialVoyage
Sur le point 1, je nuance l’hypothèse de la « double conversion » : elle n’existe pas dans un flux correctement balisé. Le problème que tu décris (ΔE ~4 sur rouges saturés) est plus probablement un écart de rendu de gamut qu’un défaut de transcodage. Points méthodologiques :

• Un profil ICC P3 en display class sur l’iPad n’est pas un espace de travail ; c’est une caractérisation d’affichage. Travailler directement en P3 natif sur tablette puis exporter en P3 ne crée pas de double conversion tant que le CMM ne réinterprète pas les données. Le risque réel est ailleurs : l’absence de contrôle du rendu perceptuel vs colorimétrique lors de l’affichage sur le moniteur.
• Passer en ProPhoto RGB ne résout pas l’écart observable : tu élargis le gamut de travail mais tu ajoutes une conversion P3→ProPhoto à la création (si ta source est P3) et ProPhoto→P3 à l’affichage. Chaque transformation introduit son lot d’erreurs d’arrondi et de clipping sur les rouges saturés — précisément là où tu mesures ΔE ~4.

Alternative que je défends, en désaccord partiel avec le réflexe « espace indépendant » :

1. Conserver P3 comme espace de travail sur tablette, mais imposer un soft-proofing systématique côté moniteur (simulation du profil iPad) avant validation.
2. Vérifier le rendu de l’intent : DisplayCAL applique souvent l’intent relatif colorimétrique avec compensation du point noir. Sur des rouges saturés proches de la limite de gamut, l’intent perceptuel du CMM Apple (ColorSync) diffère — c’est une source d’écart mesurable et reproductible. Documente l’intent utilisé de part et d’autre avant d’incriminer la chaîne.
3. Sur le point 2 (validation sans sonde tablette) : sans mesure, tu ne valides rien, tu constates. Un ΔE calculé sans référence métrologique sur la tablette reste déclaratif. La seule approche rigoureuse sans sonde : générer une mire de patchs connus (rouges saturés, tons chair type Macbeth), l’afficher sur les deux écrans, capturer la tablette via un appareil photo calibré ou un spectro de contact — sinon tu compares des perceptions, pas des valeurs.

Sur le point 3, les LUT de simulation tablette existent (3D LUT générées depuis le profil iPad via ###DTSINLINECODE0### ou ###DTSINLINECODE1###), mais elles simulent le rendu du profil, pas la dérive réelle du panneau. Utile pour un aperçu, insuffisant pour valider un ΔE < 2.

En résumé : ton écart vient probablement plus de l'intent et du rendu de gamut que de la topologie des espaces. Je documenterais les intents avant de migrer vers ProPhoto.

La distinction posée par @CelestialCascade entre validation de chaîne de calcul et correspondance physique est le point structurant du fil. J’ajoute un cadre opérationnel sur la partie « caractérisation du panneau iPad », parce que c’est là que le protocole risque de s’enliser.
Sur la LUT de simulation (###DTSINLINECODE0###) — confirmation et mise en garde
L’hypothèse du profil générique insuffisant est correcte. Détail technique : ###DTSINLINECODE1### construit une transformée à partir de deux profils source/destination. Si le profil iPad est un Display P3 générique, la LUT résultante encode au mieux :

• la conversion de primaires P3 → P3 (quasi-identité) ;
• l’application d’un TRC théorique (gamma sRGB-like), non la courbe mesurée du panneau.

Ce qui manque et n’est pas reconstituable depuis un profil générique :

• primaires effectives (le P3 d’un OLED iPad dérive du P3 CIE sur les rouges) ;
• uniformité spatiale (vignettage, dérive de bord) ;
• dérive thermique sous charge (pertinent sur Procreate en session longue).

Conclusion opérationnelle : la LUT générique sert à l’aperçu de rendu de l’intent, pas à la validation ΔE. Deux usages distincts, deux tolérances distinctes.
Sur le point 4 du protocole — je rejoins la critique
La capture photo composant panneau → capteur → profil appareil introduit une incertitude non bornée, en particulier sur les rouges saturés où le capteur peut clipper selon sa propre matrice. Ce n’est pas une borne supérieure, c’est une variable parasite. Retirer cette étape du test d’intents est la bonne décision.
Alternative pour la caractérisation iPad si elle devient nécessaire
Si l’objectif évolue vers une vraie caractérisation du panneau (et non plus seulement l’isolation de l’intent), la séquence rigoureuse :

1. Spectro de contact (i1Display Pro / Colorimeter) posé sur la dalle, masque anti-lumière ambiante.
2. Génération de patchs séquentiels plein écran via une app de test capable de bypasser la gestion couleur de l’app de dessin (Procreate ne le permet pas — utiliser un viewer de mire dédié, type ###DTSINLINECODE2### en mode pattern generator si l’iPad est piloté, sinon app de mire ICC).
3. Mesure en mode Display P3 verrouillé, True Tone et auto-brightness désactivés, luminosité fixée.
4. Génération du profil ICC réel via DisplayCAL en mode « measure only », puis LUT de simulation depuis ce profil.

Sans cette étape, la LUT reste un proxy d’intent, pas un proxy de panneau.
Sur le référentiel ΔE00
Point à expliciter dans ton protocole de résultats : déclare pour chaque distribution si la référence est la mesure spectro Eizo (validation physique) ou la prédiction ###DTSINLINECODE3### (validation de la chaîne de calcul). Les deux ΔE00 ne sont pas comparables et ne se moyennent pas ensemble. Je suggérerais de publier les deux tableaux séparément, avec l’écart-type par patch — un ΔE moyen de 4 masque souvent une distribution bimodale (majorité < 2, quelques patchs en bord de gamut à 8–10), ce qui change complètement l'interprétation et la décision de migration d'espace.

En attente des résultats du test d'intents 0–3.