Note de l’auteur : un lecteur qui vend des articles pour la maison en ligne utilise Nano Banana pour modifier par lots des images de coussins de fenêtre en saillie, déclinés en plusieurs couleurs : vert, rouge, bleu, gris, blanc cassé et kaki. Il obtient plus de vingt images finales par dossier. Ses propres mots : « La dominante rouge est loin d’être rare, c’est même très courant. Toute l’image tire vers le rouge et je dois corriger chaque image à la main. » Il utilise le plus souvent Nano Banana 2, car c’est le modèle sélectionné par défaut dans son outil. Il n’avait jamais prêté attention au modèle ni au canal.
C’est un cas typique de dominante rouge lors de la retouche d’images avec Nano Banana : l’invite ne demande pas de tons chauds, mais l’image finale tire globalement vers le rouge et les couleurs chaudes. Il ne suffit pas de « changer de modèle » pour régler le problème : la dominante peut venir de l’image de référence, de l’invite, de la résolution, du canal ou de la compression du fichier final. Il faut donc examiner chaque piste dans l’ordre.
Ce que vous allez apprendre : à la fin de cet article, vous saurez à quelle étape apparaît la dominante rouge, par quoi commencer et combien coûte approximativement une série de tests comparatifs. Les faits présentés reposent sur trois sources : la documentation officielle de Google (consultée le 30 octobre 2026), les tests d’utilisateurs publiés sur le forum officiel de Google (et non des conclusions officielles), ainsi que la documentation et les informations de la plateforme APIYI (vérifiées le 30 octobre 2026).
Nano Banana : 5 points à vérifier quand une image retouchée vire au rouge
Voici d’abord un tableau récapitulatif. Les 5 points sont classés du moins coûteux et du plus facile à vérifier au plus complexe. Mieux vaut les examiner dans cet ordre plutôt que de changer immédiatement de modèle.
| Point à vérifier | Pourquoi l’image peut virer au rouge | Vérification en 30 secondes | Solution à privilégier |
|---|---|---|---|
| Image de référence | L’espace colorimétrique Display P3 n’est pas reconnu, l’URL n’a pas réellement été transmise ou la retouche repart du résultat précédent | Vérifier le profil ICC et la présence d’IMAGE dans promptTokensDetails |
Convertir en sRGB, passer en base64 et repartir de l’image d’origine à chaque retouche |
| Termes d’éclairage dans l’invite | Les mots évoquant une lumière chaude, le crépuscule ou une ambiance peuvent déclencher un ajustement global des couleurs | Relancer une fois sans les termes d’éclairage | Reformuler avec une description positive et une balance des blancs neutre |
| Modèle et résolution | Certains utilisateurs signalent une dominante visible en 2K/4K, mais presque imperceptible en 1K | Relancer en 1K avec la même image et la même invite | Comparer les résolutions, puis tester les modèles 2.1, 2 et Pro |
| Canal d’invocation | Le nom affiché dans l’outil peut ne pas correspondre au modèle ou au groupe réellement utilisé | Vérifier le groupe du jeton, les journaux d’invocation et la taille du fichier image | Changer de groupe pour effectuer une comparaison A/B |
| Compression de sortie | Une seconde compression peut faire perdre des détails de couleur | Vérifier les dimensions en pixels et la taille du fichier | Récupérer le fichier d’origine et ne le compresser qu’à la fin |
🎯 Conseil de diagnostic : pour les points 3 et 4, il faut comparer les résultats obtenus avec plusieurs modèles et groupes sur une même image. Sur APIYI apiyi.com, une seule clé API suffit : modifiez le paramètre
modelpour comparer les trois modèles 2.1, 2 et Pro, sans créer de comptes séparés.
Nano Banana : vérifier d’abord que la dominante rouge est bien dans le fichier
Avant de commencer, écartez un éventuel problème d’écran ou de logiciel de visualisation. Pour cela, relevez les valeurs LAB dans les zones neutres de l’image : mur blanc, rebord de fenêtre blanc ou sol gris. LAB est un espace colorimétrique conçu en fonction de la perception humaine : L représente la luminosité, a l’axe rouge-vert (plus la valeur est élevée, plus la couleur tire vers le rouge) et b* l’axe jaune-bleu (plus elle est élevée, plus la couleur tire vers le jaune). Avec la pipette de Photoshop ou tout autre outil capable de lire les valeurs LAB, prélevez un point au même endroit dans l’image d’origine et dans l’image générée.
Les seuils ci-dessous sont empiriques, pas officiels : si la médiane de a dans les zones neutres est supérieure de plus de 2 à celle de l’image d’origine, la différence est généralement visible à l’œil nu ; au-delà de 4, la dominante est nette. Si a a à peine changé mais que l’image paraît plus rouge, le problème vient probablement de l’affichage ou du profil colorimétrique. Il n’est alors pas nécessaire de passer tout de suite aux 5 vérifications ci-dessous.
Nano Banana : 5 causes à vérifier quand les images retouchées tirent vers le rouge
1. L’image de référence présente déjà un risque de dérive colorimétrique
Pourquoi les couleurs dérivent : trois problèmes sont fréquents avec les images de référence. Premièrement, les images exportées depuis des appareils Apple utilisent souvent Display P3, un espace colorimétrique à large gamut. Le fichier contient alors un profil ICC P3, qui indique aux logiciels quelle norme de couleur utiliser. Si une étape du traitement ne reconnaît pas ce profil et lit l’image comme du sRGB, les couleurs peuvent changer. Deuxièmement, l’image de référence n’a peut-être pas été transmise : selon la documentation d’APIYI, les modèles Nano Banana nécessitent une image de référence en base64 et ne prennent pas en charge le format OpenAI. Si vous placez une URL dans le champ image_url du format compatible OpenAI, le modèle ne voit pas l’image d’origine : il ne peut que « deviner » une image à partir du texte. Troisièmement, les écarts s’accumulent lorsque vous continuez à retoucher le résultat de la modification précédente.
Sur ce dernier point, un test partagé par un utilisateur sur le forum officiel de Google mérite le détour. Il s’agit d’un retour utilisateur, pas d’une conclusion de Google : après trois modifications consécutives en 4K, la valeur a* d’une zone neutre est passée de 2,02 → 3,65 → 5,81 → 7,78, soit une hausse d’environ 2,1 à 2,4 à chaque étape. Le ΔE00, un indicateur qui mesure l’écart entre deux couleurs, se situait autour de 2,9 à 3,7. Plus de 98 % des pixels neutres avaient dérivé vers le rouge.
Comment vérifier en 30 secondes :
- Dans votre logiciel de visualisation, utilisez « Afficher les informations » pour vérifier si l’image de référence contient un profil ICC Display P3.
- Dans la réponse, consultez
usageMetadata.promptTokensDetailset vérifiez la présence de tokens IMAGE. S’il n’y en a pas, l’image n’a pas été transmise au modèle. - Comparez la valeur a* d’un mur blanc dans les images produites après la première et la troisième modification. Si elle augmente à chaque étape, la dérive s’accumule.
Comment corriger le problème : convertissez systématiquement les images en sRGB avant de les envoyer ; transmettez l’image de référence en base64, sans passer par une URL ; repartez de l’image d’origine à chaque modification, plutôt que de retoucher le résultat précédent. Si vous avez réellement besoin de modifications successives, Google recommande de renvoyer la signature de pensée (« thought signature ») pour conserver le contexte de raisonnement. Sur APIYI, le point d’accès Gemini natif prend en charge les véritables modifications successives : l’image produite à l’étape précédente est renvoyée dans inlineData avec role:model. Le canal issu de l’ingénierie inverse ne le permet pas : il faut lui transmettre à nouveau l’image à chaque étape.
Point 2 : les termes évoquant une lumière chaude dans l’invite
Pourquoi l’image tire vers le chaud : Nano Banana ne se contente pas de modifier les pixels d’une zone précise. Sa documentation officielle indique qu’il peut notamment ajuster la palette de couleurs. Un exemple de Google demande aussi d’« adapter la lumière et les ombres à un environnement extérieur » : le modèle peut donc harmoniser l’éclairage et les ombres sur toute l’image. Si l’invite contient des termes comme « chaleureux », « soleil de l’après-midi », « crépuscule », « ambiance » ou « style Instagram », le modèle risque de donner une dominante chaude à l’ensemble de l’image. Dans une autre discussion sur un forum, un utilisateur rapporte que la saturation et les tons de peau tiraient encore vers le rouge malgré l’instruction « changer uniquement les vêtements, conserver la lumière et l’arrière-plan ». Corriger l’invite peut donc réduire le risque, mais ce n’est pas forcément la seule cause.
Comment vérifier en 30 secondes : supprimez de l’invite tous les termes liés à la lumière, à l’ambiance et aux tonalités. Ne changez rien d’autre, puis relancez la génération pour voir si la valeur a* des zones neutres baisse nettement.
Comment corriger : suivez le principe recommandé par Google — « décrivez ce que vous voulez, plutôt que ce que vous ne voulez pas » — et précisez les couleurs du produit à conserver. Vous pouvez utiliser directement cette invite :
Modifie uniquement la couleur et le motif du coussin de banquette de fenêtre. Conserve tout le reste à l’identique. Préserve l’éclairage de la photo d’origine, la balance des blancs, la direction des ombres et l’arrière-plan ; garde le rebord de fenêtre blanc et les murs d’un blanc neutre ; n’ajoute ni filtre chaud, ni coucher de soleil, ni éclairage chaud, ni lumière de bougie, ni tonalité de pellicule ; utilise une température de couleur neutre de lumière du jour pour l’ensemble ; respecte les valeurs de couleur que je fournis pour le produit, par exemple vert foncé #2F4F4F.
En anglais, le principe est le même : Keep whites neutral, Use a neutral daylight color temperature, puis indiquez la valeur hexadécimale. D’après les essais d’utilisateurs sur le forum, ce type de formulation « fonctionne parfois, mais pas à tous les coups ». Après modification, réessayez 1 à 2 fois ; si l’image tire toujours vers le chaud, passez au point 3.
Point 3 : la dominante apparaît en 2K/4K, mais se voit à peine en 1K
Pourquoi cette dominante apparaît : dans une discussion sur les teintes rosées sur le forum officiel de Google, des utilisateurs signalent une dominante visible sur les images produites en 2K et 4K, mais invisible ou presque en 1K. Nano Banana Pro et Nano Banana 2 seraient tous deux concernés, et le phénomène serait mesurable aussi bien en PNG qu’en JPG. Google n’a pas indiqué dans cette discussion si un correctif était prévu. Autrement dit, à invite identique, le niveau de résolution peut lui-même être un facteur.
Autre point qui prête facilement à confusion : la résolution de sortie dépend de imageSize et de aspectRatio dans la requête, pas des mentions « 4K » ou « haute définition » dans l’invite.
| Ratio | 1K | 2K | 4K |
|---|---|---|---|
| 1:1 | Environ 1024×1024 | Environ 2048×2048 | Environ 4096×4096 |
| 16:9 | Environ 1376×768 | Environ 2752×1536 | Environ 5504×3072 |
| Comment vérifier | Une image de l’ordre de 1024 pixels correspond au 1K | De l’ordre de 2048 pixels : 2K | De l’ordre de 4096 pixels : 4K. C’est plus fiable que l’étiquette affichée par l’outil |
Comment vérifier en 30 secondes : avec la même image et la même invite, passez imageSize à 1K et relancez la génération. Si le résultat est normal en 1K mais présente une dominante en 2K/4K, suspectez d’abord le pipeline de sortie haute résolution plutôt que l’invite.
Comment y remédier : si le 1K suffit, par exemple pour une miniature d’image principale ou une petite image sur une page produit, commencez par générer en 1K. Si vous avez besoin d’une grande image, lancez une génération avec chacun des trois modèles pour comparer. Voici leurs caractéristiques : Nano Banana 2.1 (gemini-nano-banana-2.1), sorti le 6 octobre 2026, prend en charge le 1K, le 2K et le 4K, mais pas le 512 px ; Nano Banana 2 (gemini-3.1-flash-image) prend en charge le 512 px, le 1K, le 2K et le 4K, et Google recommande officiellement d’utiliser la version 2.1 pour les nouveaux projets ; Nano Banana Pro (gemini-3-pro-image) offre la meilleure qualité. Attention : les signalements sur le forum concernent à la fois Pro et Nano Banana 2, donc passer à Pro ne garantit pas l’absence de dominante. Aucun signalement public de dominante colorée concernant la version 2.1 n’a été trouvé dans les recherches effectuées, mais cela ne suffit pas non plus à conclure qu’elle n’est pas concernée.
| Modèle | Paramètre model |
Résolutions | Prix par génération |
|---|---|---|---|
| Nano Banana 2.1 | gemini-nano-banana-2.1 |
1K / 2K / 4K | 0,045 $/génération |
| Nano Banana 2 | gemini-3.1-flash-image |
512 px / 1K / 2K / 4K | 0,055 $/génération |
| Nano Banana Pro | gemini-3-pro-image |
1K / 2K / 4K | 0,09 $/génération |
| Plateforme disponible | APIYI apiyi.com | Changement de modèle avec la même clé API | Vérifié le 30 octobre 2026 |
Prix relevés le 30-10-2026 ; les modèles et tarifs applicables sont ceux de la liste de la plateforme. D’après ce tableau, tester les trois modèles une fois chacun sur la même image coûte environ 0,19 $. En ajoutant un test comparatif en 1K, un cycle complet revient à un peu plus de 0,20 $, bien moins cher que de retoucher manuellement plus de vingt images.
📷 Emplacement de capture 1 (page des journaux d’invocation APIYI) : montrer les quatre colonnes « modèle utilisé, tokens en entrée/sortie, montant facturé, statut » dans la liste des journaux. Elles permettent de vérifier le modèle réellement utilisé et le coût de chaque requête du test comparatif.
Point 4 : le modèle annoncé par l’outil n’est pas forcément celui qui est utilisé
Pourquoi les couleurs dérivent : dans le cas rapporté par le lecteur, l’outil indique que « Banana 2 est utilisé par défaut dès le départ ». Mais l’étiquette affichée dans l’interface ne prouve pas quels sont le modèle, le groupe et le point de terminaison réellement utilisés par la requête. Sur APIYI, la série Nano Banana dispose de deux canaux redondants, AI Studio et Vertex : le groupe par défaut passe par AI Studio via une passerelle officielle, tandis que Vertex est un groupe distinct, absent du groupe par défaut. La FAQ d’APIYI sur les dérives vers le rouge indique que Nano Banana Pro produit assez souvent des tons trop rouges ou trop chauds lors de la retouche d’images. Elle suggère d’essayer le groupe Vertex ou de comparer avec gpt-image-2. Il faut toutefois préciser la limite : des utilisateurs du forum ont reproduit la dérive colorimétrique aussi bien via Replicate que via Vertex. Le canal n’est donc pas la seule cause possible ; passer à Vertex est un test A/B, pas une solution garantie.
Comment vérifier en 30 secondes :
- Sur la page des jetons, vérifiez à quel groupe la clé est associée ; le groupe se configure sur le jeton, pas dans une entrée de journal individuelle.
- Dans les journaux d’invocation, vérifiez le nom du modèle réellement utilisé, les tokens et le coût.
- Regardez la taille d’une image 4K : environ 18 à 20 Mo avec Vertex, contre 9 à 10 Mo avec AI Studio. Cela donne un indice indirect sur le canal.
- Vérifiez le
modelVersiondans la réponse pour vous assurer que l’outil n’a pas changé de modèle à votre insu.
📷 Emplacement de capture 2 (page des groupes de jetons APIYI) : montrer la liste déroulante des groupes lors de la création ou de la modification d’un jeton, en repérant le groupe Default et les groupes associés à Vertex. Préciser que « pour changer de canal, il suffit de changer le groupe du jeton, sans modifier le code ».
Comment corriger : créez un jeton associé au groupe Vertex, puis relancez le test avec la même image et la même invite ; la méthode d’invocation reste inchangée. Pour une invocation compatible OpenAI, renseignez https://api.apiyi.com/v1 comme base_url. Pour la retouche d’image, l’image de référence doit toutefois être fournie en base64, conformément aux exigences de Gemini : n’insérez pas une URL dans image_url sous prétexte que vous utilisez le format compatible. Si les deux groupes produisent une dérive, essayez gpt-image-2 : selon la documentation d’APIYI, sa fidélité des couleurs est généralement meilleure en retouche d’image. Il tend à effectuer des « retouches légères de l’image d’origine », tandis que banana pro privilégie une « réinterprétation stylisée ». Il faudra donc ajuster l’invite après avoir changé de modèle. Pour les modèles disponibles et leur facturation, référez-vous à la liste de la plateforme. Vous pouvez aussi refaire d’abord le test sur l’interface Web imagen.apiyi.com, avec la même image de référence et la même instruction, afin d’écarter un problème dans votre propre code.
Point 5 : l’image a subi une compression supplémentaire
Pourquoi les couleurs dérivent : après sa génération, l’image peut être compressée à nouveau par un outil, un hébergeur d’images ou une plateforme e-commerce. La compression utilise souvent le sous-échantillonnage de chrominance : elle conserve moins de détails de couleur que de luminosité. Sur les forums, certains utilisateurs signalent aussi que les images produites par le modèle semblent contenir des informations de couleur à plus basse résolution, ce qui complique les corrections ultérieures. Il faut toutefois distinguer les deux phénomènes : la compression JPEG peut salir les couleurs et créer des blocs colorés sur les contours, mais elle n’explique pas une dominante rouge uniforme sur toute l’image. Celle-ci est surtout liée au modèle, à l’image de référence ou à l’invite.
Comment vérifier en 30 secondes : regardez les propriétés du fichier. Si une image 4K ne pèse que 1 à 2 Mo, ou si ses dimensions en pixels n’atteignent pas l’ordre de 4 096, elle a probablement subi une compression supplémentaire ou le paramètre imageSize n’a pas été pris en compte. Dans l’exemple de la documentation APIYI, le champ inlineData.mimeType d’une image générée avec succès vaut image/jpeg. Le tableau parts peut contenir du texte ou des images intermédiaires : récupérez la dernière image.
Comment corriger : commencez par enregistrer le fichier original renvoyé par le modèle et gardez la compression pour la toute dernière étape, avant la livraison. Si vous réutilisez l’image générée comme entrée pour une nouvelle itération, appliquez les règles de compression des images d’entrée : compressez-la uniquement si elle dépasse 1,5 Mo, limitez son côté le plus long à 2 048 px, réglez la qualité à 0,9 et conservez le format d’origine. En dernier recours, corrigez l’image en postproduction : prenez l’image d’origine comme référence, mesurez le décalage médian des valeurs a/b dans les zones neutres, puis appliquez une translation LAB à toute l’image en modifiant uniquement a/b, sans toucher à L*. D’après les tests d’utilisateurs sur des forums, cette correction a produit des résidus inférieurs à 0,3 lors de trois essais, sans modifier la structure ni la luminosité de l’image. Elle se prête donc bien au traitement par lots avec un script.
Nano Banana : diagnostiquer une dominante rouge en 10 minutes
Voici comment enchaîner les cinq points précédents dans un ordre facile à suivre. Chaque étape a son critère de validation : passez à la suivante seulement s’il est rempli. Sinon, corrigez le problème avant de continuer.
| Étape | Action | Critère de validation |
|---|---|---|
| 1. Conserver les éléments | Enregistrez l’image originale et l’image générée. Notez leurs dimensions en pixels, leur poids, leur type MIME et la présence ou non d’un profil ICC. | Les informations des deux images sont complètes et le résultat peut être reproduit. |
| 2. Mesurer la dominante | Relevez les valeurs a/b dans une zone neutre. | Ne continuez que si a* dépasse de plus de 2 points la valeur de l’original. Sinon, vérifiez l’affichage. |
| 3. Vérifier l’image de référence | Convertissez-la en sRGB, vérifiez le base64 et cherchez le token IMAGE. | promptTokensDetails contient IMAGE. |
| 4. Repartir de l’original | Ne modifiez pas le résultat de l’itération précédente. | La valeur a* de l’image générée en une seule passe ne continue plus à augmenter d’une itération à l’autre. |
| 5. Modifier l’invite | Reformulez la consigne de balance des blancs pour obtenir un rendu neutre, puis réessayez 1 à 2 fois. | La valeur a* de la zone neutre revient à moins de 2 points au-dessus de celle de l’original. |
| 6. Comparer en 1K | Avec la même image et la même invite, réglez imageSize sur 1K. |
Déterminez si le rendu est normal en 1K mais présente une dominante en 2K/4K. |
| 7. Changer de modèle | Testez une fois chacun des modèles 2.1 → 2 → Pro. | Identifiez celui qui présente la plus faible dominante et notez le coût. |
| 8. Changer de canal | Essayez un autre groupe Vertex ou testez gpt-image-2. | Comparez les deux résultats pour déterminer si le problème est lié au canal. |
| 9. Corriger en post-traitement | Effectuez un décalage dans l’espace LAB en prenant l’image originale comme référence. | L’écart dans la zone neutre est proche de 0 par rapport à l’original. Conservez les paramètres de correction. |
Quelques correspondances entre symptômes et causes sont utiles à retenir : si la dominante varie d’une exécution à l’autre avec la même invite, il s’agit d’une variation d’échantillonnage ; réessayez 1 à 2 fois. Si chaque modification accentue le rouge, c’est une accumulation au fil des itérations. Si le problème ne concerne qu’un outil ou un groupe, vérifiez le canal, les paramètres ou l’encodage. Chaque appel API est une opération atomique : avec la même invite et la même image, le résultat peut être bon une fois et mauvais la suivante. Réessayer est donc une solution valable en soi.
💡 Conseil de comparaison : les étapes 7 et 8 sont plus faciles à réaliser sur une même plateforme. Avec APIYI sur apiyi.com, utilisez la même clé API pour tester différents modèles et deux jetons pour comparer différents groupes. Les journaux d’appel enregistrent le modèle et le coût de chaque essai, ce qui facilite la comparaison.
Questions fréquentes (FAQ)
Q1 : La dominante rouge après modification avec Nano Banana est-elle un bug reconnu par Google ?
Google ne l’a pas confirmé. Sur le forum officiel, des utilisateurs ont signalé une légère dominante rose ou rouge après modification et fourni des mesures a*. Mais Google n’a ni confirmé la cause dans la discussion ni annoncé de correctif. Les chiffres cités dans cet article proviennent de tests réalisés par des utilisateurs.
Q2 : Passer à Nano Banana Pro évite-t-il la dominante rouge ?
Pas forcément. Les signalements sur le forum concernent aussi bien Pro que Nano Banana 2, et la FAQ d’APIYI indique que Pro a souvent tendance à réchauffer les couleurs lors de la modification d’images. Le mieux est de tester les trois modèles avec la même image et la même invite, puis de comparer les valeurs a*, plutôt que de changer de modèle au jugé.
Q3 : Nano Banana 2.1 corrige-t-il la dominante rouge ?
Aucun correctif n’a été annoncé publiquement. La version 2.1 est sortie le 6 octobre 2026. Selon Google, elle améliore la qualité d’image et la cohérence sur plusieurs tours. Aucun signalement de dérive colorimétrique n’a été trouvé dans les sources consultées, mais cela ne signifie pas qu’elle en est exempte. Google recommande d’utiliser la version 2.1 pour les nouveaux projets : vous pouvez donc la tester en premier.
Q4 : Passer au groupe Vertex résout-il forcément le problème ?
Ce n’est pas garanti. Des utilisateurs du forum ont également reproduit la dérive colorimétrique via Vertex. Changer de groupe permet seulement de faire un test A/B. Sur APIYI apiyi.com, il suffit de changer le groupe dans le jeton, sans toucher au code : le test demande donc peu d’efforts et vaut la peine d’être tenté.
Q5 : Pourquoi les images générées par l’API ont-elles une dominante colorée alors que celles de l’interface web semblent normales ?
La version web de Gemini est un agent : elle peut réécrire l’invite et effectuer plusieurs essais en interne pour sélectionner le meilleur résultat. L’API, elle, effectue une seule invocation et transmet l’invite telle quelle au modèle. Autre cause fréquente : l’image de référence n’a pas réellement été transmise. La documentation d’APIYI apiyi.com recommande d’utiliser le format base64 pour l’image de référence et de vérifier la présence de jetons IMAGE dans `promptTokensDetails`.
Q6 : Comment corriger en lot une vingtaine d’images déjà trop rouges ?
Utilisez une correction par décalage dans l’espace LAB : prenez l’image originale non modifiée comme référence, mesurez le décalage médian des valeurs a*/b* dans une zone neutre, puis appliquez le décalage inverse à toute l’image, en ne modifiant que a*/b*. Un utilisateur du forum a mesuré un résidu inférieur à 0,3. Cette correction intervient après coup : pour traiter le problème à la source, commencez par le diagnostic en 10 minutes.
Nano Banana : points clés pour corriger une dominante rouge
- Mesurez avant de corriger : la dominante est réellement présente dans le fichier si la valeur a* d’une zone neutre dépasse de plus de 2 celle de l’image d’origine.
- Préparez une image de référence propre : convertissez-la en sRGB et utilisez base64, sans placer d’URL dans
image_url. - Repartez de l’original à chaque modification : lors d’un test utilisateur avec trois modifications successives en 4K, la valeur a* est passée de 2,02 à 7,78.
- Formulez positivement les consignes d’éclairage : décrivez un blanc neutre, une température de couleur de lumière du jour et la conservation de la balance des blancs d’origine.
- Utilisez la 1K comme comparaison rapide : si le résultat est normal en 1K mais présente une dominante en 2K ou en 4K, suspectez d’abord la chaîne de traitement haute résolution.
- Comparez modèles et canaux en A/B : avec la même clé API, changez de modèle et de groupe, puis vérifiez les coûts dans les journaux.
- Gardez un décalage LAB en solution de secours : modifiez uniquement a et b ; la correction par lots peut être automatisée par script.
Conclusion
Pour diagnostiquer une dominante rouge lors de la modification d’images avec Nano Banana :
- Vérifiez d’abord que la dominante est présente dans le fichier : mesurez la valeur a* d’une zone neutre pour écarter un problème d’affichage, puis passez aux cinq points de contrôle.
- Procédez du moins coûteux au plus coûteux : image de référence → consignes d’éclairage dans l’invite → modèle et résolution → canal d’invocation → compression de sortie. Chaque point peut être vérifié en 30 secondes.
- Comparez plutôt que de deviner : comparaison en 1K, entre trois modèles et entre deux groupes ; une série complète coûte un peu plus de 0,20 $.
- Gardez les limites en tête : aucune de ces étapes ne garantit la suppression de la dominante rouge. Elles permettent seulement d’en réduire la probabilité, de la localiser, puis de la corriger.
Pour les équipes qui modifient des photos de produits par lots, nous conseillons d’intégrer à la procédure habituelle le retour à l’image d’origine, une invite demandant une balance des blancs neutre et une comparaison en 1K. Sur APIYI, apiyi.com, utilisez la même clé API pour comparer les modèles et les canaux, puis vérifiez dans les journaux d’invocation le modèle et le coût de chaque requête.
📚 Références
- Gemini API « Nano Banana image generation » : présentation des modèles, des résolutions et des capacités de retouche
- Lien :
ai.google.dev/gemini-api/docs/image-generation -
Détails : source officielle pour
imageSize,aspectRatio, la signature de raisonnement et la formulation des consignes de conservation des détails (consultée le 30 octobre 2026) -
Google Cloud « Gemini image generation best practices » : bonnes pratiques pour les invites
- Lien :
docs.cloud.google.com/gemini-enterprise-agent-platform/models/capabilities/gemini-image-generation-best-practices -
Détails : source du principe « Décrivez ce que vous voulez, plutôt que ce que vous ne voulez pas »
-
Tableau des modèles abandonnés de l’API Gemini : état de publication et d’arrêt des différents modèles
- Lien :
ai.google.dev/gemini-api/docs/deprecations -
Détails : confirme qu’aucune date d’arrêt n’a été annoncée pour les versions stables 2 et Pro
-
Discussion sur le forum officiel de Google concernant la dominante rose : tests réalisés par des utilisateurs sur une légère dominante rose après retouche
- Lien :
discuss.ai.google.dev/t/edited-images-return-with-a-slight-pink-color-cast-after-migration-from-preview-to-image/176315 -
Détails : les données sur l’accumulation de a*, les différences entre 1K, 2K et 4K et les écarts résiduels après correction LAB proviennent tous de tests réalisés par des utilisateurs
-
Centre de documentation APIYI : « Que faire si l’image tire vers le rouge après une retouche avec banana pro ? », « Guide de développement de la série Nano Banana », « Compression des images et résolution de sortie » et « Journaux d’appels »
- Détails : informations propres à la plateforme sur les groupes, les canaux, la transmission d’images en base64, le volume des données en sortie et les champs des journaux (vérifiées le 30 octobre 2026). Vous pouvez rechercher ces documents par leur titre dans le centre de documentation
Auteur : équipe technique APIYI
Échanges techniques : contactez-nous depuis la page d’accueil du site APIYI. Pour plus de ressources sur l’intégration des modèles d’image, consultez le centre de documentation docs.apiyi.com
