Preparing your workspace
● This section specifies how many pieces of each color you have available to create the image
● Color names are bricklink colors
● Step 4 of the algorithm cannot run unless you select enough pieces to fill the picture ('Missing Pieces' must be 0)
● If you're working with an existing set, then clear the available pieces and use the mix in option to add in the pieces from your set.
Required Pieces:Important: Infinite piece counts were used, since a linear error dithering algorithm was selected in the 'Quantization' section, or a variable piece type was selected in the 'Pixel Piece' section
Note: Any colors painted using the paintbrush are assumed to exist when infinite piece counts are enabled
| Color | Number Available |
|---|
● Click a pixel to increase its height
● Click a pixel to decrease its height
Below is a recording of my tech talk from BrickCon 2021
If you're interested in understanding how this site works, the talk goes over the techniques and algorithms that were used
It also goes over some ideas that haven't (yet) been implemented within the tool, so it functions fairly well as a more general overview of the brick mosaic space
You can find the slide deck used in the talk here (with some updates since the talk), and if the video doesn't load, you can find it directly on BrickCon's YouTube channel here
These are some other articles and videos featuring DooPixel Pixel Art Maker
Some are quite interesting even outside the context of this tool in particular, since they go into the history of brick mosaics
Note that some were made when the tool was older
DooPixel Pixel Art Maker lets you upload your own image and turn it into brick pixel art. The tool matches your image to available brick colors, then creates a parts list and building guide for the design.
DooPixel is an independent brick pixel art tool.
The computer vision techniques used are pretty inexpensive (with the exception of optional depth map generation), 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, apart from depth map generation, 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. This also makes it much easier for me to maintain and host. The only server code consists of simple increments to anonymously estimate usage for the purposes for tracking performance in case the static deployment needs to be scaled up, and for the counter in the about section.
Even the deep neural network to compute depth maps is being run entirely within the browser, in a web worker, using a modified version of ONNX.js. I've compiled a version of the library based on this pull request, with a small additional change I made to support the resize operation in v10. The model used is MiDaS - more specifically, the small ONNX version which can be found here.
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.
Note: No user data is stored, so this is just aggregated info based on simple increments
| Date | Images created |
|---|