I’m working on a project where I need to include picture files (like .jpeg or .png images) as part of my NFT’s metadata structure in Scrypto. I’m not sure about the right approach to handle this kind of data.
Should I convert the image into some kind of numeric format? Maybe use a Vector or BTreeMap to store the binary data? Or is there a better data type in Scrypto for handling file content?
I’ve been thinking about different options but I’m confused about which one would work best for storing actual image data inside the NonFungibleData struct. Any suggestions on the most efficient way to do this?
hey @SingingSnow! really interesting question - I’ve been curious about this stuff too.
Are you planning to store the actual image data on-ledger? That’ll get expensive fast with transaction fees and state bloat, especially for larger images. A 2MB jpeg stored directly in NFT metadata could cost a fortune.
What’s driving the need to put image data inside the NonFungibleData struct instead of just storing a reference or hash? Need it completely immutable and on-chain for some reason?
I’ve seen projects use a hybrid approach - store a cryptographic hash of the image in metadata with a content identifier, but keep the actual image data in distributed storage. Maybe your project’s different though?
What size range are we talking for these images? Need to reconstruct the exact original file, or would compressed representation work?
Trying to understand the full picture since the “best” approach depends heavily on these factors!
I hit this same problem last year. Tried storing raw image data in NonFungibleData using Vec - technically works but becomes a nightmare fast. It’s not just expensive, it kills performance. Every transaction with that NFT crawls because it loads all the data. I tested a 500KB PNG once and the network straight up rejected it. What actually worked: store a SHA-256 hash of the image plus basic metadata (dimensions, file type, timestamp) in the struct. Keep the real images on IPFS and use the hash for verification and lookup. Clean and fast. If you’re dead set on on-chain storage, try chunking - split images across multiple resources with an index to tie them together. More work to code but you get true decentralization without hitting size limits.
totally agree! u def dont wanna blow ur budget on massive images. ipfs links r way smarter! spliting into chunks can help but it’s more complex. unless ur use case demands it, keep it simple with hashes for sure. savings in the long run!