Retouche d’images NSFW avec n8n : créer de nouveaux looks par lots depuis une référence

Pour retoucher par lots une série de personnages NSFW dans n8n, faites de chaque image demandée un job, gardez ses références ensemble et ramenez chaque variante à la même source de personnage validée. Téléchargez les fichiers dans un dossier de revue, puis ne transférez que ceux approuvés dans le dossier de livraison. Vous obtenez un processus reproductible sans prendre une requête API terminée pour la preuve que le visage a été conservé.

Le plus difficile n’est généralement pas d’écrire six prompts. Il faut que six éléments reçoivent la bonne source, la bonne tenue et la bonne pièce, que chaque résultat reste lié à ses consignes, et que la version choisie soit retrouvable après expiration du lien temporaire. Un workflow peut tourner parfaitement et livrer le mauvais personnage si ces décisions manquent.

Ce guide construit un exemple complet : six images de soirée de Mara, adulte fictive de 34 ans. Nous changerons vêtements, lumière et cadrage en gardant une identité établie. L’exemple public utilise des vêtements opaques et des instructions non explicites. Les mêmes mécanismes servent au contenu adulte autorisé, mais ni n8n ni ce tutoriel ne garantissent l’acceptation ou le rendu attendu de toutes les demandes NSFW.

Le workflow proposé s’appuie sur le nœud communautaire SpicyAPI publié et le schéma actuel de retouche. Ce n’est pas le compte rendu d’un nouveau lot de six images exécuté. Les instructions distinguent l’automatisation du nœud des décisions créatives qui restent les vôtres.

Construisez la série autour d’une image de personnage validée

Commencez par l’image que vous montreriez à quelqu’un demandant qui est Mara. Choisissez une vue propre et assez rapprochée, un visage lisible, la coiffure à conserver et un éclairage ne cachant pas la moitié des traits. Dans cet exemple, elle a des boucles brunes aux épaules, un sourire légèrement asymétrique et un caraco bleu foncé opaque sous une veste anthracite. Elle est assise près d’un canapé vert. Ces détails rendent les retouches concrètes sans longue biographie inventée.

Gardez ce fichier comme original de personnage. Il doit rester dans votre stockage même après envoi à SpicyAPI. Une URI temporaire facilite les références pendant la production ; ce n’est pas une archive permanente. Versionnez l’original, par exemple mara-master-v1, pour qu’un changement de coiffure ultérieur ne modifie pas silencieusement les sources d’une ancienne série.

Préparez deux images supplémentaires. La tenue montre une robe de satin bordeaux opaque sur cintre ou mannequin, sans visage concurrent. La pièce montre un salon vide avec lampe en laiton et meubles en velours vert. Le modèle doit recevoir trois attributions : la personne depuis la première image, le vêtement depuis la deuxième, le décor depuis la troisième.

Une photo de pièce avec une autre personne importante rend cette distinction floue, tout comme une tenue portée par un modèle au visage visible. Si ce sont les seules références disponibles, recadrez la partie nécessaire avant envoi. Le but n’est pas d’accumuler le plus grand pack, mais de lever l’ambiguïté sur le rôle de chaque image.

Gardez la première demande de caméra proche de la source. Un portrait assis de trois quarts soutient mieux un autre portrait assis qu’une plongée extrême avec tête détournée. C’est une recommandation de travail, pas un taux mesuré. Le modèle dispose de moins d’informations lorsque le nouvel angle lui demande d’inventer des traits jamais montrés.

Ne construisez pas la série comme original → nouvelle tenue → nouvelle pièce → nouvelle pose → gros plan. Chaque sortie ajoute une interprétation du visage. Une dérive à la deuxième étape peut devenir la base de la troisième. Nos six lignes pointent toutes vers mara-master-v1, pas vers le résultat précédent. Une chaîne pour une petite réparation peut être volontaire, mais doit être un choix séparé, pas un accident des connexions.

La première image définit l’identité, la deuxième le vêtement et la troisième la pièce. Illustration.

Choisissez l’endpoint avant l’automatisation

Utilisez un modèle de retouche, pas un text-to-image recevant seulement la description du personnage. Le nœud Edit Image intégré à n8n recadre, redimensionne et compose des fichiers ; ce n’est pas l’éditeur génératif qui change tenue ou pièce. Ici, l’ID est alibaba/qwen-image-2.1/edit. La page de retouche Qwen Image 2.1 décrit la tâche et ses contrôles réels.

L’endpoint actuel accepte image_urls avec une à dix images, un prompt obligatoire de 5 000 caractères maximum, un ratio, un niveau de résolution et un format. Il retourne une image par requête. Six images voulues correspondent donc à six tâches. Trois références dans une requête produisent toujours une seule sortie, pas trois variantes.

Pour notre lot multi-références ordinaire, choisissez resolution: 2k, aspect_ratio: 4:5, output_format: png et background: opaque. Réglez enable_prompt_expansion à false pour commencer avec les instructions écrites inchangées. La désactivation existe en 1k et 2k ; c’est un réglage de comparaison utile, pas un verrou d’identité. Laissez le seed vide au départ. Le répéter ne garantit ni le visage ni le même fichier.

Le schéma actuel n’expose ni strength, ni CFG, ni étapes, ni prompt négatif séparé. N’ajoutez pas les champs familiers de Stable Diffusion parce qu’un autre tutoriel les utilise. Placez préservation et exclusions dans le prompt principal. Pour des contrôles locaux d’échantillonnage, choisissez un workflow qui les expose réellement.

L’endpoint possède aussi mask_url pour une autre tâche : réparation locale avec exactement une référence. Nous ne l’utilisons pas pour la série à trois sources. Une réparation de bord de vêtement après sélection peut devenir une tâche masquée distincte. Envoyer personnage, vêtement et pièce avec un masque violerait la règle du mode local.

Le catalogue décrit cet endpoint comme sans restriction. C’est pertinent pour choisir un éditeur NSFW, pas une garantie sur votre prochain lot. L’article de retouche Qwen existant traite d’autres résultats observés. Ce tutoriel ajoute la production par lots ; il ne transforme pas ces observations en nouveau benchmark de cohérence.

Installez le vrai nœud et nommez les éléments du workflow

Pour le package, la clé et les templates HTTP Cloud, ouvrez le guide officiel SpicyAPI n8n. Suivez ensuite la préparation de scènes ou de références propre à ce workflow.

Le package est @spicyapi/n8n-nodes-spicyapi, version 0.1.1. Sur n8n auto-hébergé, ouvrez Settings → Community Nodes → Install, entrez le nom et installez. Créez le credential SpicyAPI (spicyapi.ai) API avec la clé de la console API. Gardez la base URL par défaut sauf raison précise de la changer.

n8n Cloud autorise les nœuds communautaires vérifiés ; publier sur npm ne suffit pas à la vérification. Ce guide utilise le nœud sur n8n auto-hébergé. Sur Cloud, les mêmes appels peuvent être faits avec HTTP Request intégré, sans attendre les listes ou téléversements automatiques du package. La documentation actuelle d’installation n8n explique cette distinction.

Il n’existe pas d’opération SpicyAPI distincte nommée « Edit Character » ou « Batch NSFW ». Choisissez Resource: Image → Operation: Generate, puis le modèle de retouche. Generate est l’opération des modèles d’image, y compris la retouche ; le modèle détermine la tâche. La liste affiche des prix de départ, pas le devis fini de votre pack.

Nous construirons deux petits workflows. Le premier produit et sauvegarde les candidats pour revue. Le second lit les lignes approuvées et place les fichiers retenus en livraison. Cela permet d’examiner six images ensemble sans laisser une exécution attendre votre retour, et de relivrer sans payer une nouvelle génération.

Nommez les nœuds importants : Read Jobs, Ready Jobs, Loop Jobs, Prepare Edit, Edit Character, Attach Job, Save Candidate et Record Candidate. Les expressions y feront référence. Si vous choisissez d’autres noms, adaptez-les. C’est un guide de construction manuelle, pas l’affirmation qu’un template officiel importable existe pour cette série exacte.

Commencez par Manual Trigger. Une programmation viendra après le comportement attendu, mais le premier essai doit contenir un job délibéré. Un dossier de nouveaux uploads n’est pas encore un brief de production. Le tableau précisera les fichiers associés et la sortie demandée.

Faites six lignes de jobs, pas un dossier de fichiers vaguement liés

Utilisez un Google Sheet avec onglet Jobs. Chaque ligne est une sortie demandée. Attribuez job_id unique, nom de lot, prompt, trois sources, résolution, ratio, numéro de tentative et statut. Vous pourrez réessayer une image précise sans régénérer les autres.

Les six demandes varient assez pour former une série utile :

Utilisez batch_id: mara-evening-01 et attempt: 1 partout. Marquez d’abord seulement M01 ready, les cinq autres draft. Quand un candidat atteint le stockage avec les bonnes informations de ligne, passez les autres à ready. Ce départ teste le vrai parcours de retouche, pas seulement un credential isolé.

Gardez character_uri, wardrobe_uri et room_uri dans des colonnes distinctes. Elles peuvent contenir les URI nouvellement téléversées ou des URL publiques récupérables par l’API. Trois champs se lisent mieux qu’une chaîne JSON complète. Prepare Edit les assembliera dans image_urls en ordre fixe.

Ajoutez des colonnes de résultats sans écraser le brief : task_id, candidate_file_id, candidate_name, review_status, review_note, delivery_file_id et actual_cost. Avec plusieurs candidats par job, mettez-les dans Candidates, indexé par candidate_id, tandis que Jobs conserve le plan demandé. Le premier passage a un candidat par ligne ; cette séparation devient utile dès que M03 demande deux essais.

Un ID candidat peut être mara-evening-01-M03-a2. On y lit lot, plan et tentative. L’ID API reste essentiel à la reprise, mais ne décrit pas la tenue demandée. Conservez les deux.

Les statuts sont des états de production simples : draft, ready, pending_review, approved, identity_fix, creative_fix, task_error et delivered. Ce sont vos valeurs de tableau, pas les états SpicyAPI. L’API peut dire succeeded tandis que vous dites identity_fix, car l’image existe mais son visage ne correspond pas à la série.

Planifiez tenue, pose et cadrage de chaque job avec une seule référence de personnage. Illustration.

Faites entrer les références sans confondre octets et URL

n8n peut porter JSON et fichiers binaires sur le même élément. Une URL est une chaîne JSON. Une photographie téléchargée appartient à une propriété binaire comme data ou character. Ni le nom de propriété ni son identifiant de stockage ne sont une URL publique d’image.

Pour un job rapide, téléchargez le personnage depuis le stockage via son intégration n8n dans character, le vêtement dans wardrobe et la pièce dans room. Faites arriver ces fichiers sur le même élément que le prompt. Si Edit Fields intervient entre téléchargement et génération, gardez Include Binary Data activé. Sinon, le JSON peut survivre tandis que les photos disparaissent.

Dans SpicyAPI, ajoutez trois entrées à Media Inputs. Pour chacune, choisissez image_urls, Source: Binary File et le Input Binary Field correspondant : character, wardrobe ou room. Répéter le même champ de liste est voulu. Le nœud téléverse ces binaires et construit le tableau dans l’ordre ajouté.

N’ajoutez pas trois entrées à un champ de fichier unique comme mask_url. Le plugin vérifie cette différence et signale plusieurs sources vers un champ unique. La liste média vient du schéma choisi. Si elle affiche un champ inconnu, vérifiez le modèle avant de copier un nom d’un autre workflow.

Pour réutiliser les trois sources, un téléversement explicite se gère mieux. Téléchargez chaque original dans n8n, puis utilisez SpicyAPI → File → Upload avec son nom binaire. La réponse contient uri, fileId, fileName, mimeType et bytes. Placez uri dans la colonne source du lot.

Upload retourne un nouvel objet JSON et ne recopie pas automatiquement reference_role. Pour une liste de trois éléments, préservez ce rôle par expressions liées ou fusion explicite. Au début, trois nœuds nommés séparément se contrôlent mieux : personnage, tenue et pièce. Copier chaque URI dans le tableau rend les rôles visibles avant une retouche payante.

Les entrées téléversées sont temporaires ; l’implémentation décrit une conservation d’un jour. Réenvoyez depuis les originaux pour un lot ultérieur. Ne supposez pas qu’un spicy:// collé le mois dernier reste utilisable. Gardez IDs Drive ou clés de stockage permanent près des URI pour les recréer.

Une URL de page de partage Drive est une autre erreur fréquente. L’API demande les octets, pas une page HTML de prévisualisation après connexion. Au lieu de rendre les originaux publics, laissez Drive télécharger le binaire avec votre credential, puis téléversez via SpicyAPI. Le dossier source peut rester privé.

Pour nos six lignes, utilisez des URI fraîchement créées partout. Définissez trois Media Inputs en Source: URL avec {{ $json.character_uri }}, {{ $json.wardrobe_uri }} et {{ $json.room_uri }}. Ici, URL accepte aussi une URI Spicy. Vous évitez de transporter trois binaires complets dans chaque opération de tableau.

Gardez plusieurs références dans un seul élément

Il existe deux sens de « plusieurs images ». Six jobs doivent donner six éléments n8n. Les trois références d’un job restent un tableau de trois entrées dans cet élément. Diviser ce tableau en trois éléments change le sens : l’éditeur pourrait recevoir trois demandes indépendantes à une référence chacune.

Cette distinction apparaît dans une discussion Reddit sur les albums Telegram. L’auteur constatait des exécutions séparées pour plusieurs images ; Wait retardait chacune sans regrouper l’album. Les réponses proposent un buffer par identifiant partagé ou une séparation collecte/traitement. Ce n’est pas une solution universelle, mais « attendre » n’équivaut clairement pas à « assembler un pack de références ».

Notre tableau évite cette collecte : il déclare les trois références avant retouche. Pour un futur formulaire multi-fichiers, la collecte doit produire un élément contenant tous les fichiers et rôles choisis. Ne laissez pas chaque fichier déclencher Edit Character seul. Un vêtement envoyé ne doit pas devenir une demande indépendante de le redessiner.

Utilisez les entrées Media Inputs répétées ou construisez la liste dans Additional Parameters (JSON). La boîte attend un objet, fusionné en dernier. Ses clés remplacent Prompt, Model Parameters et Media Inputs. C’est utile pour un tableau dynamique, mais peut masquer les valeurs sélectionnées visuellement.

Cette expression produit par exemple un objet complet depuis la ligne préparée :

{{ {
  prompt: $json.edit_prompt,
  image_urls: [$json.character_uri, $json.wardrobe_uri, $json.room_uri],
  resolution: $json.resolution,
  aspect_ratio: $json.aspect_ratio,
  output_format: "png",
  background: "opaque",
  enable_prompt_expansion: false
} }}

Choisissez une méthode pour le tableau. Avec cette expression, laissez Media Inputs vide pour ne pas envoyer des fichiers ensuite remplacés. Avec la liste visuelle, omettez image_urls des paramètres additionnels. L’entrée assemblée doit contenir un tableau de trois éléments, pas un tableau imbriqué ni une chaîne séparée par des virgules.

Une colonne de tableur ressemblant à du JSON peut rester du texte. Nos URI séparées évitent l’incertitude. Avec references_json, parsez en tableau avant génération et arrêtez la ligne si cela échoue. "[first,second,third]" n’est pas une liste d’URL.

Le principe vaut aussi pour résolution et booléens. Placez false comme booléen, pas comme texte "false". Entrez 2k comme enum valide, pas des dimensions devinées. Le formulaire issu du schéma montre justement les valeurs acceptées.

Écrivez une première consigne qui attribue correctement chaque source

Dans Prepare Edit, construisez edit_prompt avec une introduction fixe de rôles et la demande du plan. Edit Fields suffit à joindre les chaînes ; pas besoin de Code pour six lignes simples. Gardez les instructions d’identité fixes tandis que la ligne apporte le changement.

Une consigne M01 adaptée est :

L’image 1 représente Mara, adulte fictive de 34 ans. Conserve ses proportions faciales, ses boucles brunes aux épaules, son sourire légèrement asymétrique et sa pose assise. L’image 2 fournit uniquement la robe de satin bordeaux opaque : copie couleur, encolure et emplacement des coutures, pas l’identité d’une autre personne. L’image 3 fournit uniquement le salon, le canapé de velours vert et la lampe en laiton. Place Mara dans ce salon avec la robe. Garde un portrait naturel, des yeux lisibles et une lumière chaude douce. Cadre un portrait assis de trois quarts en 4:5. N’ajoute aucune autre personne, aucun texte ni accessoire supplémentaire.

C’est un prompt proposé, pas exécuté et noté ici. Il attribue chaque image, décrit le changement et nomme quelques éléments reconnaissables. Il indique aussi quoi faire en cas de contradiction : visage depuis l’image 1, vêtement depuis la 2.

Pour M02, remplacez la phrase du plan par un portrait à mi-corps, la lampe éclairant un côté du visage. Ne répétez pas M01 avec dix termes de caméra contradictoires. Pour M03, remplacez la conservation de pose assise par une pose debout explicite près du canapé, mains détendues et visibles. Demander de conserver l’assise et de se lever crée une contradiction évitable.

M04 veut une lumière de fenêtre. Gardez boucles et vêtement, mais précisez la lumière froide avec lampe en fond. Le changement concerne lumière et position, pas une nouvelle description de personnage. M05 réutilise la veste anthracite de l’original sur la robe bordeaux ; dites-le clairement, car le modèle pourrait raisonnablement suivre seulement la référence de vêtement.

M06 veut une composition assise plus large avec espace libre d’un côté. Ce n’est pas une réduction aléatoire du visage par recadrage ultérieur. Donnez la composition voulue puis examinez le visage en pleine taille. Le plan large sert à une bannière mais offre moins de détails pour juger l’identité.

Placez le style NSFW souhaité dans le brief lorsqu’il convient à l’endpoint et au public. Une étiquette « rends-le NSFW » ne décrit ni tenue, ni expression, ni cadrage, ni ambiance. Le créateur doit les préciser. Dans l’exemple public, soirée adulte, satin opaque et regard direct transmettent le ton sans consignes explicites.

Si le brief exige une pose exacte absente de l’original, créez d’abord une référence validée de cette pose avant un grand lot. Répéter la même demande vague ne remplace pas l’information visuelle manquante. Le premier lot peut utilement améliorer les sources sans fournir immédiatement six images à garder.

Connectez la boucle avec une voie distincte pour les erreurs

Ajoutez Google Sheets Get Row(s) dans Read Jobs, choisissez Jobs et récupérez les lignes du lot. Un Filter nommé Ready Jobs garde status égal à ready. Si le filtre est dans Sheets, vérifiez qu’il retourne toutes les correspondances, pas seulement la première. Un tableau de six lignes donnant un élément n’est pas un lot de six images.

Reliez le filtre à Loop Jobs, un Loop Over Items avec Batch Size 1 et Reset désactivé. Sa sortie loop va à Prepare Edit, puis Edit Character. SpicyAPI traite déjà plusieurs éléments ; la boucle sert ici à finir sauvegarde et statut de chaque ligne avant la suivante.

Configurez Edit Character en Image → Generate, choisissez le modèle exact et mappez Prompt sur l’instruction préparée. Ajoutez les trois références ou l’objet JSON choisi. Activez Wait for Completion et Download Output. Fixez Max Cost per Item (USD) volontairement ; $0.10 est un départ utile pour cet exemple si le devis complet reste dessous.

Le plafond concerne un élément, pas toute la feuille. Cent lignes peuvent chacune passer dix cents. Limitez le lot à six lignes prêtes et ajoutez un plafond de dépense du compte à la clé si vous voulez une seconde frontière. Nombre de lignes et plafond n’améliorent pas l’image ; ils évitent une production accidentellement beaucoup plus grande.

Le nœud obtient son devis avant création. Si la demande dépasse la limite, il échoue avant génération. Un deuxième nœud de devis n’est nécessaire que pour afficher une estimation séparée. Pour planifier, Model → Get Quote évalue les mêmes références et réglages sans créer d’image.

Dans Settings, configurez On Error pour poursuivre par la sortie normale de ce guide. Le résultat d’erreur contient error, description et un ID si disponible. Ajoutez un If après Edit Character testant la présence d’error. La voie erreur note task_error et le message puis revient à Loop Jobs ; la voie réussite sauvegarde le candidat, note pending_review et revient au même point.

N’utilisez pas done pour générer encore. Done sert au résumé une fois toutes les lignes revenues. Vous pouvez lire le tableau actualisé ou afficher des comptes. Gardez les branches explicites : l’erreur API ne va pas en revue comme fichier vide, et le fichier terminé ne part pas directement en livraison.

Pour six retouches, gardez l’attente intégrée ; un callback séparé est généralement inutile. Si l’exécution cesse d’attendre une tâche encore active, copiez son ID dans Task → Get et activez Wait for Completion et Download Output. Get n’attend pas par défaut et peut retourner un état running sans fichier. Dans une exécution de reprise séparée, lisez d’abord la ligne Jobs correspondante, passez par Prepare Edit, puis Task → Get → Attach Job → sauvegarde. Vous préservez les liens des expressions suivantes ; Manual Trigger directement vers Get laisserait Prepare Edit inexécuté. Après récupération réussie, sauvegardez sans revenir à Generate. Un timeout peut contenir l’ID dans description même si taskId est vide : lisez-la avant remplacement. Une nouvelle génération parce que la page semble lente peut devenir une seconde tâche payante alors que l’original réussit plus tard.

Rattachez l’identité du job avant de sauvegarder

En réussite, le nœud retourne tâche et binaires. Son JSON n’est pas la ligne originale augmentée ; il contient taskId, state, cost, settled et output. Voilà pourquoi {{ $json.job_id }} peut être vide malgré le bon prompt.

Ajoutez Edit Fields Attach Job après la branche de réussite. Gardez le JSON de tâche, activez Include Binary Data et ajoutez les champs de production par expressions d’éléments liés. Le nœud fournit l’appariement, donc vous pouvez viser l’élément Prepare Edit spécifique plutôt que la première ligne.

Utilisez {{ $('Prepare Edit').item.json.job_id }} pour job_id, et le même schéma pour batch_id, attempt, edit_prompt et la version source. Utilisez la tâche courante pour task_id avec {{ $json.taskId }}. Construisez candidate_id depuis lot, job et tentative, puis utilisez-le comme racine du nom.

N’utilisez pas $('Read Jobs').first() pour toutes les identités : cela nommerait potentiellement les six sorties M01. Évitez aussi de reconstruire les associations par position après tri ou filtre d’une branche. L’appariement fonctionne tant que la relation est claire ; si vous divisez ou agrégez plus tard, gardez un job_id explicite.

La première ressource téléchargée est data par défaut ; les suivantes data_1, data_2, etc. Notre éditeur retourne une image, donc data va au stockage. Avec un modèle multi-ressources, sauvegarder data ne prouve pas avoir tout enregistré. Choisissez la ressource du candidat ou créez des enregistrements séparément nommés.

Le chemin JSON output.assets[].url contient des liens, pas les octets. Selon la documentation, ils expirent après environ vingt minutes. Un tableau gardant seulement ces URL peut fonctionner immédiatement puis échouer au retour. Download Output donne de vrais octets au stockage.

Les binaires ont aussi besoin d’une destination permanente. Ils n’héritent pas de l’expiration du lien, mais les données d’exécution n8n peuvent être purgées. Une exécution réussie n’est pas une archive. Sauvegarder pendant l’exécution permet de revoir l’image demain sans régénérer.

Sauvegardez pour revue, puis décidez visuellement de la suite

Créez un dossier privé mara-evening-01/review. Dans Save Candidate, ajoutez Drive File → Upload, Input Data Field Name à data, le nom candidat plus .png et ce dossier. La documentation Drive décrit l’envoi binaire.

Le nom doit refléter le vrai format. Écrire .png sur un JPEG ne convertit rien ; notre requête choisit PNG. Gardez l’ID de fichier retourné, pas seulement le nom. Deux fichiers peuvent partager un nom et la livraison doit avoir une source sans ambiguïté.

Drive retourne les métadonnées, pas tout le candidat. Dans Record Candidate, utilisez l’ID courant et les liens vers Attach Job pour candidat, job, tâche et coût. Mappez manuellement dans Candidates avec Append or Update Row, en correspondance sur candidate_id. Une autre tentative n’écrase ainsi pas la première.

Si vous actualisez Jobs, passez la ligne job_id à pending_review. Retournez la dernière mise à jour à Loop Jobs. Sur erreur, notez le job depuis Prepare Edit, la description et l’ID éventuel avant retour. Les deux branches doivent rejoindre la boucle, sinon le lot s’arrête au premier élément.

Examinez les six images à deux tailles. En miniature, forment-elles la série voulue : même personnage, tenue et pièce cohérentes, variations suffisantes ? En pleine taille, comparez yeux, nez, bouche, mâchoire, ligne des cheveux et asymétrie distinctive entre source et candidat. Ce sont des repères visuels pratiques, pas un score biométrique automatique.

Séparez échecs d’identité et de création. Une Mara reconnaissable avec mauvaise lampe demande une autre instruction qu’un beau portrait d’une autre personne. Si le visage convient mais pas la composition, notez creative_fix et le changement manquant. Si le personnage change, notez identity_fix et ce qui diffère, comme mâchoire plus étroite ou autre implantation des cheveux.

N’approuvez pas seulement parce que state vaut succeeded ou qu’une légende automatique décrit la bonne tenue. Un modèle de légende reconnaît une robe bordeaux sans décider si le visage appartient à la série. Un assistant peut suggérer des notes, mais la décision d’approbation reste séparée et visible.

Donnez à chaque échec une prochaine retouche précise

Supposons M01 proche du but, mais avec la forme de cheveux du mannequin de tenue. Vérifiez que l’image 2 n’a vraiment pas de tête concurrente ; sinon recadrez le vêtement. Précisez ensuite que la 2 fournit seulement la robe, et la 1 exclusivement les boucles et l’implantation. Soumettez l’essai 2 depuis l’original, pas le candidat dérivant.

Si M02 ressemble à Mara mais change l’encolure, améliorez la référence textile. Une photo sombre cachant l’encolure ne fournit pas assez d’information. Recadrez une vue nette des coutures puis demandez leur construction en gardant le mi-corps. Ajouter des robes vaguement similaires peut accroître l’ambiguïté.

M03 debout peut échouer de deux façons. Pose plausible mais visage changé : réduisez le changement de caméra et essayez un trois quarts debout tourné vers elle. Visage conservé mais corps maladroit : demandez une position simple près du canapé avec mains détendues visibles. Rotation difficile, bras croisés et lumière extrême ensemble empêchent d’isoler la cause.

M04 peut garder le visage sous une lumière si froide et sombre que la comparaison devient difficile. Avant de parler de dérive, examinez une vue neutre et distinguez éclairage et proportions. Gardez l’emplacement fenêtre en demandant traits lisibles et ombre plus douce. Ne changez pas automatiquement de référence parce qu’un étalonnage rend la personne moins familière.

M05 peut perdre la robe sous une veste devenant une autre tenue. Précisez veste anthracite originale ouverte sur la robe, construction de celle-ci visible. Si un seul bord de veste est défectueux dans un excellent cadre, envisagez une retouche masquée locale du candidat choisi plutôt qu’une nouvelle scène entière. Cette tâche utilise ce candidat seul, pas les trois références initiales.

M06 peut produire l’espace vide mais une tête trop petite pour la couverture. Précisez portrait moyen assis, pièce à gauche, visage assez grand pour être lisible. Le ratio seul n’indique pas où placer le titre. Décrivez la mise en page, pas seulement 4:5 ou 16:9.

Un refus de contenu va dans les erreurs, pas les corrections d’identité. Lisez le motif et choisissez demande ou modèle autorisé adapté ; ne renvoyez pas en boucle une entrée refusée inchangée. Une image rendue mais inadaptée est différente : elle peut être facturée car la génération a réussi. Conservez cette distinction pour voir le coût des essais créatifs inutilisables.

Arrêtez une branche après une limite délibérée, par exemple deux essais au premier passage. C’est un choix de production, pas la prédiction de suffisance de deux essais. Un plan obstiné retourne à la préparation des sources ou au manuel. L’automatisation sert à rendre le problème visible et reproductible, pas à créer vingt variantes sans rapport pendant votre absence.

Comparez proportions du visage et boucles séparément du cadrage du fond et de la position de lampe. Illustration.

Livrez les images approuvées sans les régénérer

Après revue, marquez les candidats choisis approved. Gardez les autres tentatives avec leurs notes. Pour M03, vous pouvez choisir l’essai 2 et conserver le 1 identity_fix. La livraison lit Candidates, pas le fichier le plus récent du dossier.

Construisez le second workflow avec Manual Trigger, Sheets Get Row(s) et filtre review_status égal à approved avec delivery_file_id vide. Ajoutez Loop Over Items, Batch Size 1. Téléchargez chaque candidat par son ID Drive dans data, puis envoyez ce binaire au dossier approved avec le nom de livraison.

Utilisez votre candidat stocké, pas le lien SpicyAPI temporaire. C’est l’image exacte revue. N’appelez pas Image → Generate pour la refaire au même seed ou à plus haute résolution en la supposant encore approuvée. Tout nouveau rendu doit être revu car visage, tenue et cadrage peuvent changer.

Après Upload, actualisez la ligne avec delivery_file_id et review_status: delivered, et éventuellement Jobs avec l’ID retenu. Retournez à la boucle. L’ID fournit un accès stable à la version livrée et empêche une exécution normale ultérieure de retraiter toutes les lignes approuvées.

Nous utilisons téléchargement puis envoi pour rendre le binaire explicite. Une copie native de stockage préservant les octets peut le remplacer. La règle créative reste : livrer copie l’image validée sans relancer l’éditeur.

Placez les exports redimensionnés, recadrés ou compressés dans un autre dossier. Miniature carrée et portrait validé pleine taille sont deux fichiers, même source ou non. Gardez l’original pour d’autres exports sans nouveau coût. Si un recadrage coupe la coiffure ou change la présentation, vérifiez-le pour sa destination.

Ce workflow ne publie pas sur les réseaux. La livraison termine aux fichiers et au tableau de sélection. Cela suffit pour un designer de page, une galerie privée ou un choix manuel des destinations. Ajoutez la publication spécifique plus tard sans la rendre indissociable de génération et revue.

Évaluez le vrai pack de références, pas seulement la liste

Le prix de départ sert à parcourir les modèles. Les références et réglages complets déterminent le devis. Qwen Image 2.1 Edit commence à $0.036 en 1k, $0.048 en 2k et $0.072 en 1.5k. Les devis publics à trois références sont $0.060 en 1k et $0.048 en 2k, en PNG opaque sans expansion. En 1k, les deux références ajoutent $0.024 ; le devis 2k n’a pas cet ajout. Ne supposez pas qu’un niveau intermédiaire coûte moins que 2k ni que le supplément fonctionne identiquement partout.

Utilisez Model → Get Quote avec les mêmes image_urls, prompt et réglages avant de passer les cinq autres lignes à ready. Le nœud retourne l’entrée assemblée avec le devis ; vous verrez aussi si les trois références ont survécu au mapping. L’opération peut téléverser les binaires mais ne génère pas d’image.

Pour notre configuration 2k à trois sources, le devis actuel de $0.048 donne $0.288 pour six candidats et $0.576 pour douze. Six mêmes requêtes en 1k au tarif cité font $0.360. Ce sont des budgets sur devis, pas des reçus d’un lot exécuté ni un comparatif de qualité. Recalculez votre pack avant lancement. Stockage et hébergement ou abonnement n8n sont distincts.

Comptez les essais comme des tâches. Six images validées peuvent demander plus de six générations réussies car des candidats payants ne conviennent pas. Avec deux essais maximum par plan après devis du premier passage, vous prévoyez au plus douze tentatives. C’est plus utile qu’« un lot de six images » sans budget de remplacement.

Le plugin envoie une clé d’idempotence par élément. Réessayer le même appel dans la même exécution vise la récupération de l’existant plutôt qu’un doublon payant. Nouvelle exécution, entrée changée ou nouveau passage de boucle sont du nouveau travail. Cliquer Execute Workflow à nouveau n’équivaut pas à récupérer l’ID original.

Dès qu’une ligne a un ID, récupérez ou examinez la tâche avant remplacement après interruption technique. Si elle a réussi mais que Drive a échoué, récupérez la sortie et terminez la sauvegarde. L’expiration d’un credential de stockage n’améliore pas le visage ; aucune raison créative ne justifie de payer un autre rendu.

La documentation du plugin indique que les tâches failed et expired libèrent normalement la réservation, et que les refus ne sont pas facturés sauf indication contraire du modèle. Un candidat réussi rejeté en revue diffère d’un échec API. Gardez actual_cost de la tâche réglée pour connaître le coût réel de chaque plan livré.

Faites parcourir tout le chemin au premier job, puis étendez

Avant les six lignes, faites générer, sauvegarder et revoir M01. Ouvrez le fichier réel du dossier de revue. Confirmez que la ligne dit M01, que les rôles sont corrects et que le fichier retourné est celui affiché. Un aperçu correct dans le panneau d’exécution ne prouve pas le bon nom ni la bonne association au tableau.

Approuvez puis exécutez une fois la livraison. Ouvrez le fichier approuvé et confirmez son identité avec celui choisi. Relancez sans changer les statuts : la ligne avec ID de livraison doit être ignorée. Effacer manuellement cet ID la rend à nouveau éligible ; ne le faites que pour une nouvelle copie réellement nécessaire.

Passez ensuite M02 à M06 à ready. La boucle doit produire un enregistrement candidat ou une erreur précise par job. Examinez la planche-contact, écrivez de courtes notes concrètes et ne créez que les remplacements justifiés. L’original de personnage reste la source des remplacements ordinaires.

Vous avez maintenant un workflow n8n NSFW image-to-image utile : source définie, références attribuées, jobs séparés, bonne gestion binaire et URI, consignes lisibles et dossier contenant les images choisies. L’automatisation transporte et sauvegarde. La conception des plans et votre sélection déterminent si la série mérite publication.