Feature request: resize cover images

[Oreolek]

The cover images are height-capped at 225px. So instead of loading full-size covers (which can be quite large) calibre-web can load (pre-generated) small covers.

Webp format is also a possibility here.

[gelsas]

@OzzieIsaacs I just wanted to suggest that too.

If there are 60 books loaded each page then it takes quite some time for all images to load fast because of their size.

I would really love to see this feature. That would improve the loadtime by alot.

(On my kindle for example it takes "ages" to load all the images.)

[OzzieIsaacs]

One idea: Reduce the no of books on each page (admin-> view config-> on. Of books per page

[gelsas]

Sure changed it to 12 just now. Its faster but still quite slow. Is there any reason against having this suggested feature at some point in the future ?

[OzzieIsaacs]

No, it‘s just the ideas are rising with the no. of users. Another idea I currently also denied was lazy loading the pictures, so they are loaded if the browser is displaying the cover the first time. The pull request is still open, is it worth a try?

[gelsas]

Lazy loading is sadly very buggy on most ebook readers. Thats why in my opinion it is not the best solution.

But maybe there is a solution to still use the pull request with slightly changing it. Couldn't we just check what device is accessing calibre web via the user agent and only have lazyloading automatically enabled on desktops/phones/tablets but not on ebook readers ?

Just an idea. Let me know what you think about it.

[Shadowghost]

Anything new on this? My library is quite large (covers are always >225px) and fetching all covers takes ages on slower connections. Is there a reason why generating 225px thumbnails of the covers on their (global) first load isn't considered up until now? Lazyloading would surely help on smaller screens but won't do anything on normal screen sizes.

[OzzieIsaacs]

it‘s just the ideas are rising with the no. of users... I'm currently trying to implement all the filter stuff from several issues, and merging the other pull requests, refactoring the biggest file to be ready for the future. Please be patient, there are also issues which are way older which I haven't implemented yet.

[mmonkey]

@OzzieIsaacs I am working on a PR to address this.

PR will include:

• Configurable cache directory
• Image thumbnail creation when the image is loaded the first time
• Clear cache button per book and global (admin settings only)
• Cache cleanup when a book is deleted or a new image is uploaded

Other considerations:

• Image thumbnails will be generated at 2x the displayed resolution for high DPS screens (450px height)
• I will consider adding thumbnail quality options, but in the mean time I've done some testing with resample type and quality percentages to cover most use-cases.
• Once the PR is merged, docker images will need to be updated to add an addition volume for the cache directory
• If time permits, I will look into improving image loading timing. Currently the page wont load on mobile until all images are loaded (I believe).

Feedback requested:

• Should a local cache be used for book covers served by google drive?
• Should thumbnails be generated via a task instead of on page load?
• Should the cache mechanism be more robust? As in, should cache busting be triggered via a timestamp, in some sort of lockfile, instead of deleting the thumbnail via the filesystem? (my initial take: not really necessary)

I will be certain to capture page load metrics and include them in the PR.

[gelsas]

Lazy loading the images would help so it does not load all images

[mmonkey]

Lazy loading the images would help so it does not load all images

Good callout, perhaps lazy loading images can resolve:

If time permits, I will look into improving image loading timing. Currently the page wont load on mobile until all images are loaded (I believe).

That may also be a good candidate for a follow-up PR.

[OzzieIsaacs]

@mmonkey: That sound great, was planned to be one of my next projects, but I'm very happy if you implement it. I have the following comments: 1) Please create the PR for the development branch, I got rid of pillow there and everything only relates on imagemagick. The only thing broken there currently should be sorting shelfs (I'm currently working there) 2) Please try to avoid many settings, there are so much settings, you can look into the issues, several users asking for functions and options, because they don't find is, as there is so much and not everything is available with everything. So please no configuration option for the cache (if somebody thinks he needs it elsewhere he shall use a symlink). I'd suggest a sub directory of the cps folder (maybe static/covers folder is a good idea, we could bypass the wsgi server ... url_for("static", ...), haven't thought it trough 3) Clear cache button per book and global (admin settings only) -> global is a good idea, I don't know if it's really needed on a per book base. Please also consider to automatically delete the cache on a database directory change 4) Regarding quality options, please think on comment 2), on the other hand there is an issue about cover sizes on kobo reader which would require low quality cover pictures to make the Kobo reader to render books faster after download (see #1347) 5) Image loading lazy loading, there was a PR regarding this I closed it long time ago, as I didn't see benefit from it (#282)

Your questions: 1) Should a local cache be used for book covers served by google drive? Definitely locally, using google drive is a pain, you can go and drink a coffee while the first book covers are loading 2) Should thumbnails be generated via a task instead of on page load? I think yes, adding them to the queue in the background task is a good idea, otherwise (especially on slow computers or with google drive enabled you will wait very long for the initial generation) I was thinking on a table holding the cover cache covers and you could add books there on startup. Another thing to consider would be changing/adding books via calibre and automatically generating covers for new/changed books (I'm thinking on checking the timestamp of the books regular in a background task) 3) Should the cache mechanism be more robust? As in, should cache busting be triggered via a timestamp, in some sort of lockfile, instead of deleting the thumbnail via the file system? (my initial take: not really necessary) Not really sure about the question, as your thinking of implementing it different from my view. I would not delete the cache at any time without asked for it (the admin button, or if Calibre-Web realizes the file is gone)

[OzzieIsaacs]

Ah, and one final remark, there is a testing repro: https://github.com/OzzieIsaacs/calibre-web-test where we need to add some tests when we are finished

[mmonkey]

I'd suggest a sub directory of the cps folder (maybe static/covers folder is a good idea, we could bypass the wsgi server ... url_for("static", ...), haven't thought it trough

The cached image directory wouldn't really make sense under "static" perhaps we just add cps/cache. The cache directory should also be added to gitignore.

I was thinking on a table holding the cover cache covers and you could add books there on startup.

I hadn't considered adding a table for this. However, if generating thumbnails is a task, that may work best. What do you think the best approach would be to not create a task for every book on every startup? We don't need to re-generate thumbnails for ones that already exist. Like, would there be a query that gets all the book ids which then is used to query the new table for missing ids?

[OzzieIsaacs]

The cached image directory wouldn't really make sense under "static" perhaps we just add cps/cache. The cache directory should also be added to gitignore.

okay

I hadn't considered adding a table for this. However, if generating thumbnails is a task, that may work best. What do you think the best approach would be to not create a task for every book on every startup? We don't need to re-generate thumbnails for ones that already exist. Like, would there be a query that gets all the book ids which then is used to query the new table for missing ids?

Yes that was how I was thinking of it. I think this may should be done once per x minutes to check if somebody has changed a cover in the background. And don't worry, this won't be the first database overarching (?) query, it's a little one liner

[mmonkey]

Yes that was how I was thinking of it. I think this may should be done once per x minutes to check if somebody has changed a cover in the background.

@OzzieIsaacs I don't see a mechanism for scheduling tasks, am I missing something? If not, I was thinking of adding APScheduler.

I was thinking on a table holding the cover cache covers and you could add books there on startup.

What is the convention for registering things at startup? Like where in the code could the scheduling service be initialized / scheduled task be started?

Otherwise things are looking pretty good so far, and I am getting a feel for the project structure in general. My index page size went from 26Mb+ to just under 6Mb. I am looking forward to test the speed improvements for google drive mounted libraries!

[OzzieIsaacs]

The PR is merged:

• Please update to the newest nightly version
• Install APScheduler via pip
• Restart Calibre-Web
• Go into admin section enter edit schedule task settings, enable "Generate Book Cover Thumbnails", change the regular update time if you want (only needed for sideloaded books via Calibre), save setting
• go to admin section Click on Refresh Cover Thumbnnail cache
• Check Tasks section and wait some minutes until all thumbnails are generated

Enjoy

[ofostier]

Hello can we generate them manualy using a script (not from UI) ? My library got more than 100k books and is it is quiet long by UI way.