Replies: 3 comments 15 replies
-
|
It's been raised on Komga: gotson/komga#1098 |
Beta Was this translation helpful? Give feedback.
-
|
OPDS-PSE mandates the use of jpeg, gif or png images, see here:
I agree with you that this is outdated, and we need a better way to handle that.
I don't think the setting should be at the server level, but needs to be baked in the OPDS-PSE protocol, and the client should be allowed to request In Komga, when using the REST API, clients would typically:
We can't really do that with OPDS-PSE, because the OPDS-PSE link only provides a single mediatype for the whole publication, while each page could be using a different mediatype. One way of doing it would be to use Content Negociation. |
Beta Was this translation helpful? Give feedback.
-
|
I think we need to move this discussion over to https://github.com/opds-community/specs where the official spec lies. The goal isn't to maintain our own spec just for the readers, but to keep everyone in alignment. |
Beta Was this translation helpful? Give feedback.
-
|
They actually host a monthly call that's public invite. Might be beneficial for moving the spec forward for people to attend. This is probably also a better place for the discussion: https://github.com/opds-community/drafts/discussions |
Beta Was this translation helpful? Give feedback.
-
|
Content negotiation is an elegant HTTP-based solution to this problem, but it requires an extra round trip:
If you add other potential hints and properties such as height/width/resolution, it doesn't necessarily scale that well. My advice would be to look for inspiration in the IIIF Image API specification, move to OPDS 2.0 and define an updated URI template and list of hints embedded in This could look something like that: {
"rel": "http://vaemendis.net/opds-pse/stream",
"href": "https://example.com/opds-pse/xyz{?page,height,width,format}",
"templated": true,
"properties": {
"maxHeight": 1600,
"maxWidth": 1200,
"supportedFormats": ["image/webp", "image/jpeg", "image/png", "image/gif"]
}
}You'll notice that I've skipped the number of pages in those hints. This is potentially redundant with what can be expressed in OPDS 2.0 with the following metadata: https://readium.org/webpub-manifest/contexts/default/#duration-and-number-of-pages |
Beta Was this translation helpful? Give feedback.
-
We are not talking about forking any spec here. It would create a version 2.0 of the OPDS-PSE, that's not forking anything, given we maintain the OPDS-PSE now.
if i read that correctly, i think it requires at least one link to be gif/png/jpeg, but it should allow for other kind of media type.
That's probably something we need to discuss with @HadrienGardeur, to understand whether something like page streaming could be located there or not. I am all in favor of moving that unofficial spec to something official if we can.
Content negociation can work in 2 different ways:
|
Beta Was this translation helpful? Give feedback.
-
|
Proactive negotiation can avoid a round trip as long as you accept the risk that the server might not be able to reply with your preferred media type. This risk is mitigated when a long list of media type is specified, which is the case with your example @gotson. Knowing in advance what the server can return remains useful even in that case, since it allows the client to adapt what they send in their With this mixed approach, you could drop the media type from the URI template: {
"rel": "http://vaemendis.net/opds-pse/stream",
"href": "https://example.com/opds-pse/xyz{?page,height,width}",
"templated": true,
"properties": {
"maxHeight": 1600,
"maxWidth": 1200,
"supportedFormats": ["image/webp", "image/jpeg", "image/png", "image/gif"]
}
}
The spec requires specific media types for the cover of a publication (and IMO we should extend this requirement to WebP/AVIF) but it doesn't say anything about the content of the publication itself. In this case, using WebP or (even better) AVIF would be perfectly acceptable. Going beyond a URI template based approach to stream comics/manga, the Divina profile of RWPM only requires a bitmap format and doesn't list specific ones. While Divina remains a work in progress, it has several benefits over a single URI template:
It would be very interesting to discuss Divina between both of our communities (Readium and Anansi-Project) since Divina could IMO cover the use cases for OPDS-PSE and ComicInfo.xml at the same time. |
Beta Was this translation helpful? Give feedback.
-
Unrelated to this issue, but I have books that are made of more than one type of image, and I'd be happy to see the "type" attribute go away because I know that sometimes the server isn't truthful with the client about what to expect. |
Beta Was this translation helpful? Give feedback.
-
|
We all agree that the current way of doing this is not optimal, my proposal should tackle this. |
Beta Was this translation helpful? Give feedback.
-
|
In OPDS 2.0, the If the server allows transcoding on the fly, that's not an issue anyway. But if you want to simply stream content "as-is", moving away from a URI template based approach would allow you to provide such info along with other useful metadata. |
Beta Was this translation helpful? Give feedback.
-
A user recently contacted Panels support to see if we could do something to speed up their streaming by tweaking how Panels pre-cache pages.
Apparently, their whole library of comics is in WebP format, and it takes some time to get the pages converted to jpeg.
I still need to find out what server they're using.
Panels already has support for WebP, and it's a waste of resources to convert each page on-the-fly when a client has support for the original format. It would also speed the streaming up.
Does it make sense to have an opt-in feature to allow servers to return the WebP image and skip the conversion?
I don't have a specific solution in mind. I'm just testing the water.
What do you think would be a good approach?
Beta Was this translation helpful? Give feedback.
All reactions