Supported image formats are dependent on your browser's compatibility
Due to the nature of the Lego Art sets, images with transparency aren't supported
| Color | Number Available |
|---|
Some sets use 1x1 tiles, while others use 1x1 studs. Make sure you double check before continuing if you want consistent pixels in your result.
Depending on the input set of studs, many images don't easily translate to the available color palette. Try to use an image with similar colors to those of the set of studs you have available.
In some cases, adjusting the colors in step 2 can help greatly, but this doesn't work for many source images. For more robust color adjustments, I recommend making the changes in another tool before remixing the image.
Depending on your hardware and the resolution you've chosen, the pdf can take quite a few seconds to generate. Be prepared to wait if you're generating instructions for larger resolutions. Larger resolutions may also cause some slowness on the page or may not work at all on lower powered devices, so I recommend starting at the default and then going up.
TipIf there is a significant loss of color quality between steps 3 and 4, then the set you're using is running out of studs. If you're willing to sacrifice resolution for color accuracy, then changing the resolution in step 1 can help by reducing the number of studs required.
Supported image formats are dependent on your browser's compatibility
Due to the nature of the Lego Art sets, images with transparency aren't supported
In 2020, The Lego Group released the Lego Art
theme, which allows people to create a predetermined image using lego studs.
Lego Art Remix lets you upload your own image, and then uses computer vision to use the
studs from a Lego Art set that you already have to recreate the image.
This project is not affiliated with The Lego Group
The computer vision techniques used are pretty inexpensive, and the resolutions being dealt with are naturally quite low, so as of the time of writing, the algorithm runs quite quickly. This allows for it to be run on the client, and on the machines that I tested, it ran in near real time.
The most computationally expensive part of the process is generating the instructions, since even pdf generation is done client side.
Since it runs almost entirely within the browser (see the source code), no image data is sent to a server and so it's very secure. The only server code consists of simple increments to count how many images were generated, for the purposes for tracking performance in case the static deployment needs to be scaled up.
As of the time of writing, I don't have all of the sets, and I haven't had much time to test. As a result, there's probably a few bugs, so let me know if you find any.
Algorithm improvement ideas are always welcome. Improvements that maintain the efficiency to within a reasonable degree would allow the algorithm to keep running on the client, which I really like. That being said, putting in the work to add a server side computation option would allow for more complex approaches (such as constrained VAEs, etc.).