| name | train-krea2-lora |
| description | End-to-end workflow to create a custom Krea 2 image LoRA: research and assemble a training dataset (source images, curate by vision, write captions, optimize resolution), train it on fal's krea-2-trainer, validate the result, and publish it to the Hugging Face Hub with a proper model card and native <Gallery />. Use this whenever the user wants to train a Krea 2 LoRA, make a custom Krea image style/character/object, "train a lora like the krea ones", build or caption a dataset for Krea 2, fine-tune Krea 2 RAW/Turbo, run the fal krea-2-trainer, or publish a Krea LoRA to Hugging Face — even if they mention only one phase (e.g. "caption these images for a krea lora", "what resolution for krea training", or "publish my krea lora"). Also triggers on artist-style LoRAs for Krea (e.g. a Magritte or Ghibli style) and on questions about Krea LoRA steps / learning rate / dataset size. |
Train a Krea 2 LoRA (dataset → fal training → Hugging Face)
This skill captures a proven, end-to-end recipe for shipping a Krea 2 LoRA. It is organized as six phases. Walk through them in order, but you can enter at any phase if the user already has (say) a dataset or trained weights.
The bundled scripts/ are the tested implementations — prefer running them over re-writing equivalents inline. The references/ files hold the detailed knowledge; read them when a phase needs the depth.
The core facts that make results good
These are the non-obvious lessons. Internalize them before touching the trainer.
- Train on RAW, run on Turbo. Krea built
krea/Krea-2-Raw (undistilled) so LoRAs trained on it express strongly on the fast krea/Krea-2-Turbo. The fal trainer does this for you; inference uses Turbo.
- ~1000 steps is the sweet spot for a ~30-image style set. More is usually worse. In direct A/B, 2000 steps overcooked a 32-image Magritte set (harder, over-saturated compositions) vs. a clean 1000-step run. Raise steps only for large/complex datasets, and compare before trusting it. Keep the learning rate at the default 5e-4 (Krea's recommended range is 3e-4–7e-4, constant).
- The dataset and captions are the real quality levers — the fal trainer only exposes
steps and learning_rate, so spend your effort on image selection, motif diversity, and captions, not hyperparameter twiddling.
- Captions = trigger phrase + content only. Describe what is depicted; do NOT write style/medium words ("surreal", "oil painting", "anime", "cinematic") into the body, so the look binds to the trigger phrase rather than to generic tokens. This keeps the style controllable and strong.
- Feed native ~1.5–2K images, aspect-preserved. Don't downscale to 1024 and never upscale. Krea renders at 1–2K; higher-fidelity source helps and the trainer buckets down as needed. Upscaling injects artifacts that poison a style LoRA.
- Render previews and outputs at ~1.5–2K, not 1024 — this is the #1 cause of "the LoRA looks bad." High-frequency style traits (crisp edges, panel lines, fine linework, weathering) cannot be resolved at 1024px on a 12B model, so the same weights look soft at 1024 and sharp at 2048. If results look soft, re-render larger BEFORE suspecting the LoRA or dataset. The fal inference endpoint accepts a custom
image_size: {width, height} (up to very large); the preset square_hd is only 1024×1024, so pass explicit {width, height} (e.g. 2048×1280) for real evaluation and galleries.
Phase 1 — Scope & trigger phrase
Settle three things with the user (pick sensible defaults and state them rather than stalling):
- What is being trained: a style, a character/person, or an object/product. Keep it narrow — one clean concept beats a mixed bag.
- Trigger phrase. Choose a short, distinctive phrase the base model doesn't already know, so the LoRA "owns" it. A coined token plus a category word works well, e.g.
mgrtt style, ztoy plush, arwn character. Avoid plain real names the base model already recognizes (e.g. just "Magritte") — they collide with prior knowledge.
- Image count. 15–40 for a style, 10–30 for a character/object. Quality and consistency beat quantity.
Phase 2 — Research & source a candidate pool
There is no single right source — research the web to find the best images for this specific subject. Treat sourcing as an open research task: ask where high-quality, consistent, appropriately-licensed examples of this concept actually live, search for them, then download from wherever is best. Don't default to one site.
Goal: gather ≈1.5–2× your target count of strong candidates so curation can be selective. Judge each potential source on resolution (native, ≥~1000px short side — see core facts), consistency with the concept, license/rights, and whether you can fetch true originals (not thumbnails).
Where the good images live depends on the subject (go where they are, this is not exhaustive):
- User-supplied images — if the user has them, use them and skip to Phase 3.
- Paintings / fine art — the WikiArt JSON API is reliable;
scripts/wikiart_fetch.py fetches, filters, de-dupes, and downloads full-res originals for an artist. Museum open-access APIs (the Met, Art Institute of Chicago, Rijksmuseum) are excellent for public-domain works.
- Photographic styles / real-world subjects — Wikimedia Commons (has a real API), Unsplash/Pexels, Flickr Commons, other CC/stock sources.
- A character / franchise / niche aesthetic — wikis, fan archives, official galleries, curated web-search results.
- Anything else — general web search, then download and validate.
Whatever the source: validate each file opens as a real image (not an error page or a thumbnail), and record provenance (URL/title) for the manifest and card. scripts/wikiart_fetch.py is a worked example of the fetch → filter → validate → manifest pattern — adapt it to other sources rather than treating WikiArt as the only path.
Read references/recipe.md ("Sourcing") for the WikiArt API specifics and per-source tips.
Phase 3 — Curate & caption (this is where vision matters)
For each candidate, look at the image and judge it. With many candidates and subagents available, fan this out (one agent per image returning a small JSON verdict); otherwise do it inline. For each image capture: is it a genuine, on-target example; does it belong to the right period/variant (exclude off-style outliers); is the scan/photo clean (no watermark, frame, glare, heavy compression); what are its key motifs; and a one-sentence concrete content description.
Then select the final set to maximize motif diversity so the LoRA learns the whole vocabulary instead of overfitting one composition — cap any single dominant motif to roughly a quarter of the set. Drop low-quality and off-style images.
Write each caption as: <trigger phrase>, <concrete content description> — lowercase content, 8–25 words, varied sentence openings, no style/medium words in the body (see the core facts above). Save captions alongside selection (a JSON list of {src, caption} is the handoff to Phase 4).
See references/recipe.md ("Curation & captioning") for the assessment rubric and selection heuristics.
Phase 4 — Optimize images & package
Run scripts/optimize_images.py with your selection JSON. It produces the training set: sRGB-converted, downscaled-only to ≤2048 on the long side, dimensions aligned to /16, metadata stripped, sequentially numbered NN.png + matching NN.txt caption, plus a dataset_manifest.json. Then zip images + captions at the archive root (same-stem pairing is what the trainer expects):
cd <dataset_dir> && zip -q ../dataset_fal.zip *.png *.txt
Phase 5 — Train on fal & validate
Train with scripts/fal_train.py (needs FAL_KEY and pip install fal-client):
python scripts/fal_train.py --zip <dataset_fal.zip> --trigger "<trigger phrase>" --steps 1000
It uploads the zip, calls fal-ai/krea-2-trainer (steps 1000, LR 5e-4 by default — the proven settings), downloads the .safetensors, and prints the fal-hosted lora_file URL. Cost ≈ $0.0028/step (~$2.80 for 1000 steps).
Always validate before publishing. Run scripts/fal_sample.py --lora <lora_file_url> to generate a few previews via fal-ai/krea-2/turbo/lora, then actually view them. Render at ~1.5–2K (the script now defaults to 1536; use --width 2048 --height 1280 for wide compositions) — 1024 hides fine detail and will make a good LoRA look soft. Match preview prompts to the style's own domain (abstract compositions for an abstract style; scenes for a scene-based one); use figurative subjects only to probe generalization, and keep those out of the published gallery. To compare two runs (e.g. step counts), scripts/build_gallery.py renders a static side-by-side gallery using the same seed per prompt so only the LoRA differs.
Read references/recipe.md ("Training & inference") for fal schema details, the inference endpoint, and the native-key-format caveat (these weights load on the fal endpoint as-is; the diffusers path may need a key remap).
Phase 6 — Publish to Hugging Face
Follow the model release checklist. Build the card from references/model_card_template.md — it mirrors the official Krea LoRA cards: frontmatter with base_model: [krea/Krea-2-Turbo] + base_model_relation: adapter, instance_prompt, a widget of prompt→image previews, license: other / krea-2-community-license, discoverability tags, and the native <Gallery /> component (not a manual markdown image grid). Then:
hf repos create <user>/<RepoName> --type model --private
hf upload <user>/<RepoName> <staging_dir> . --commit-message "Add <name> Krea 2 LoRA"
hf repos settings <user>/<RepoName> --public
Stage a clean folder: the weights (named like the concept, e.g. magritte.safetensors), README.md, and an images/ gallery. Verify metadata parsed with hf models card <id> --metadata.
See references/recipe.md ("Publishing") for the full checklist mapping and frontmatter field reference.
Ethics & rights
Style imitation is generally fine, but if the subject is a living/recent artist or a real person, surface the copyright/likeness consideration: train for personal/research use, default the repo to private, don't present outputs as authentic originals, and let the user decide on public release. Note the source provenance in the dataset manifest and card.
