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.
<link type="image/jpeg" rel="http://opds-spec.org/image/thumbnail" href="/opds/v1.2/books/09ZF85SYB236B/thumbnail"/>
<link type="image/jpeg" rel="http://opds-spec.org/image" href="/opds/v1.2/books/09ZF85SYB236B/pages/1"/>
OPDS spec defines them as such:
5.2.2. Artwork Relations
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: 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.
Tried opening up an issue request over there.
Thanks for looking into this.
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
I hope that makes sense.
In my case, I only really care about the Reading Now (and the IOS widget), so I’d be happy with that.
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.
Just wanted to say that it looks absolutely fantastic now. I think you must also be using the higher-resolution image for the widget.
Great list of features in this TestFlight release!
Thanks!! I’m glad you’re happy with it. Yeah, the widget uses the highest resolution possible.