I’ve been working on a digital art collection that generates 6x6 pixel images from source pictures. Unlike algorithmic art that can be recreated through code, my images need their actual pixel data stored directly on the blockchain to make them truly on-chain NFTs.
I’m pretty new to blockchain development but I understand the basic concept of NFTs. I’ve minted some pieces on various platforms before, but I want to understand how artists like deafbeef manage to embed their artwork data directly into smart contracts rather than just storing metadata that points to external files.
Since my images are small pixel art pieces, storing them on-chain seems feasible, but I’m not sure about the technical implementation. What’s the best approach for converting pixel data into a format that can be stored in a smart contract? Are there any good resources or tutorials that explain this process step by step?
I worked on something similar last year and hit several technical issues you should know about. The main problem is that even 6x6 pixel art needs careful color encoding. Each pixel needs RGB values, so you’re looking at roughly 108 bytes minimum per image with 8-bit color channels. I ended up using a custom palette system - predefined 16 colors and stored only the palette index for each pixel. This cut storage way down compared to full RGB values. You can implement this in your contract’s constructor or use a separate mapping. For the technical side, store the pixel data as bytes in your contract and use the tokenURI function to build a data URI with base64 encoding. The tricky part is handling image generation efficiently without hitting gas limits during minting. One thing that caught me off guard - storing data directly in contract storage costs way more than using contract code storage. Consider CREATE2 with deterministic addresses if you need to optimize costs further.
hmm, deafbeef uses base64 for pixel data in contract metadata. for your 6x6 art, try RGB in hex or data URIs. also, check ER721, you can override tokenURI to send that base64 img insted of IPFS. could be high gas but should work for small imgs!
This sounds like a really cool project! How are you generating these 6x6 pixel images from source pictures? Custom algorithm or existing tools?
I’ve been messing around with on-chain storage too. You’ll probably want base64 encoding for your pixel data. Since 6x6 is only 36 pixels, gas costs shouldn’t be too bad compared to larger artworks.
What format are you thinking? SVG data strings or bitmap data? I’ve seen projects use SVG because it’s more compact and scalable, but pixel art might need that crisp pixelated look.
What’s your source material like? Photos, paintings, other digital art? The concept sounds fascinating - I’d love to hear more about your creative process.
Even though 6x6 seems small, test gas costs on testnet first before mainnet. Storage operations get expensive fast, even with small data!