DEV Community: LeGo build

From Photos to Brick Designs: 2D Mosaics, 3D Models, and Buildability

LeGo build — Thu, 08 Oct 2026 03:43:25 +0000

Disclosure: This article was written by an AI assistant and checked against the linked source code and a local test run. The open-source 2D mosaic repository and the separate browser-based 3D website are different projects.

These are original concept illustrations for subject ideas—not screenshots of generated output or verified physical builds.

A photo of a dog, a portrait, a city street, a landscape, or a sketch of an imaginary machine can all be a starting point for a brick design. But the interesting engineering question is not “can AI draw it with studs?” It is what information the design actually contains: an editable model, a parts estimate, steps, and the unresolved checks between a digital proposal and a physical build.

Many subjects, different design problems

People and portraits: preserve a recognizable silhouette and facial cues while simplifying colors and small details.
Pets and other animals: balance recognizable pose against thin legs, tails and unsupported shapes.
Buildings and vehicles: a single photo hides back surfaces and structure; perspective can distort proportions.
Landscapes: turn continuous terrain, water and foliage into layers that still read clearly.
Original worlds: imaginative references are useful, but a plausible image is not automatically a feasible model.

So “almost any subject can start the process” is a creative invitation, not a claim that every input produces a ready-to-assemble set. To make the distinction concrete, I use a small, auditable 2D mosaic pipeline below, then explain the separate 3D workflow and the checks it still needs.

A reproducible 2D baseline

A brick-looking image and a usable brick plan are different things. An image model can paint plausible studs without telling you which grid cells are occupied, how many pieces you need, or whether a color can actually be bought. For a flat mosaic, a small deterministic pipeline is often a better starting point than asking a generative model to invent the whole result.

This local-first Python implementation turns an image into a grid, a preview, a printable pattern and an approximate parts count. It does not claim to produce a physically verified build.

The reproducible example

The repository includes a rocket illustration and a generated mosaic:

This animation uses the repository’s actual input illustration and 2D mosaic; it is not a 3D product demo.

For this post, the included CLI was run on that source image:

brickmosaic examples/rocket.png --width 32 --max-colors 10 -o output

The run reported a 32 × 32 grid, 1,024 occupied cells and 10 colors. The 1,024 figure describes this opaque example image; it is not a general result for photos with transparent backgrounds. The project's 11 automated tests also passed in the local environment.

Four decisions that make the output inspectable

1. Normalize and sample the image

The loader applies EXIF orientation before converting to RGBA. The image is then resized to the requested grid dimensions with Pillow's BOX resampling. If height is omitted, it follows the source aspect ratio. Width and height are each limited to 1–128 studs so an accidental input does not create a huge pattern.

2. Treat transparency as an empty cell

A cell below the configurable alpha threshold becomes None in the grid. That sounds minor, but it means a transparent PNG can produce a shaped mosaic instead of a solid rectangular background. Optional local background removal is available for photographs, but segmentation is fallible: a model can remove a thin antenna or keep part of the background. A transparent image with a clean cutout is the more predictable input.

3. Match colors in Lab space, then limit the palette

Raw RGB distance is a poor proxy for perceived color difference. The implementation converts sRGB to CIE Lab (D65) and selects nearest palette entries using squared Delta E 1976 distance. It first assigns each opaque cell to the full palette, chooses the most frequent max_colors entries, then reassigns every opaque cell within that smaller set.

That two-pass step is important: merely dropping less frequent colors would leave holes or inconsistent counts. The palette is an approximate visual reference, not a certified catalogue of manufacturer part/color combinations.

4. Export data as well as a preview

The pipeline writes mosaic.png, pattern.svg, parts.csv and plan.json. The PNG is for a quick look; the numbered SVG is more useful at a workbench. CSV and JSON let you inspect totals and build your own downstream tooling. A test checks that the CSV count and JSON total agree with the grid.

Where AI helps—and where it does not

Optional AI background removal runs locally through U²-Net's u2netp variant. The first AI run downloads model weights; the input image is processed on the user's machine. The segmentation result is only a mask, not a proof of correct bricks or parts availability. The core resize, color assignment and exports are deterministic and work without the AI extra.

A flat 1×1-stud grid still needs a suitable base, real color/part availability checks, and human review. It says nothing about legal connections, load-bearing support or assembly order for a 3D object. Those claims should stay separate instead of calling every brick-style picture “buildable.”

The jump to a 3D proposal

A 2D grid records visible cells. A 3D design must additionally decide depth, hidden surfaces, connections, support, parts and assembly order. Those choices vary by subject: a pet needs pose and support; a building needs walls and a roof; a landscape needs readable terrain layers. One image alone cannot establish every unseen surface.

The separate Image2LEGO browser workflow accepts a reference image and presents an editable 3D brick-model proposal, with model inspection, steps, a parts view and export options. That makes it a broader starting point for portraits, pets, architecture, landscapes and original concepts. It does not mean every proposed connection is legal, stable, or stocked in real colors. Review the model and parts before buying anything.

The open-source 2D implementation contains the CLI, example images and tests. For a separate browser-based 3D proposal workflow, see the photo-to-bricks guide. That website is not the source code of the 2D repository, and its digital proposals also need manual buildability checks before anyone buys parts.

Which subject would you try first—and what would you validate before calling its digital proposal a real build?

Qwen-Image-2.1 on public prompts: the 4/7 was protocol, not capability

LeGo build — Fri, 25 Sep 2026 05:08:10 +0000

There is one sentence in Qwen-Image-2.1's official README that is very easy to scroll past: use the official prompt-rewriting models to expand short prompts into detailed descriptions. In our first round, we followed none of it.

That produced an awkward result: asked to draw "a photo of two clocks" using GenEval's original prompt text, it drew one clock. The two other models on the same machine, same card, same seed went 7 for 7.

The point of this article is that the 4/7 was not a capability ceiling — it was the way we were feeding the model — and that chasing this down explains why the advertised numbers and hands-on experience disagree.

The short version

Most of the gap is about protocol, not about the model.

The recommended pipeline is three things stacked: prompt rewriter + 2048² + 40 steps. Round one used raw short prompts + 1024² + 20 steps — none of the three. Rewrite the prompts into enhancer-style long descriptions and both object-dropping failures pass immediately, at the same resolution, the same seed, on the same machine, with the prompt as the only variable that moved.

Two things follow. First, this model does not eat terse requests: GenEval's prompts are written for automated scorers and happen to be the worst-case input for the recommended pipeline. Second, estimating your real experience from a leaderboard score means ignoring a whole set of pipeline defaults that sit in between.

Round one

Three models on one machine, one GPU, one prompt set: the text is verbatim from public benchmarks (GenEval / DPG-Bench / LongText-Bench), same seed.

	Qwen-Image-2.1	SenseNova-U1.5	FLUX.2-klein-KV
Shape	7B DiT + Qwen3-VL text encoder, RGBA VAE	8B+8B MoT, 8 steps	9B distilled + INT4 KV, 4 steps
1024² per image (median)	52.1 s (20 steps)	9.8 s	1.6 s
2048² per image	102–111 s	13 s	not supported (≤1536)
Text rendering · char accuracy	74.6%	86.5%	40.8%
Text rendering · line hits	25/35	26/35	4/35
Chinese long text, line hits	18/20	18/20	0/20
English long text, line hits	7/15	8/15	4/15
GenEval compositional (7)	4/7	7/7	7/7
DPG-Bench long description (4)	2 good / 2 flawed	4 good	4 good
Native transparent RGBA	✅ unique	✗	✗

The three-way contact sheet:

Qwen's three failures are specific: a photo of two clocks drew one clock; a photo of a purple wine glass and a black apple dropped the apple entirely; a photo of a bench collapsed structurally at 1024².

It also owns two categories outright. Chinese long text: 18/20 line hits, level with SenseNova, where FLUX scores 0/20 — its Chinese comes out as a solid block of garbage. And native transparent RGBA is Qwen-only; if you need cut-out assets, that alone decides the choice.

One failure mode worth remembering: on dense small text, Qwen invents entire blocks of plausible-looking fake words. A chalkboard menu comes out neatly laid out and, up close, entirely fabricated.

Where the gap actually comes from

Source of the gap	Weight	Evidence
Missing prompt rewriter; raw short prompts used	largest	ablation fixes 2/2
Incommensurable metrics: vendor composite vs per-prompt pass rate	large	their board is a total with no GenEval / DPG split
Different opponent: INT4 4-step distill vs full FLUX	medium	the klein-KV we ran against is not on that board
Sampling and scoring	medium	1 image/prompt, single seed; judged by eye, not Mask2Former
Resolution / steps	large for structural failures, small for text	bench: broken at 1K, fine at 2K; long-text scores flat

The second row is worth spelling out: the "small model, big performance" claim rests on Qwen-Image-Bench, a self-published *composite total, with **no GenEval or DPG breakdown* — it is not commensurable with "4 of 7 prompts passed".

The official README, meanwhile, is explicit:

For best results, we recommend using the official prompt rewriting models to expand short prompts into detailed, high-quality descriptions.

and states its defaults plainly: num_inference_steps = 40, 2048 × 2048. Round one followed none of them.

Ablation: only the prompt changes

Same machine, same GPU, 2048², 20 steps, seed 42. The only change is rewriting GenEval's original text into an enhancer-style long description.

a photo of two clocks → original text still draws one clock; long description → exactly two.
a photo of a purple wine glass and a black apple → apple missing with the original; long description → both present, colours bound correctly.

One caveat must travel with this: the right-hand descriptions were hand-written in the enhancer's style, and are not real output from the official rewriter (a fine-tuned Qwen3.5-VL 9B checkpoint we never deployed). So the result shows that prompt form matters enormously — not that the official rewriter would necessarily recover the score.

Do not treat 2K/40 steps as a cure

Re-running the four long-text prompts with the official recipe (2048²/40 steps), with SenseNova at 2048² as a control:

LongText-Bench prompt	Qwen 1024²/20 steps	Qwen 2048²/40 steps (official)	SenseNova 2048²
English chalkboard menu	20.5% · 2/7	13.7% · 3/7	63.4% · 3/7
English festival poster	94.4% · 4/5	80.6% · 2/5	73.3% · 1/5
Chinese slide	81.5% · 12/12	81.1% · 12/12	76.9% · 11/12
Chinese festival poster	90.2% · 3/5	98.6% · 4/5	97.3% · 4/5
mean (char accuracy · line hits)	71.7% · 72.4%	68.5% · 72.4%	77.7% · 65.5%

Text rendering did not improve, and the cost is 172 s/image against 52 s/image at 1024²/20 steps.

An honest qualifier: OCR is not fully comparable across resolutions (smaller, more decorative type at 2K — the poster's 94.4% → 80.6% is the font style eating it), so the fair reading is "no measurable gain", not "2K is worse".

Structural failures, on the other hand, really are a configuration problem — the bench that collapsed at 1024² is fine at 2048²:

So keep the two goals apart: for compositional prompts the lever is prompt rewriting, not resolution; for correct text the lever is the model, and more steps buy nothing.

A second prompt set: 26 vertical prompts

Public leaderboards measure general capability, which does not answer "which model should take this job". So we wrote our own: 9 domains, 26 prompts, each carrying its own checkpoints, every model at two sizes (a uniform 1024² for cross-model comparison, plus each model's recommended size) — 156 images.

Domain	Pick	Key finding
Architecture · exterior	any of the three	SenseNova 1024 and FLUX 1536 hallucinate large signage on glass curtain walls; Qwen does not
Architecture · interior	SenseNova	Most stable light layering. At 1024² Qwen drops mood constraints: a night bedroom comes out as daylight
Portrait	SenseNova (close-ups) / any (group)	The elderly close-up shows the biggest gap: SenseNova is photographic, Qwen visibly smoother
App · UI	SenseNova	The only one that renders a correct Chinese UI already at 1024²
Product · e-commerce	any of the three	Qwen missed "two bottles" at 1024², but its label text is the most accurate
Game · icons	Qwen (single icon)	Single icons are commercial-grade from all three; "12 style-consistent line icons" breaks all three
Anime · 2D	Qwen / SenseNova (FLUX out)	On the Chinese poster both write title, subtitle, slot and studio correctly; FLUX garbles the whole block
Comic · storyboard	SenseNova	Four-panel comic: only it puts each Chinese line in its own panel
Illustration · picture book	SenseNova	Chinese ink-wash: Qwen comes out too faint at both sizes — the negative space swallows the mountains

The App·UI group is the clearest proof that you cannot pick a model from a leaderboard:

At 1024² Qwen shrinks the whole mockup into a small block in the middle with ghosting, recovering only at 2048² (line hits 5/12 → 11/12, char accuracy 63.0% → 86.4%). SenseNova is 12/12 at that size to begin with.

The four-panel comic shows the other thing — on one image, two metrics say different things:

Qwen writes all four lines (4/4 line hits) but attaches them to the wrong panels and mixes in garbled characters, so char accuracy is 34.8%. SenseNova is 100% · 4/4. Hit rate answers "was the sentence written", char accuracy answers "are the characters right" — this prompt needs both.

Latency

Median of the first 18 prompts	Qwen-Image-2.1	SenseNova-U1.5	FLUX.2-klein-KV
1024²	53.2 s	9.8 s	1.5 s
native size	113.1 s (2048²)	13.2 s (2048²)	3.8 s (1536²)

The 8 vertical prompts added later are not in this table and must not be compared: card 3 was held by a render-farm job while they ran, so the Qwen arm moved to a borrowed card and used the more memory-frugal sequential offload mode throughout — 97 s at 1024² / 208 s at 2048², roughly 2× round one's model mode. Offload only changes when weights are staged in and out, not the sampling math, so image quality is unaffected at the same seed, but the timings are not comparable, hence excluded.

Limitations — read these with the numbers

One image per prompt, single seed. A spot check, not a leaderboard score; at n=4–7 a single prompt is ±14%.
Compositional and long-description prompts were judged by eye, not by GenEval's Mask2Former or DPG's mPLUG+CLIP.
The ablation's long descriptions are hand-written stand-ins, not real rewriter output.
The three models did not run the same step count (Qwen 20 / SenseNova 8 / FLUX 4) — "best configuration", not "equal budget".
The 26 vertical prompts are self-authored, not a public benchmark; same one-image-per-prompt caveat.
The FLUX arm is an INT4 4-step distilled deployment, not the full FLUX 2 Pro / Max on that leaderboard.

If you only want the verdict

Renders / portraits / UI mockups / comic panels → SenseNova, and it is usable at 1024², more than 5× faster than Qwen
Anime posters with a big Chinese title, or transparent-background PNGs → Qwen; it owns both
Compositionally complex scenes in Qwen → turn on prompt rewriting first; do not ask with a terse sentence
Strictly consistent multi-element sets (12 icons, say) → none of the three; plan on post-processing
Do not estimate real output quality from a leaderboard total — a whole set of pipeline defaults sits in between

Prompt text, every generated image, timings and OCR scores are public in qwen-image-2.1-bench, alongside an HTML report and the reproduction scripts.

Evidence

raw.githubusercontent.com — https://raw.githubusercontent.com/QwenLM/Qwen-Image-2.1/main/README.md
raw.githubusercontent.com — https://raw.githubusercontent.com/QwenLM/Qwen-Image-2.1/main/README.md
raw.githubusercontent.com — https://raw.githubusercontent.com/QwenLM/Qwen-Image-2.1/main/README.md
raw.githubusercontent.com — https://raw.githubusercontent.com/QwenLM/Qwen-Image-2.1/main/README.md
raw.githubusercontent.com — https://raw.githubusercontent.com/wangsheng1991/qwen-image-2.1-bench/main/README.md
raw.githubusercontent.com — https://raw.githubusercontent.com/wangsheng1991/qwen-image-2.1-bench/main/blog/prompt-rewrite-ablation.md
raw.githubusercontent.com — https://raw.githubusercontent.com/wangsheng1991/qwen-image-2.1-bench/main/README.md
raw.githubusercontent.com — https://raw.githubusercontent.com/wangsheng1991/qwen-image-2.1-bench/main/README.md
raw.githubusercontent.com — https://raw.githubusercontent.com/wangsheng1991/qwen-image-2.1-bench/main/README.md
raw.githubusercontent.com — https://raw.githubusercontent.com/wangsheng1991/qwen-image-2.1-bench/main/README.md
raw.githubusercontent.com — https://raw.githubusercontent.com/wangsheng1991/qwen-image-2.1-bench/main/README.md
raw.githubusercontent.com — https://raw.githubusercontent.com/wangsheng1991/qwen-image-2.1-bench/main/README.md

Picking an image model is not the expensive part

The useful lesson here is not which model won. It is that the same model scores differently depending on how you feed it — between a leaderboard total and the job on your desk sits a whole set of pipeline defaults. If the job is an interior render, that step is already done for you: RenVi turns one room photo and one style description into a finished render, with the model, resolution and step count handled server-side.

Upload a room photo, get one render free: https://www.houseplusplus.com/?ref=qwen-image-2-1-bench

An ID photo spec table where every number carries the sentence it came from

LeGo build — Thu, 24 Sep 2026 02:42:04 +0000

What it solves

The photo you hand in with a document application is a pile of millimetre figures.

The two most common Russian formats are 3 × 4 cm — medical records, student IDs, passes, military IDs — and 35 × 45 mm, for passports and visa paperwork. It sounds simple until you actually have to crop one: how tall is the head, how much space above it, how white is the background, how many pixels are enough?

Search for any of those and every page gives a different answer.

Not because anyone is careless, but because these numbers live in sources of different ages that copy each other: a government page states one part, a photo studio's instructions state another, a visa agency copies both and rewords one. There is no way to tell which figure has a source behind it and which is something a person typed in passing.

So I did something deliberately dumb: every number carries the sentence it appeared in.

What cropping to a spec actually looks like: pick the row, drag the crown and chin onto the guide lines, export a printable 10 × 15 cm sheet. The photo never leaves the browser. https://wangsheng1991.github.io/content-engine/topics/passport-photo/
— (@wangsheng199.bsky.social) 2026-09-25T10:50:56.709Z

What a row actually is

A row is not "3 × 4 = 30 × 40 mm". It is:

size in millimetres
a head-height band
a headroom band (the space above the head)
background colour
minimum DPI
which sheets it can be laid out on (10 × 15 cm, 4 × 6 in, A4)
a status: verified / single-source / disputed
and, for every figure, the source URL and the verbatim sentence

The first two rows came out like this:

Фото 3 × 4 см — 30 × 40 mm, head (to the top of the hair) 26 mm, 2–4 mm from the top edge to the hair, white background, at least 600 dpi.

Фото на паспорт РФ, 35 × 45 мм — 35 × 45 mm, head 32–36 mm (70–80% of the photo's height), 4–6 mm of headroom, white background, at least 300 dpi.

Behind each figure sits a sentence like this one:

необходимо фото размером 30.00mm × 40.00mm с разрешением не менее 600 dpi. Фон должен быть белый, без посторонних предметов и теней.

Source, sentence, date read. The point is that a stranger can re-read that sentence months later instead of trusting me.

Three rules

One: a figure whose sentence cannot be read does not enter the table

This is the most important rule and the easiest one to break. A number shows up, it looks reasonable, it appears in several places — but if I cannot find the sentence itself, it does not go in.

Two: a contradicting figure is not deleted — it stays, with the reason it lost

This is the counter-intuitive one.

One source puts the head height for 3 × 4 at 11–13 mm. Three others say 26 mm. An 11–13 mm head inside a 40 mm frame is a third of the height, which no acceptance desk takes — and the same page says "не менее 70–80%" three entries above.

Normally you delete that as noise.

It is still in the table, with its source and a note on why it was rejected.

Because the next person re-reading that page will hit the same 11–13 mm and have the same moment of doubt. Shown only a clean table, they will assume the scrape was wrong or their reading was, and spend an afternoon re-deriving what I already derived. Left there with the reason, they reach the same conclusion in five seconds.

A rejected judgement is still data; it is just a different shape.

Three: a row with a single source is not shipped

The table holds a third format: the newer 35 × 45 for application forms, head 25–30 mm, headroom 3 mm ± 1 mm.

Exactly one page describes it. The format is still being phased in and there is very little public material.

Its status is single-source, and it never appears on the live site — pages are generated only from verified rows.

The reason is plain: one source is not evidence, it is a claim. The same figure written independently in two unrelated places is what makes it dependable. That rule is hard, and it does not bend because a number looks sensible or because someone is impatient for that size.

Where the photo goes

All of the above is about checking figures. The tool's half has one rule: the photo does not go to a server.

The file is read into a canvas through FileReader, cropped to the chosen spec, annotated with the head-height guide lines so you can check them yourself, laid out into a printable sheet, and downloaded directly with canvas.toBlob. No upload, no backend on this path, no account.

You can open the page, disconnect from the network, and it still works.

The reason for taking this seriously: a document photo is the highest-stakes image most people ever handle. It carries their face, their name usually sits elsewhere in the same application, and it exists in order to be handed to an institution. Making someone upload it to an unfamiliar server just to change its size is indefensible.

What it does not do

Honesty beats a feature list:

It does not find your face. You align the guide; it draws the head-height limits so you can check them.
The background is replaced with a flat colour, not segmented hair by hair. Fine edges will not be perfect.
It will happily produce a photo that gets rejected for reasons it cannot see — expression, glasses glare, shadows, a face turned slightly away. It is a layout tool, not a compliance oracle.
We do not claim "meets visa requirements". Every desk adds its own rule. The tool can vouch for two things — the dimensions and the head proportion — against the source it quotes.

Check it yourself

The cheapest test: print the exported sheet at 100% and measure it. 30 × 40 mm is 30 × 40 mm, and the top of the head sits inside a 4–6 mm band.

To check the figures themselves, every source link is in source.yaml and every sentence is in evidence.json, verbatim.

Evidence

photo-visa.online — https://photo-visa.online/s/foto-na-3-na-4-onlayn
photo-visa.online — https://photo-visa.online/s/foto-na-3-na-4-onlayn
39mm.ru — https://39mm.ru/requirement.html
39mm.ru — https://39mm.ru/requirement.html
39mm.ru — https://39mm.ru/requirement.html
39mm.ru — https://39mm.ru/requirement.html
39mm.ru — https://39mm.ru/requirement.html
pasporta.org — https://pasporta.org/zagranpasport/foto-na-zagranpasport/
pasporta.org — https://pasporta.org/zagranpasport/foto-na-zagranpasport/
visa-guru.ru — https://visa-guru.ru/blog/zagranpassport/foto-na-zagranpasport
39mm.ru — https://39mm.ru/requirement.html

The photo never has to leave your device

This article is about how the specs were verified. If what you actually need is to turn the photo in your phone into a 3 × 4 print, that step needs no install and no upload: pick the size, align the head-height guide and export a printable sheet, all of it on your own device. The photo does not leave the tab, and every size in the table carries the sentence it came from.

Open the passport photo tool (free, no upload): https://www.dlss5nvidia.com/tools/passport-photo?ref=passport-photo

Image-to-video in three parameters: how a 5-second clip costs twice what it should

LeGo build — Tue, 22 Sep 2026 10:09:33 +0000

一张 1024×768 的室内效果图，一句运动提示词，五秒后拿到一段可以发出去的镜头。这是图生视频里最省事的一档，也是我们六月份给渲见（RenVi）做营销素材时走的那条路。

结论先放这里：模型本身没坑，坑在两个参数的默认值上。

我们实际跑出来的东西

项目	实测值
模型	`wan2.6-i2v-flash`
输入	一张效果图，以 data URI 内联
请求参数	`resolution: 720P`、`duration: 5`
输出	1108×830、5.007 秒、H.264、约 5.5 MB
附带音轨	有，AAC 立体声 44.1 kHz
单条成本	¥1.50（本该是 ¥0.75）

那个 AAC 音轨不是我们要的 —— 是没人告诉模型不要。下面三节就是那三个参数。

首尾两帧放在一起是这样，五秒里只有一次缓慢的推镜：

一、`audio` 默认是开着的，价格正好翻倍

官方文档在 audio 这一栏写的是：

可选值：true：默认值，输出有声视频。false：输出无声视频。

而价格页同一行模型是这样标的：720P 有声 0.3 元/秒，无声 0.15 元/秒；1080P 有声 0.5 元/秒，无声 0.25 元/秒。

也就是说，不写 audio 就是按有声计费。五秒的有声 720P 是 ¥1.50，无声是 ¥0.75 —— 差的这一块钱，买到的是一段你根本没打算用的 AI 环境音。

我们那批素材就是这么付的：三条片子的文件里都带着音轨，因为当时的脚本 parameters 里只有 resolution 和 duration。复现脚本现在默认 audio: false，要声音得显式写 --audio true。

二、`resolution` 不是清晰度开关，是像素预算 —— 而且默认 1080P

文档里这句话值得读两遍：

模型根据选择的分辨率档位，自动缩放至相近总像素，视频宽高比将尽量与输入图像 img_url 的宽高比保持一致。

所以选 720P 拿到的不一定是 1280×720。我们的输入是 4:3（1024×768），输出就是 1108×830 —— 91.96 万像素，和 1280×720 的 92.16 万几乎一样。它是「给够这么多像素，形状跟着你的图走」，不是「裁成 16:9」。

更要紧的是同一段文档的另一句：wan2.6-i2v-flash 的 resolution 默认值是 1080P。不写它，就按 1080P 的价钱算，哪怕你的输入图只有 1024 宽、根本喂不出真 1080P 的细节。

三、`duration` 是 2–15 的整数，不是 5/10 两档

网上关于图生视频的笔记很多写「只有 5 秒和 10 秒」，那说的是 wan2.6-i2v-us。flash 这一档的文档原文是：

取值为[2, 15]之间的整数。默认值为 5。

也就是说 7 秒、9 秒、13 秒都可以，单价按秒线性计费。做产品展示时，比「五秒切下一张」好看得多的用法是一张图 12 秒慢慢推，成本仍然是一秒一秒算的。

接口只有一个模式：异步

这个接口没有同步调用这一回事。请求必须带上 X-DashScope-Async: enable，否则直接报错 —— 原文是「HTTP 请求只支持异步，必须设置为 enable」，缺少这个头会返回 current user api does not support synchronous calls。

拿到 task_id 之后轮询，状态就六种：PENDING、RUNNING、SUCCEEDED、FAILED、CANCELED、UNKNOWN。UNKNOWN 不是「还没好」，是「任务不存在」 —— 任务 ID 只保留 24 小时，结果链接也是：

链接有效期 24 小时，可通过此 URL 下载视频。视频格式为 MP4（H.264 编码）。

所以「提交完先去干别的，回头再下载」这种做法，隔夜就失效了。脚本里轮询完成立刻落盘，不是洁癖，是必须。

复现

脚本在这个仓库里，零依赖，只用 Node 和 DashScope 的接口：

export QWEN_API_KEY=sk-...     # 或 DASHSCOPE_API_KEY
node scripts/wan-i2v.mjs \
  --image room.jpg \
  --prompt "slow cinematic dolly-in through the cozy renovated living room, gentle smooth camera motion, soft warm natural light, photorealistic, stable, no people" \
  --resolution 720P --duration 5 \
  --log run.json

默认 --audio false（省钱那档），要声音加 --audio true
图片直接读本地文件转 data URI，不需要对象存储，也不需要先把图传到公网
每 8 秒轮询一次，最多 40 次；超时和 FAILED 都会报错退出，不会留下一段空文件
跑完把 task_id、轮询次数、实际耗时、文件大小写进 run.json

我们那批素材的量测日志在 research/wan-i2v/measured-2026-09-22.json，每条片子都带 sha256，尺寸、时长、音轨、字节数都可以自己复算。

这四个参数的取舍

参数	默认	建议	为什么
`audio`	`true`（有声）	显式写 `false`	无声 720P ¥0.15/秒，有声 ¥0.3/秒，正好一倍
`resolution`	`1080P`	按输入图的实际像素选	720P 和 1080P 是 ¥0.15 / ¥0.25 每秒；输入只有 1024 宽时，1080P 是白付的钱
`duration`	`5`	2–15 的整数，按内容节奏选	按秒计费，镜头需要多久就给多久
`watermark`	`false`	保持 `false`	商用素材不该带「AI 生成」角标

这条链能做到哪、做不到哪

能做：把一张已经满意的静图变成有镜头运动的短视频，用于商品页、社媒、效果图转视频。成本是每条几毛到一块多。
不做：长视频、多镜头叙事（那是 shot_type: multi，另一档模型）、把糟糕的图救回来 —— 输入决定上限，模型只负责给它加运动。
一个真实的边界：我们这次是拿 AI 生成的效果图当首帧。真实照片同样可以，但房间的结构、透视关系会跟着动，出现金属反射、灯光逻辑错误时，多半要减小运动幅度重跑，而不是加大提示词。

五秒的镜头，成本七毛五。这个价钱意味着可以为每个风格各出一条，而不是精挑细选只做一条 —— 营销素材的供给量，比单条质量更容易做出差别。

证据

图生视频接口只支持异步调用：请求必须带 X-DashScope-Async: enable。 — https://help.aliyun.com/zh/model-studio/image-to-video-api-reference
缺少异步请求头时接口直接报错，不存在同步等待视频的用法。 — https://help.aliyun.com/zh/model-studio/image-to-video-api-reference
resolution 决定的是总像素预算，输出宽高比会尽量跟随输入图，而不是固定裁成 16:9。 — https://help.aliyun.com/zh/model-studio/image-to-video-api-reference
wan2.6-i2v-flash 的 resolution 可选 720P / 1080P，默认值是 1080P（也就是贵的那一档）。 — https://help.aliyun.com/zh/model-studio/image-to-video-api-reference
wan2.6-i2v-flash 的 duration 取值是 [2, 15] 之间的整数，默认 5 秒，而不是只有 5 秒和 10 秒两档。 — https://help.aliyun.com/zh/model-studio/image-to-video-api-reference
audio 的默认值是 true，也就是默认输出有声视频；想要无声必须显式写 false。 — https://help.aliyun.com/zh/model-studio/image-to-video-api-reference
官方文档写明 audio 直接影响费用，有声与无声按不同价格计费。 — https://help.aliyun.com/zh/model-studio/image-to-video-api-reference
结果视频的下载链接只有 24 小时有效期，格式为 MP4（H.264 编码）。 — https://help.aliyun.com/zh/model-studio/image-to-video-api-reference
异步任务的状态枚举包含 PENDING、RUNNING、SUCCEEDED、FAILED、CANCELED 和 UNKNOWN，其中 UNKNOWN 表示任务不存在而非尚未完成。 — https://help.aliyun.com/zh/model-studio/image-to-video-api-reference
北京地域 wan2.6-i2v-flash 按输出秒数计费：720P 有声 0.3 元/秒、无声 0.15 元/秒；1080P 有声 0.5 元/秒、无声 0.25 元/秒。 — https://help.aliyun.com/zh/model-studio/model-pricing
1024×768 的输入图，在 720P 档位下产出的是 1108×830（91.96 万像素，与 1280×720 的 92.16 万相当），印证了「相近总像素 + 跟随输入宽高比」。 — https://raw.githubusercontent.com/wangsheng1991/content-engine/main/research/wan-i2v/measured-2026-09-22.json
我们那批片子每条都带 AAC 立体声音轨，因为当时的请求没有传 audio，默认按有声生成（并计费）。 — https://raw.githubusercontent.com/wangsheng1991/content-engine/main/research/wan-i2v/measured-2026-09-22.json
量测出的成片时长是 5.007 秒，与请求的 5 秒一致。 — https://raw.githubusercontent.com/wangsheng1991/content-engine/main/research/wan-i2v/measured-2026-09-22.json
复现脚本每 8 秒轮询一次，最多 40 次。 — https://raw.githubusercontent.com/wangsheng1991/content-engine/main/scripts/wan-i2v.mjs
复现脚本显式发送 audio: false，不把「贵一倍」交给服务端的默认值。 — https://raw.githubusercontent.com/wangsheng1991/content-engine/main/scripts/wan-i2v.mjs

一张照片进去，几秒后出来一张能用的效果图

上面那条链的起点，是渲见（RenVi）里最常见的一个动作：把家里的房间照片传上去，选一个风格，等几秒。效果图满意了，再往「变成镜头」这一步走。视频只是素材的一种形态；真正决定转化的是第一张图好不好看、要等多久。

上传房间照片，免费出一张效果图: https://www.houseplusplus.com/?ref=wan-i2v-first-frame

SHARP：单张图的秒级 3D 高斯视图合成

LeGo build — Tue, 22 Sep 2026 09:48:32 +0000

单目视图合成要解决的问题很直接：给你一张照片，生成它附近视角的新画面，而且要看起来像真的。难的地方在于，一张照片没有视差，深度、遮挡、反射都缺信息。此前的做法往往要在「更真」和「更快」之间做取舍。

Apple 的 SHARP 给出的答案是把取舍绕开：不一步步重建场景，而是让神经网络把整张照片直接读成一份 3D 表示。

SHARP 在做什么

按官方仓库 README 的描述，SHARP 接收一张照片，回归出这个场景的 3D 高斯（3D Gaussian）表示参数。整个过程是一次神经网络前馈，在标准 GPU 上耗时不到 1 秒。生成的 3D 高斯表示随后可以被实时渲染，输出附近视角的高分辨率写实图像。

README 还提到两点对开发者很关键：

第一，这个表示是 metric 的，带绝对尺度，因此支持米制相机运动——你给出的相机位移是有物理单位的，而不是一个随意缩放的相对量。

第二，坐标约定遵循 OpenCV（x 向右、y 向下、z 向前），而 3DGS 场景中心大致位于 (0, 0, +z)。这意味着把 .ply 交给第三方渲染器时，需要自己缩放和旋转，把场景重新居中。

按 README 的描述，整个过程不针对单个场景做迭代优化，而是一次前馈就把参数吐出来。这一点对工程上的意义很直接：推理路径短，你不需要为每张新图重新跑一轮训练式的流程。

关键数字一览

维度	此前最佳模型	SHARP
LPIPS	README 未给出绝对值，作为对比基准	相对降低 25–34%
DISTS	README 未给出绝对值，作为对比基准	相对降低 21–43%
合成耗时	README 未给出绝对值，作为对比基准	降低三个数量级；标准 GPU 上不到 1 秒
生成方式	README 未说明	单次前馈（single feedforward pass）
输出形式	README 未说明	3D 高斯泼溅（3DGS），`.ply` 文件，兼容公共渲染器
泛化能力	README 未说明	论文称具备跨数据集的鲁棒零样本泛化

表格里凡是 README 没写的，就空着，不替论文补数字。这些百分比描述的是相对此前最佳模型的改善幅度，不是绝对分值——LPIPS 和 DISTS 都是越低越好，所以「降低」是好事，但 README 没有给出绝对分值，这里也就不做换算。

从仓库到第一条预测命令

README 给出的上手路径很常规：建环境、装依赖、跑 CLI。

conda create -n sharp python=3.13
pip install -r requirements.txt
sharp --help

权重不需要手动准备：第一次运行时模型 checkpoint 会自动下载，并缓存在 ~/.cache/torch/hub/checkpoints/。如果你更想自己管理权重，README 也给了直接下载 .pt 文件的方式，再用 -c 参数把本地 checkpoint 指给命令。

真正的推理只有一行：

sharp predict -i /path/to/input/images -o /path/to/output/gaussians

输出目录里是 3D 高斯泼溅文件。如果你还想额外拿到一条相机轨迹的视频，加上 --render；也可以从中间结果出发单独渲染：

sharp predict -i /path/to/input/images -o /path/to/output/gaussians --render
sharp render -i /path/to/output/gaussians -o /path/to/output/renderings

适合谁用，以及现在还不能做什么

按 README 的描述，它的定位是「单张图进、附近视角出」：适合照片量少、没有多视角采集条件，但又想要可自由换视角画面的场景，也适合把已有图像资产快速转成可实时渲染的 3D 资产。因为表示带绝对尺度，涉及真实位移的场景也能对得上单位。

另一个按 README 可以合理推断的好处来自耗时：既然单次前馈不到 1 秒，这一步就有可能放进交互式流程里，而不用当成一次离线批处理任务。不过 README 没有给出吞吐、并发或显存方面的数据，真要拿它做线上服务，还是得自己压测。

局限同样来自 README，写清楚比夸大更有用：

高斯预测本身在 CPU、CUDA、MPS 上都能跑，但用 --render 渲染相机轨迹视频目前要求 CUDA GPU，也就是说只有 CUDA 机器能直接出视频；
gsplat 渲染器首次启动时初始化要等一会儿；
接第三方 3DGS 渲染器需要按上面的坐标系约定缩放旋转、重新居中；
README 把定量与定性评估都指向论文和项目页，本页只复述 README 与摘要里的数字，不做额外推断。

自己跑一遍

conda create -n sharp python=3.13
pip install -r requirements.txt
sharp --help
sharp predict -i /path/to/input/images -o /path/to/output/gaussians

把 -i 换成你自己的图片目录，权重会在首次运行时自动下载。如果你的目标只是先把手里图片的质量提上去，也可以直接在线试 AI 图像增强，不必先跑通本地环境。

证据

SHARP 通过单次前馈在标准 GPU 上以不到 1 秒的时间回归出场景的 3D 高斯表示参数。 — https://raw.githubusercontent.com/apple/ml-sharp/main/README.md
SHARP 产出的 3D 高斯表示可以被实时渲染，生成附近视角的高分辨率写实图像。 — https://raw.githubusercontent.com/apple/ml-sharp/main/README.md
该表示是 metric 的，带绝对尺度，支持米制的相机运动。 — https://raw.githubusercontent.com/apple/ml-sharp/main/README.md
实验结果展示了 SHARP 跨数据集的鲁棒零样本泛化能力。 — https://raw.githubusercontent.com/apple/ml-sharp/main/README.md
在多个数据集上，SHARP 相对此前最佳模型把 LPIPS 降低 25–34%、DISTS 降低 21–43%，同时把合成耗时降低三个数量级。 — https://raw.githubusercontent.com/apple/ml-sharp/main/README.md
预测结果是以 3D 高斯泼溅（3DGS）形式存放在输出目录中的可渲染结果。 — https://raw.githubusercontent.com/apple/ml-sharp/main/README.md
官方 CLI 的预测入口是 sharp predict，用 -i 指定输入图像目录、-o 指定输出高斯目录。 — https://raw.githubusercontent.com/apple/ml-sharp/main/README.md
模型权重在第一次运行时自动下载，并缓存到 ~/.cache/torch/hub/checkpoints/。 — https://raw.githubusercontent.com/apple/ml-sharp/main/README.md
高斯预测在 CPU、CUDA 和 MPS 上都能工作，但通过 --render 渲染相机轨迹视频目前需要 CUDA GPU。 — https://raw.githubusercontent.com/apple/ml-sharp/main/README.md
输出的 3DGS 遵循 OpenCV 坐标约定（x 右、y 下、z 前），场景中心大致在 (0, 0, +z)，接第三方渲染器时需要自行缩放与旋转来重新居中。 — https://raw.githubusercontent.com/apple/ml-sharp/main/README.md

图像的鲁棒表示已经有了，你的照片也可以先变清楚

SHARP 展示了一件值得记住的事：一张普通照片里，本来就藏着足够多的信息，只要有一个足够鲁棒的表示方式把它读出来。在你自己的照片上，最实用的第一步往往不是重建 3D，而是先把图像本身的质量拉起来。 DLSS 5 是一个在线 AI 图像编辑器，把手里已有的图画上传上去，就能试试我们的 AI 超分与画质增强。

上传图片，试试 AI 增强: https://www.dlss5nvidia.com/?ref=ml-sharp

DEV Community: LeGo build

From Photos to Brick Designs: 2D Mosaics, 3D Models, and Buildability

Many subjects, different design problems

A reproducible 2D baseline

The reproducible example

Four decisions that make the output inspectable

1. Normalize and sample the image

2. Treat transparency as an empty cell

3. Match colors in Lab space, then limit the palette

4. Export data as well as a preview

Where AI helps—and where it does not

The jump to a 3D proposal

Qwen-Image-2.1 on public prompts: the 4/7 was protocol, not capability

The short version

Round one

Where the gap actually comes from

Ablation: only the prompt changes

Do not treat 2K/40 steps as a cure

A second prompt set: 26 vertical prompts

Latency

Limitations — read these with the numbers

If you only want the verdict

Evidence

An ID photo spec table where every number carries the sentence it came from

What it solves

What a row actually is

Three rules

One: a figure whose sentence cannot be read does not enter the table

Two: a contradicting figure is not deleted — it stays, with the reason it lost

Three: a row with a single source is not shipped

Where the photo goes

What it does not do

Check it yourself

Evidence

Image-to-video in three parameters: how a 5-second clip costs twice what it should

我们实际跑出来的东西

一、audio 默认是开着的，价格正好翻倍

二、resolution 不是清晰度开关，是像素预算 —— 而且默认 1080P

三、duration 是 2–15 的整数，不是 5/10 两档

接口只有一个模式：异步

复现

这四个参数的取舍

这条链能做到哪、做不到哪

证据

SHARP：单张图的秒级 3D 高斯视图合成

SHARP 在做什么

关键数字一览

从仓库到第一条预测命令

适合谁用，以及现在还不能做什么

自己跑一遍

证据

一、`audio` 默认是开着的，价格正好翻倍

二、`resolution` 不是清晰度开关，是像素预算 —— 而且默认 1080P

三、`duration` 是 2–15 的整数，不是 5/10 两档