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?
Top comments (0)