par GoogleImage
Nano Banana
11 modèles · à partir de 76 crédits
Modèles de la famille Nano Banana
| Modèle | Mode | Prix | Formats d'image | |
|---|---|---|---|---|
| Nano Banana 2 Edit | Édition d'image | à partir de 100 crédits | — | Ouvrir → |
| Nano Banana 2 Reference to Image | Image | à partir de 100 crédits | 1:1 · 3:2 · 2:3 · 3:4 · 4:3 · 4:5 | Ouvrir → |
| Nano Banana 2 Text-to-Image | Texte vers image | à partir de 100 crédits | — | Ouvrir → |
| Nano Banana 2.1 EditNouveau | Édition d'image | à partir de 83 crédits | 1:1 · 3:2 · 2:3 · 3:4 · 4:3 · 4:5 | Ouvrir → |
| Nano Banana 2.1 Reference-to-ImageNouveau | Image | à partir de 400 crédits | 1:1 · 3:2 · 2:3 · 3:4 · 4:3 · 4:5 | Ouvrir → |
| Nano Banana 2.1 Text-to-ImageNouveau | Texte vers image | à partir de 80 crédits | 1:1 · 3:2 · 2:3 · 3:4 · 4:3 · 4:5 | Ouvrir → |
| Nano Banana Edit | Édition d'image | à partir de 76 crédits | 1:1 · 3:2 · 2:3 · 3:4 · 4:3 · 4:5 | Ouvrir → |
| Nano Banana Pro Edit | Édition d'image | à partir de 175 crédits | — | Ouvrir → |
| Nano Banana Pro Edit Ultra | Édition d'image | à partir de 188 crédits | — | Ouvrir → |
| Nano Banana Pro Text-to-image | Texte vers image | à partir de 175 crédits | — | Ouvrir → |
| Nano Banana Pro Text-to-image Ultra | Texte vers image | à partir de 188 crédits | — | Ouvrir → |
Règles de LUVI Prompt Engine pour Nano Banana 2.1
TARGET MODEL: Nano Banana 2.1 (Google, gemini-nano-banana-2.1). It reads a brief the way a language model reads one: positively, in prose. There is no negative_prompt, no weighting and no style dial.
Règles à respecter
- Narrative prose, not tag stacks. Describe a scene a person could photograph or design: register → subject and action → setting → light → camera → in-image text → finish.
- Exclusions become presences that do NOT name the excluded thing: "no people, no cars" → "a quiet, deserted street", never "no cars" and never "empty of people and cars". Naming the unwanted thing can summon it.
- Aspect ratio and resolution are parameters. Never write "16:9", "widescreen", "4K" or "8k" into the prose — on a conflict the parameter wins and the words are wasted.
- In-image text: put every visible string in double quotes, exactly as it must read, and describe the type (weight, style, colour) and its placement in plain words. Never write the words "in quotes" or "quoted" — the model draws the quotation marks. Every other visible surface (signs, apparel, packaging, screens) is either given quoted copy or described as plain/blank; unquoted incidental lettering comes back as gibberish.
- Keep quoted copy verbatim. If it contains an em dash, the model draws it as a separate rule that splits the line: add OUTSIDE the quotes that the text stays on a single line with a literal em dash between the phrases. Example: a sign reading "Taze simit — İçeride çay var" on a single line, with a literal em dash between the two phrases.
- Non-English copy (e.g. Turkish İ ı ğ ş ç) is kept character-exact and LARGE in the frame; small lettering drops diacritics at any resolution.
- People: keep every physical detail the user gave (age, build, hair, wardrobe, expression) — never flatten a described person to "a man"; vague unnamed people drift toward real public-figure lookalikes. Keep distinct on-screen identities few; give extras varied faces or defocus them.
- Never ask for a transparent background — the model has no alpha. Ask for a plain seamless white background instead.
Ce qui fonctionne le mieux
- Open with the operation and the deliverable: "Create an image: a photorealistic product photograph of …", "… an infographic poster …".
- State purpose and audience when known ("for an e-commerce product page", "suitable for a 4th grader").
- Many elements → order them in words: "First … Then … Finally …".
- When the user names light, lens or mood, phrase it concretely ("soft window light from the left" beats "cinematic lighting"). Do not add light directions, lenses, camera specs, scene elements (buildings, props, background figures) or wardrobe the user did not ask for — expand only what the user wrote.
- Prose over JSON: when the user supplies JSON, rewrite its content as prose — JSON loses counted details and soft details.
Issu des règles de LUVI Prompt Engine pour cette famille : les mêmes que celles qu'appliquent le réécriveur de l'espace de travail et le connecteur MCP de LUVI.
Règles de LUVI Prompt Engine pour Nano Banana
Notes
- Nano Banana has no negative_prompt — describe positively (“an empty, deserted street”, not “no cars”). Naming what you don’t want can summon it into the frame.
- Weight syntax such as (word:1.3) is ignored; it only wastes prompt space.
- Keep to at most 5 distinct characters in one prompt.
Issu des règles vérifiées de LUVI pour cette famille.