dweb-search-frontend
dweb-search-frontend copied to clipboard
ipfs-search
Thumbnails
@dokterbob We should receive the thumbnails from the API. Ideally hosted over IPFS ^_^. Do you move that as a story to the backend?
@madnificent the front-end design would need to adapt to the back-end feature, so I think keeping this here would be useful.
@DonaldTsang Somewhat agree but I trust @dokterbob to re-open it on this backlog once the backend has a first version ready. I'm fine with it either way, it should be opened in the backend first and we need to keep track of it.
@ivan386 @dokterbob I would say anything smaller than 256px should be used as Thumbnail.
Given the backend implementation, it would be easiest to use the filesize. Perhaps we can use a single IPFS block as the criterium, as they will be fetched in one go: 256KB. Browsers are pretty good and efficient at scaling images nowadays.
Also a pretty smart idea: https://github.com/FLIF-hub/FLIF or https://github.com/cloudinary/fuif for progressively rendered thumbnail, such that it can take only the first N kilobytes of data to have an image resolution of 256px without the need of the other pieces of data.
@madnificent @dokterbob First block of progressive JPEG can be used as Thumbnail.
Example:
Full image
First block
But may be problems in firefox. It show white square in random times.
@ivan386 a very compatible solution, what about using WebP (VP8/VP9) or HEIF/HEIC/AVCI (x264/x265) or AVIF (AV1)? Does any of those support partial renderings? Or even Adam7 interlaced PNG?
I think using the original content as a thumbnail should be last resort. If we intend to build a search for thumbnails specifically, with a dedicated UI, then that would indeed be awesome. If we want to download the full content when the search results are being fetched then that would be awesome too (I think that was in one of the earlier v2 frontend releases). If we want to verify whether an image is sufficiently small to be used as an image, then I doubt it will have much success.
If we are generating the thumbnails ourselves, I'd personally prefer a simple and well understood format. We're trying to build thumbnails, not host the original content. If we generate thumbnails and place them in a shared IPFS folder with a name based on the original IPFS hash of the object, then they could easily be used by other projects too. That sounds super rad to me. Not sure if @dokterbob agrees.
Is a thumbnail service something that could be PRd into the current backend core @dokterbob or do you need a good oversight for that to happen correctly?
I'd love to run a thumbnail service, but it requires sharded directories for the proposed interface to work. I've been thinking about it and will continue to do so as we figure out more day to day issues.