Adding support for blurhash #1490
Conversation
|
Blurhash will be the successor to dominant color, which you correctly identified. We will probably then phase out dominant color within the next year. This will also act as a replacement to the small thumbnails in the future see #812, which means that we will probably have to choose the regular thumbnail instead of the small one. Otherwise, this looks good to me! :) |
|
Ah didn't know this was already in the works. And it does look like thumbhash is better than blurhash. will get that working hopefully for this PR |
|
A while back I outlined this feature but haven’t had the chance to implement it yet. I wanted to provide more context about how I see this feature integrating into the software. If you identify any benefits of using BlurHash in this context, please feel free to share your thoughts! :) |
| return | ||
| try: | ||
| hash = blurhash.encode( | ||
| self.square_thumbnail_small.path, x_components=4, y_components=4 |
There was a problem hiding this comment.
square_thumbnail_small becomes redundant once thumbhash or blurhash is fully implemented, so use square_thumbnail instead.
Currently, we create white placeholders on the frontend, then update their color to match the dominant color upon receiving a paged response. Next, we use square_thumbnail_small, apply a blur effect, and display it as a temporary preview. Finally, the actual thumbnail is loaded for the timeline. Once thumbhash or blurhash is implemented, dominant color and square_thumbnail_small are redundant and will probably be removed in the future :)
This PR is adding support for blurhash, a way to make the loading UI even prettier.
Please note that this PR is a draft because, honestly, I'm not a python expert and need help from the community to get this production ready and working (not to mention I had problems getting this to run locally so I couldn't even verify this works as intended 🤣, so please go easy on me)
This PR is paired with LibrePhotos/librephotos-frontend#580 on the frontend