Loading NFTS takes too long

[daniel-soli]

When loading the 12 nfts on accountsdetail it takes way too long because it loads the full images. (This is actually from the collections page... Nice!)

Since nft's only holds the full images and not thumbnails, would it be a good idea to make a function app which takes all nft's and make thumbnails for them? It could be stored in blob. Yes, there are hundreds of thousand of NFTs, but could it be done?

Let's say a function app which runs once a day or something and picks up every nft made, makes a thumbnail version of it with the cid as name so it will be searchable on the blob. Blob searches are quite quick. And then we just use that image instead for the thumbnail.

If the thumbnail doesn't exist in blob we use the original image. And to start with, since we don't have any we would need to do a long running function collecting ever nft.

Just a thought :) Since it's taking way too long when loading nfts.

[modersohn]

Call me pessimistic, but I see loads of possible problems.

First the variety of file formats (animated GIF comes to mind), then the storage in general (have you got a link or better some code to see Azure Blob Storage in action? What if we end up generating several GB of data?) and then possibly issues with copyright or not being decentralised etc. etc.

Oh and looking at your screenshot (nice BTW, what tool/browser is that?) - it seems the graph QL data was already cached? Otherwise there would have been loads of re-renders, right?

[modersohn]

I just learned on discord, that the image URL we're showing in the overviews should actually be a low-res thumbnail (see https://wiki.ezl2.app/en/tips#metadata-basics). So in your screenshot above, the NFTs weren't minted correctly IMO.

[fudgebucket27]

I'm against this sorry.... There's so many things that can go wrong and adds complexity. FYI Loopring already processes each NFT and makes thumbnails for them and adds the thumbnails to their cloudfront cdn(though this can take hours upon hours depending on the size) . You can hit this API endpoint for example: https://api3.loopring.io/api/v3/user/nft/balances?accountId=40940&limit=50&metadata=true&offset=0

You can see the various thumbnails for the NFT in the following json properties

    "imageSize": {
                    "240-240": "https://d2y691019xyzhi.cloudfront.net/0f354ea05083ab8ed1ddf886cb979f434129165b29a1d68080b02f45f1e00336-240-240.png",
                    "332-332": "https://d2y691019xyzhi.cloudfront.net/0f354ea05083ab8ed1ddf886cb979f434129165b29a1d68080b02f45f1e00336-332-332.png",
                    "original": "https://d2y691019xyzhi.cloudfront.net/0f354ea05083ab8ed1ddf886cb979f434129165b29a1d68080b02f45f1e00336-original"
                },

If we can figure out how they generate the URL for the thumbnails we wouldn't need to host it ourselves

[daniel-soli]

I agree that my "solution" is absolutely not the best, was just the first thing that came to mind. And yes, there may be some copyright issues, although all nft's are already out there open for everyone. GB would not be an issue, blob storage are way cheap. But it's a bad solution anyway so...

I think the problem really is what @modersohn says, the image_url property is wrongly used by artist if that is ment to be a thumbnail. But I don't wanna be going to every artist and tell them to re-mint and do it by the books 😄

By what you are saying @fudgebucket27, the url's seems to be nftId + size. Could we simply put together the urls, do a quick check if it returns an image and show that instead? If we get 404 we show the original we already got?

Edit: Sorry, I guess I misunderstood what you meant by the already processes the images. Only if one "ask" for it it seems. They also use the original sized images on their explorer.

@modersohn : It's brave browser. I think all chrome browsers have the same developer tab. :)

[daniel-soli]

Will leave this issue open for future possible solutions.