In the OPDS libraries, if I explicitly cache a book to my iPad using the “Download” menu item, the cover art is displayed in lovely crisp high resolution. However, for OPDS streamed books, it uses the lower-resolution thumbnail provided by the server. That makes sense if the book has never been opened, but would it be worth keeping the cover image in the cache once it’s been downloaded the first time through page streaming? I think most books download Page 0 almost immediately.
I don’t know how the caching process works for streamed books – that is, when the images finally get deleted – but if you could explicitly keep Page 0 around, at least as long as some other pages of the book are cached locally, it would sure be nice for the widget and “reading now” screens to show the higher-resolution images.
We did this once, and we had to revert it, unfortunately.
Downloaded files behave a bit differently from streamed comics. They are their own source of truth, and using the first page as the cover makes total sense. This is what everyone would expect.
But streamed comics from a server are trickier because the server might be using a different image for the cover in the feed. Some servers allow customizing the cover, which might not match the first page.
We implemented this to improve the Ubooquity and Substack integrations. Both return a very low-resolution cover.
It turns out that using the first page to replace the low-res cover sometimes resulted in showing the first page of the comic (not the cover).
I think Panels shouldn’t try to fix the server’s content because our assumptions might sometimes be wrong.
It would be better if servers could serve better-resolution images instead.
Would it make sense to use the “image” link rather than “image/thumbnail” if it’s present in the feed? In my server, it links to the full-size cover image, but it might only be true for Komga servers.
OPDS Catalog Entries may include atom:link elements to images that provide a visual representation of the Publication. For many Publications, these images will be the Publication’s artwork. This specification defines two Artwork Relations, which begin with http://opds-spec.org/image:
http://opds-spec.org/image: a graphical Resource associated to the OPDS Catalog Entry
http://opds-spec.org/image/thumbnail: a reduced-size version of a graphical Resource associated to the OPS Catalog Entry
However, I know that implementations vary wildly so it may not be useful to rely on its presence.
EDIT: It actually seems that although Komga sets the “image” and “image/thumbnail” links correctly for books without custom covers, it does not set them as expected for books with custom covers. Tried opening up an issue request over there.
Nonetheless, we can’t simply use the /image artwork instead of /image/thumbnail. There are no specifications nor restrictions on the size of the image in the OPDS specs. The /image artwork would weigh a few MB, negatively impacting the library’s performance.
Even if they fix the image in the feed, we would have to have sophisticated logic to determine when to use /image instead of /image/thumbnail to do this right. Something like downloading the thumbnail and measuring the resolution; if it’s below some threshold, download the /image one and resize it locally to ensure it’s not too heavy.
I still think having the servers return a higher-resolution image is better.
We can use the /image artwork in Reading Now. We don’t render many of those simultaneously, so it’s safer. At least that will make them look better in that case.
But for the library, where we show many thumbnails at the same time, I feel more comfortable using the /image/thumbnail instead.
Awesome. We can definitely do that. It shouldn’t be a huge lift so expect that improvement in the next release.
We might release a few Testflights before that change is done, but I can work on that soon.
