Large images about bd-comics-manga HOT 4 OPEN

I can't imagine that we can impose an emerging file format, as HEIF.
In order to get the desired effet (a long vertical strip, people reading sequentially from top to bottom), lazy loading of images seems a good trick. A look at google images or https://unsplash.com/ seems convincing enough to me.
Re. authoring, an explicit tiling like the one proposed by Frank would fit IMO.

from bd-comics-manga.

Regarding streaming do we really need something specific like HTTP live streaming (which means serving multiple resolutions, server specific settings and index files) intsead of a simple HTTP byte range?

If Apple and Google are truly pushing for these formats they should IMO follow a fairly standard behaviour. Large media files are usually streamed in a browser context using byte ranges.

from bd-comics-manga.

My preference would be to rely on existing bitmap formats and include alternate representations using the latest/upcoming image formats:

[
  {
    "href": "page1.jpg",
    "type": "image/jpeg",
    "alternate": [{
      "type": "image/heic",
      "href": "page1.heic"
    }]
  }
]

from bd-comics-manga.

I’d like to point out that memory is a technical issue which should probably be discussed if web browsers/views are involved at some point.

Browser vendors indeed tend to consider images a hidden cost (Apple even pointed that in a WWDC session) and what’s super important to them in the size of the image decoded in memory. Now, things can go insanely wrong in some cases (web browsers/view crashing, image not being entirely decoded on low-end mobile devices, etc.), which is why there are image sizing limitations in EPUB Readers for instance.

One of their advice is to not use “images larger than necessary”, which reminds me a lot of JS slideshows plugins/libs heavily rely on picture/srcset (responsive options being mapped to this spec), in addition to lazy-loading, which is not sufficient – it appears that in this case, if too many large images are to be displayed for instance, decoded images won’t necessarily be trashed as expected in browsers’ vanilla scrolled view.

In the case of JPG, PNG and GIF, the formula is width × height × 4. Don’t know what it is for HEIF or WebP but I guess it’s an issue worth-addressing early on if, once again, web browsers/web views end up involved at some point. That’s not necessarily an edge-case by the way (a significant amount of web articles with a lot of images/GIFs can crash iOS Safari for instance).

I can already imagine web browser vendors scream at the 1200px × 25426px images example, which would be 122 044 800 bytes each, decoded in memory – it would actually crash an iPad Mini 2 for instance. Which is also a reason why explicit titling is worth exploring.

So, for political reasons, etc.

from bd-comics-manga.