grahama1970/imagegen

Compétence de génération d'images

Génère ou édite des images pour le projet en cours (par exemple, ressources web, ressources de jeu, maquettes d'interface, maquettes de produits, wireframes, conception de logo, images photoréalistes ou infographies).

Modes et règles de premier niveau

Cette compétence a exactement deux modes de premier niveau :

• Mode outil intégré par défaut (préféré) : outil image_gen intégré pour la génération d'images normales, l'édition et les demandes simples d'images transparentes. Ne nécessite pas OPENAI_API_KEY.
• Mode CLI de secours : CLI scripts/image_gen.py. À utiliser lorsque l'utilisateur demande explicitement le chemin CLI/API/modèle, ou après que l'utilisateur a explicitement confirmé une solution de repli pour la transparence native avec gpt-image-1.5. Nécessite OPENAI_API_KEY.

Dans le cadre du CLI de secours, le CLI expose trois sous-commandes :

• generate
• edit
• generate-batch

Règles :

• Utilisez l'outil image_gen intégré par défaut pour les demandes normales de génération et d'édition d'images.
• Ne passez pas en mode CLI de secours pour un contrôle ordinaire de la qualité, de la taille ou du chemin de fichier.
• Si l'utilisateur demande explicitement une image/un fond transparent, restez d'abord sur image_gen intégré : créez un arrière-plan chroma-key plat amovible, puis supprimez-le localement avec l'assistant installé dans $CODEX_HOME/skills/.system/imagegen/scripts/remove_chroma_key.py.
• Ne passez jamais silencieusement de l'outil image_gen intégré ou du CLI gpt-image-2 au CLI gpt-image-1.5. Traitez cela comme un downgrade de modèle/chemin et demandez à l'utilisateur avant de le faire, sauf si l'utilisateur a déjà explicitement demandé gpt-image-1.5, scripts/image_gen.py ou le CLI de secours.
• Si une demande de transparence semble trop complexe pour un nettoyage chroma-key simple, si l'utilisateur demande une transparence vraie/native, ou si la suppression locale échoue à la validation, expliquez que la transparence vraie nécessite le CLI gpt-image-1.5 --background transparent --output-format png car gpt-image-2 ne prend pas en charge background=transparent, puis demandez s'il faut procéder. Exécutez le CLI de secours uniquement après confirmation de l'utilisateur.
• Le mot batch en lui-même ne signifie pas CLI de secours. Si l'utilisateur demande de nombreuses ressources ou dit de générer par lot sans demander explicitement de contrôles CLI/API/modèle, restez sur le chemin intégré et émettez un appel intégré par ressource ou variante demandée.
• Si l'outil intégré échoue ou n'est pas disponible, dites à l'utilisateur que le CLI de secours existe et qu'il nécessite OPENAI_API_KEY. Ne procédez que si l'utilisateur demande explicitement ce repli.
• Si l'utilisateur demande explicitement le mode CLI, utilisez le workflow scripts/image_gen.py fourni. Ne créez pas de lanceurs SDK ponctuels.
• Ne modifiez jamais scripts/image_gen.py. Si quelque chose manque, demandez à l'utilisateur avant de faire quoi que ce soit d'autre.

Politique de chemin de sauvegarde intégré :

• En mode outil intégré, Codex enregistre les images générées sous $CODEX_HOME/* par défaut.
• Ne décrivez pas et ne vous fiez pas au dossier temporaire du système comme destination intégrée par défaut.
• Ne décrivez pas et ne vous fiez pas à un argument de chemin de destination (le cas échéant) sur l'outil image_gen intégré. Si un emplacement spécifique est nécessaire, générez d'abord, puis déplacez ou copiez la sortie sélectionnée depuis $CODEX_HOME/generated_images/....
• Priorité du chemin de sauvegarde en mode intégré :
  1. Si l'utilisateur nomme une destination, déplacez ou copiez la sortie sélectionnée à cet endroit.
  2. Si l'image est destinée au projet en cours, déplacez ou copiez l'image finale sélectionnée dans l'espace de travail avant de terminer.
  3. Si l'image est uniquement destinée à un aperçu ou brainstorming, affichez-la en ligne ; le fichier sous-jacent peut rester au chemin par défaut $CODEX_HOME/*.
• Ne laissez jamais une ressource référencée par le projet uniquement au chemin par défaut $CODEX_HOME/*.
• N'écrasez pas une ressource existante sauf si l'utilisateur a explicitement demandé un remplacement ; créez plutôt un nom de fichier versionné frère tel que hero-v2.png ou item-icon-edited.png.

Les conseils partagés sur les prompts pour les deux modes se trouvent dans references/prompting.md et references/sample-prompts.md.

Documents/ressources de secours uniquement pour le mode CLI :

• references/cli.md
• references/image-api.md
• references/codex-network.md
• scripts/image_gen.py

Assistant de post-traitement local :

• $CODEX_HOME/skills/.system/imagegen/scripts/remove_chroma_key.py : supprime un arrière-plan chroma-key plat d'une image générée et écrit un PNG/WebP avec alpha. Préférez l'échantillonnage automatique de la clé, le mat doux et le despill pour les bords anti-aliasés.

Quand utiliser

• Générer une nouvelle image (concept art, photo de produit, couverture, héros de site web)
• Générer une nouvelle image en utilisant une ou plusieurs images de référence pour le style, la composition ou l'ambiance
• Éditer une image existante (inpainting, transformations d'éclairage ou météo, remplacement d'arrière-plan, suppression d'objet, composition, fond transparent)
• Produire de nombreuses ressources ou variantes pour une seule tâche

Quand ne pas utiliser

• Étendre ou faire correspondre un ensemble d'icônes/vecteurs SVG, un système de logo ou une bibliothèque d'illustrations existant dans le dépôt
• Créer des formes simples, des diagrammes, des wireframes ou des icônes qui sont mieux produits directement en SVG, HTML/CSS ou canvas
• Effectuer une petite modification de ressource locale du projet alors que le fichier source existe déjà dans un format natif modifiable
• Toute tâche où l'utilisateur veut clairement une sortie déterministe de code natif plutôt qu'un bitmap généré

Arbre de décision

Pensez à deux questions distinctes :

1. Intention : s'agit-il d'une nouvelle image ou d'une édition d'une image existante ?
2. Stratégie d'exécution : s'agit-il d'une seule ressource ou de plusieurs ressources/variantes ?

Intention :

• Si l'utilisateur veut modifier une image existante tout en en préservant des parties, traitez la demande comme une édition.
• Si l'utilisateur fournit des images uniquement comme références pour le style, la composition, l'ambiance ou l'orientation du sujet, traitez la demande comme une génération.
• Si l'utilisateur ne fournit aucune image, traitez la demande comme une génération.

Sémantique d'édition intégrée :

• Le mode édition intégré est destiné aux images déjà visibles dans le contexte de la conversation, telles que les images jointes ou les images générées précédemment dans le fil.
• Si l'utilisateur veut éditer un fichier image local avec l'outil intégré, chargez-le d'abord avec l'outil view_image intégré afin que l'image soit visible dans le contexte de la conversation, puis procédez au flux d'édition intégré.
• Ne promettez pas une édition arbitraire de chemin de système de fichiers via l'outil intégré.
• Si un fichier local nécessite toujours un contrôle direct du chemin de fichier, des masques ou d'autres paramètres explicites du CLI uniquement, utilisez le CLI de secours explicite uniquement lorsque l'utilisateur le demande.
• Pour les éditions, préservez agressivement les invariants et sauvegardez de manière non destructive par défaut.

Stratégie d'exécution :

• Dans le chemin intégré par défaut, produisez de nombreuses ressources ou variantes en émettant un appel image_gen par ressource ou variante demandée.
• Dans le chemin CLI de secours, utilisez la sous-commande CLI generate-batch uniquement lorsque l'utilisateur a explicitement choisi le mode CLI et a besoin de nombreux prompts/ressources.
• Pour de nombreuses ressources distinctes, n'utilisez pas n comme substitut à des prompts séparés. n est destiné aux variantes d'un seul prompt ; les ressources distinctes nécessitent des appels intégrés distincts ou des tâches CLI generate-batch distinctes.

Partez du principe que l'utilisateur veut une nouvelle image sauf s'il demande clairement d'en modifier une existante.

Workflow

1. Décidez du mode de premier niveau : intégré par défaut, y compris pour les demandes simples de sortie transparente ; CLI de secours uniquement si explicitement demandé ou après que l'utilisateur a explicitement confirmé un repli de sortie transparente.
2. Décidez de l'intention : generate ou edit.
3. Décidez si la sortie est uniquement destinée à un aperçu ou doit être consommée par le projet en cours.
4. Décidez de la stratégie d'exécution : ressource unique vs appels intégrés répétés vs CLI generate-batch.
5. Collectez les entrées à l'avance : prompt(s), texte exact (textuellement), contraintes/liste d'évitement, et toutes les images d'entrée.
6. Pour chaque image d'entrée, étiquetez explicitement son rôle :
   • image de référence
   • cible d'édition
   • entrée d'insertion/style/composition de support
7. Si la cible d'édition se trouve uniquement sur le système de fichiers local et que vous restez sur le chemin intégré, inspectez-la d'abord avec view_image afin que l'image soit disponible dans le contexte de la conversation.
8. Si l'utilisateur a demandé une photo, une illustration, un sprite, une image de produit, une bannière ou toute autre ressource explicitement matricielle, utilisez image_gen plutôt que de substituer des espaces réservés SVG/HTML/CSS. Si la demande concerne une icône, un logo ou un graphique d'interface qui doit correspondre aux ressources SVG/vecteur/code natives existantes du dépôt, privilégiez l'édition directe de celles-ci.
9. Augmentez le prompt en fonction de la spécificité :
   • Si le prompt de l'utilisateur est déjà spécifique et détaillé, normalisez-le en un cahier des charges clair sans ajouter d'exigences créatives.
   • Si le prompt de l'utilisateur est générique, ajoutez une augmentation de bon goût uniquement lorsqu'elle améliore sensiblement la qualité de la sortie.
10. Utilisez l'outil image_gen intégré par défaut.
11. Pour les demandes de sortie transparente, suivez les directives d'image transparente ci-dessous : générez avec image_gen intégré sur un fond chroma-key plat, copiez la sortie sélectionnée dans l'espace de travail ou tmp/imagegen/, exécutez l'assistant installé $CODEX_HOME/skills/.system/imagegen/scripts/remove_chroma_key.py, et validez le résultat alpha avant de l'utiliser. Si ce chemin semble inadapté ou échoue, demandez avant de passer au CLI gpt-image-1.5.
12. Inspectez les sorties et validez : sujet, style, composition, précision du texte et éléments invariants/à éviter.
13. Itérez avec un seul changement ciblé, puis vérifiez à nouveau.
14. Pour un travail d'aperçu uniquement, affichez l'image en ligne ; le fichier sous-jacent peut rester au chemin par défaut $CODEX_HOME/generated_images/....
15. Pour un travail lié au projet, déplacez ou copiez l'artefact sélectionné dans l'espace de travail et mettez à jour tout code ou référence consommateur. Ne laissez jamais une ressource référencée par le projet uniquement au chemin par défaut $CODEX_HOME/generated_images/....
16. Pour les lots ou les demandes multi-ressources, persistez chaque livrable final demandé dans l'espace de travail, sauf si l'utilisateur a explicitement demandé de garder les sorties en mode aperçu uniquement. Les variantes écartées n'ont pas besoin d'être conservées sauf demande.
17. Si l'utilisateur choisit ou confirme explicitement le CLI de secours, utilisez alors la documentation de secours uniquement pour le modèle, la qualité, la taille, input_fidelity, les masques, le format de sortie, les chemins de sortie et la configuration réseau.
18. Signalez toujours le(s) chemin(s) de sauvegarde final(aux) pour toute(s) ressource(s) liée(s) à l'espace de travail, ainsi que le prompt ou l'ensemble de prompts final et si l'outil intégré ou le mode CLI de secours a été utilisé.

Demandes d'images transparentes

Les demandes d'images transparentes utilisent toujours d'abord image_gen intégré. Comme l'outil intégré n'expose pas de contrôle de fond transparent véritable, créez une image source chroma-key amovible, puis convertissez la couleur de la clé en alpha localement.

Séquence par défaut :

1. Utilisez image_gen intégré pour générer le sujet demandé sur un fond chroma-key parfaitement plat et uni.
2. Choisissez une couleur de clé peu susceptible d'apparaître dans le sujet : par défaut #00ff00, utilisez #ff00ff pour les sujets verts et évitez #0000ff pour les sujets bleus.
3. Après la génération, déplacez ou copiez l'image source sélectionnée depuis $CODEX_HOME/generated_images/... dans l'espace de travail ou tmp/imagegen/.
4. Exécutez le chemin d'assistant installé, pas un chemin de script relatif au projet :

   python "${CODEX_HOME:-$HOME/.codex}/skills/.system/imagegen/scripts/remove_chroma_key.py" \
     --input <source> \
     --out <final.png> \
     --auto-key border \
     --soft-matte \
     --transparent-threshold 12 \
     --opaque-threshold 220 \
     --despill
   

5. Validez que la sortie a un canal alpha, des coins transparents, une couverture plausible du sujet et aucune frange de couleur de clé évidente. Si une fine frange persiste, réessayez une fois avec --edge-contract 1 ; utilisez --edge-feather 0.25 uniquement lorsque le bord est visiblement crénelé et que le sujet n'est pas brillant ou réfléchissant.
6. Enregistrez le PNG/WebP alpha final dans le projet si la ressource est liée au projet. Ne laissez jamais une ressource transparente référencée par le projet uniquement sous $CODEX_HOME/*.

Formulez les demandes transparentes comme ceci :

Créez le sujet demandé sur un fond chroma-key #00ff00 parfaitement plat et uni pour suppression de fond.
Le fond doit être d'une couleur uniforme sans ombres, dégradés, texture, reflets, plan de sol ou variation d'éclairage.
Gardez le sujet complètement séparé du fond avec des bords nets et un espacement généreux.
N'utilisez pas #00ff00 dans le sujet.
Pas d'ombre portée, d'ombre de contact, de reflet, de filigrane ni de texte sauf demande explicite.

N'utilisez pas automatiquement le CLI gpt-image-1.5 --background transparent --output-format png au lieu du chroma key. Demandez d'abord à l'utilisateur lorsque celui-ci demande une transparence vraie/native, lorsque la suppression locale échoue à la validation, ou lorsque l'image demandée est complexe : cheveux, fourrure, plumes, fumée, verre, liquides, matériaux translucides, objets réfléchissants, ombres douces, ancrage réaliste du produit ou couleurs du sujet en conflit avec toutes les couleurs de clé pratiques.

Utilisez une confirmation concise comme :

Cela nécessite probablement une transparence native vraie. Le chemin intégré par défaut utilise un fond chroma-key plus une suppression locale, mais la transparence vraie nécessite le CLI de secours avec gpt-image-1.5 car gpt-image-2 ne prend pas en charge background=transparent. Cela nécessite également OPENAI_API_KEY. Dois-je procéder avec ce CLI de secours ?

Augmentation des prompts

Reformatez les prompts utilisateur en un cahier des charges structuré et orienté production. Rendez l'objectif de l'utilisateur plus clair et plus actionnable, mais n'ajoutez pas de détails aveuglément.

Considérez cela comme un guide de mise en forme des prompts, et non comme un schéma fermé. Utilisez uniquement les lignes qui aident et ajoutez une courte ligne étiquetée supplémentaire lorsqu'elle améliore sensiblement la clarté.

Politique de spécificité

Utilisez la spécificité du prompt de l'utilisateur pour décider du niveau d'augmentation approprié :

• Si le prompt est déjà spécifique et détaillé, préservez cette spécificité et normalisez/structurez-le uniquement.
• Si le prompt est générique, vous pouvez ajouter une augmentation de bon goût lorsqu'elle améliorera sensiblement le résultat.

Augmentations autorisées :

• indications de composition ou de cadrage
• niveau de polissage ou indications d'utilisation prévue
• conseils pratiques de disposition
• concrétisation raisonnable de la scène qui soutient la demande énoncée

Augmentations non autorisées :

• personnages ou objets supplémentaires qui ne sont pas implicites dans la demande
• noms de marque, slogans, palettes ou éléments narratifs qui ne sont pas implicites
• placement arbitraire spécifique à un côté à moins que la disposition environnante ne le soutienne

Utilisation

…

[tronqué pour la traduction]