Génération d'images Gemini avec invite

Questions
1

Décrire le problème/l’erreur/la question

Bonjour à tous,
Je rencontre un problème avec un comportement d’exécution imbriqué à l’intérieur d’un nœud Loop Over Images.

Ma configuration :

  1. Loop Over Images : Traite une liste d’images récupérées de Google Drive une par une (Batch Size = 1).
  2. À l’intérieur de la boucle : Pour chaque image, elle crée un dossier (Create Concept Folder) et télécharge le fichier image.
  3. Expansion d’éléments : Ensuite, un nœud Code (Build Prompts) prend les données d’une seule image et génère 6 variations de requête différentes (développant avec succès 1 élément entrant en 6 éléments sortants).
  4. Traitement : Les nœuds suivants (Gemini data, HTTP Request, Upload Concept Image) s’exécutent 6 fois parfaitement pour la première image.
  5. Retour de boucle : À la fin de la chaîne d’exécution, j’utilise un nœud Limit défini sur Max Items = 1 pour ramener les 6 éléments à exactement 1 élément avant de le réinjecter dans le port d’entrée Loop Over Images.

Le problème :

  • La première itération fonctionne parfaitement (crée le dossier, génère et télécharge les 6 images de concept).
  • À la deuxième itération (pour la deuxième image), la boucle se déclenche correctement, et le nœud Create Concept Folder s’exécute avec succès.
  • Cependant, juste après la création du dossier, le flux de travail s’arrête complètement. Les nœuds suivants (Download Image, Build Prompts, etc.) ne s’exécutent pas du tout pour le deuxième élément.
    Il semble que n8n perde le suivi de la séquence d’exécution ou de l’index d’élément lors de la deuxième itération de boucle, car le nombre d’éléments a été développé de 1 à 6 à l’intérieur du corps de la boucle, même si j’ai utilisé un nœud Limit pour renvoyer exactement 1 élément au compteur de boucle.
    Comment puis-je réinitialiser correctement le contexte/l’index d’élément à l’intérieur de la boucle pour que la deuxième itération s’exécute complètement ?
    (Remarque : je joins la capture d’écran de ma disposition de flux de travail ci-dessous)

Quel est le message d’erreur (le cas échéant) ?

Veuillez partager votre flux de travail

image
image1551×401 76.1 KB

(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le flux de travail.)

Partagez la sortie renvoyée par le dernier nœud

Informations sur votre configuration n8n

  • Version n8n :
  • Base de données (par défaut : SQLite) :
  • Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
  • Système d’exploitation :
2

Bonjour, cela semble être un problème de structure de boucle plutôt que quelque chose que vous pouvez corriger en « réinitialisant » l’index d’élément. Le nœud Limit réduit uniquement le nombre d’éléments transmis ; il ne restaure pas le contexte d’élément de la boucle externe d’origine. Dans n8n, la liaison d’éléments est importante quand un nœud développe ou transforme des éléments, surtout quand des expressions dépendent ultérieurement de .item ou de données du nœud précédent.

Je restructurerais cela comme une boucle imbriquée appropriée :

Boucle externe : Loop Over Images
→ Create Concept Folder
→ Download Image
→ Build Prompts

Puis boucle interne : Loop Over Prompts
→ Gemini data
→ Generate Concept Image
→ Prepare Binary
→ Upload Concept Image
→ retour à Loop Over Prompts

Une fois que la boucle interne Loop Over Prompts est terminée, connectez sa sortie Done au nœud de boucle externe Loop Over Images pour que l’image suivante commence. Ne réinjectez pas l’un des six éléments prompt/image générés dans la boucle externe d’images. Le nœud Loop Over Items de n8n est conçu pour traiter des lots et continuer ensuite à partir des chemins de boucle/terminé, et les nœuds traitent souvent les listes automatiquement, donc le nombre d’éléments doit être contrôlé par la structure de boucle plutôt que corrigé avec Limit.

De plus, dans le nœud Code Build Prompts, copiez les champs d’image/dossier d’origine dans chacun des 6 éléments prompt générés, par exemple imageId, imageName, folderId et le chemin du fichier téléchargé. De cette façon, l’étape de téléchargement n’a pas besoin de s’appuyer sur des références d’éléments de boucle externe fragiles. Si vous utilisez des expressions .item ultérieurement, assurez-vous que le nœud Code préserve la liaison d’éléments/pairedItem, car n8n a besoin de ce lien quand un élément d’entrée devient plusieurs éléments de sortie.

3

Bonjour @Gokhan_ARSLANTAS Bienvenue !
Tu peux supprimer la boucle entièrement. Create Concept Folder s’exécute déjà une fois par image entrante, donc alimente directement la liste des fichiers Drive dedans, puis laisse un nœud Code émettre chaque combinaison image x prompt comme des éléments plats (2 images, 6 prompts = 12 éléments), chacun portant son propre folderId, fileId et prompt :

const scenarios = ['scenario 1', 'scenario 2', 'scenario 3', 'scenario 4', 'scenario 5', 'scenario 6'];
const images = $('List Images').all();

return $input.all().flatMap((folder, i) => scenarios.map((s, n) => ({
  json: {
    folderId: folder.json.id,
    fileId: images[i].json.id,
    filename: `${images[i].json.name}-v${n + 1}.png`,
    prompt: `${images[i].json.name}, ${s}`
  }
})));

Remplace List Images par le nom de ton nœud de liste Drive. Download Image, Gemini data, HTTP Request et Upload Concept Image s’exécutent ensuite chacun une fois par élément, donc tout fonctionne en une seule ligne droite sans nœud de boucle et sans arête qui se réalimente.
Si l’API image te limite le débit, régule le nœud HTTP Request avec Add Option > Batching (Items per Batch = 1, Batch Interval = 1000) plutôt que de remettre une boucle.

4

Bonjour James, Merci beaucoup pour vos commentaires. J’ai essayé mais je ne peux pas résoudre le problème. Je reçois également de l’aide d’un agent IA pour insérer les informations dans les nœuds. C’est peut-être pour cela que je ne peux pas. Cordialement

5

Cher Anshul, je vais l’essayer maintenant. Merci pour tes commentaires. Par conséquent, j’utilise une image par invite pour 6 invites différentes. Il n’y a pas deux images d’entrée en même temps. Ta solution est toujours OK ?

6

Salut @Gokhan_ARSLANTAS
Oui. Une seule image signifie que le nœud Code émet 6 éléments au lieu de 12, et Download Image, Gemini data, HTTP Request et Upload Concept Image s’exécutent chacun 6 fois. Rien d’autre ne change.
Si c’est toujours exactement une image, tu peux supprimer l’appairage d’index et le garder plat :

const scenarios = ['scenario 1', 'scenario 2', 'scenario 3', 'scenario 4', 'scenario 5', 'scenario 6'];
const image = $('List Images').first().json;
const folderId = $input.first().json.id;

return scenarios.map((s, n) =	({
  json: {
    folderId,
    fileId: image.id,
    filename: `${image.name}-v${n + 1}.png`,
    prompt: `${image.name}, ${s}`
  }
}));

Laisse le nœud Code en Mode : Run Once for All Items, ce qui est le paramètre par défaut, puisque le code retourne lui-même le tableau entier de 6 éléments.

7

Je confirme le diagnostic de James, c’est exactement le problème classique de mélanger les niveaux de boucle dans n8n.

Le nœud Limit ne « réinitialise » rien du contexte de la boucle externe — il filtre seulement le nombre d’items qui passent. Le Loop Over Images s’attend toujours à ce que le flux qui revient à son entrée ait la même « forme » (lignage d’items) que celui qui en est sorti, et quand tu mets un nœud Code qui expand 1→6 au milieu, tu casses ce lignage même si tu le réduis ensuite à 1 avec Limit.

La solution de boucle imbriquée que propose James est la bonne. Quelques points à surveiller lors de sa mise en œuvre :

  • Dans le nœud Code Build Prompts, assure-toi de retourner explicitement pairedItem dans chacun des 6 items générés, en pointant vers l’index de l’item original. Si tu ne le fais pas, toute expression ultérieure qui dépend des données de l’item parent (imageId, folderId, etc.) peut échouer silencieusement au lieu de donner une erreur.
  • La boucle interne (Loop Over Prompts) a besoin de sa propre Batch Size bien configurée — si tu la laisses avec la même taille que l’externe par erreur de copier-coller, tu retrouves le même symptôme.
  • Vérifie que la sortie « Done » de la boucle interne (pas « Loop ») soit celle qui se reconnecte à l’externe — c’est une erreur courante de connecter le mauvais port et de se retrouver coincé dans une boucle infinie ou courte.

Avec cela, la deuxième itération et au-delà devraient être résolues.