What It Does:
1. Real LEGO colors with perceptual matching (Delta-E CIE2000, not basic RGB).
2. One-click exports to BrickLink XML or Rebrickable CSV or PDF building guide.
3. Works with official sets (31197, 31198, 31202, etc.) or all standard colors.
4. Interactive editing: pin tiles, swap colors, preview changes.
It is hosted on free Hugging Face CPU, so it can be slow. For faster processing,
install locally: pip install legopic
I vibe-coded it over the weekend. Figured others might want it too.
I’m a pretty light LEGO user myself and didn’t even know this existed. I imagine
there are others who also just want something quick and dirty instead of installing
a full app. And since it’s open source, it’s more of a fun side project anyway.
What It Does:
1. Real LEGO colors with perceptual matching (Delta-E CIE2000, not basic RGB).
2. One-click exports to BrickLink XML or Rebrickable CSV or PDF building guide.
3. Works with official sets (31197, 31198, 31202, etc.) or all standard colors.
4. Interactive editing: pin tiles, swap colors, preview changes.
It is hosted on free Hugging Face CPU, so it can be slow. For faster processing,
install locally: pip install legopic
I vibe-coded it over the weekend. Figured others might want it too.
Feel free to comment here or open a GitHub issue!
Besides that this feature already exists in Bricklink Studio, I could be more
enthusiastic if your approach would solve the two main shortcoming of most mosaic
programs I have seen:
(1) it should use error diffusion techniques, such as Floyd-Steinberg dithering.
For photo realistic images, this is very relevant to get nice looking results.
(2) it should not reduce the palette before it starts looking for available bricks.
For dithered images, you'd end up with mostly 1x1 tiles; for gradients, you'd
end up with color bands.
Judging from your sample outputs (especially from the portrait), your vibe coded
app does neither of the above.
If you don't want to end up with mostly 1x1 tiles, you'd have to combine
your color reduction (*), your error diffusion (**), and your available parts
logic (***) into one loop. If you can do that, you may have found yourself a
fan.
*) Color reduction is how you get from RGB or similar to your LEGO-color palette
index.
**) Error diffusion is if you placed a red tile in pixel one, but really needed
something a bit more orange ("the bit more" is what we call "the
error" that would trigger pixel two to lean more towards orange, which may
result in the second tile becoming orange, more so than that pixel actually needed,
and so on. Part of the 'error' is propagated to the cell to the right,
but also some to the cells below, to minimize 'color bleeding'. These
algorithms are well known and used in image processing software that handles
the color reduction to palette colors.
***) Available parts logic could handle just knowing about which LEGO shapes
exist, or could be more advanced like knowing about the pricing or which parts
you already have available. Ideally, the weighing algorithm that handles the
color reduction process, should have room for a weight that relates to this pricing/availability.
As a bonus, one could think of incorporating parts with a different texture,
like the grill tiles, masonry bricks or studded/non-studded, and thus not only
mapping the best matching color, but the best matching overall appearance for
that cell.