Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The site doesn't state this, but https://jpeg.org/jpegxl/ says:

JPEG XL further includes features such as:

- animation

- alpha channels

- layers

- thumbnails

- lossless and progressive coding

I wonder if progressive loading can halt loading (network I/O) at certain resolutions. This would remove the need of img-sets.

Edit:

Interesting talk at https://www.youtube.com/watch?v=t63DBrQCUWc and https://www.youtube.com/watch?v=RYJf7kelYQQ

Esp. the "visual target" instead of "technical target" when deciding the encoding quality. Also, the lossless and reversible transcoding from JPEG, GIF and PNG.



>I wonder if progressive loading can halt loading (network I/O) at certain resolutions. This would remove the need of img-sets.

Yes, not resolution but predetermined quality levels.


I was playing with progressive PNGs, and with an "intelligent" web server, it's possible to halt image transmission (either temporarily or permanently) at a server-decided quality level.

Here is a demo, which uses the different resolutions to create a pseudo-animation:

https://www.da.vidbuchanan.co.uk/adamation/image.png

It would be theoretically possible to write a server with a "give me the next quality level now" API endpoint, to enable the client to signal that it's ready for the next resolution.

This is far too janky to be used in production, but at least its fun.


Interesting, but doing it server side can screw up CDNs (which are quite important for images). It's better if the client takes care of that, so CDNs can cache the full image.


There has to be some incoming header / query param to indicate the resolution the browser is asking for in order know when to stop delivering bytes, so that can be used to vary the CDNs cache key.


I believe it can also resume from where it left off, if you click a thumbnail to get a closer look.


I guess you trade responsiveness for 'on-demand' data transfers. I would guess that the moment you click the button is too late to resume the loading.

Otoh the low-res thumbnail might be just enough to show as a (big) placeholder to bridge the (short) loading time to bring the image to a resolution that the user won't notice a difference.

(brain off ... can't write coherently ...)


I think, though I don't know how good the actual support is, that you can start the download from an arbitrary point so if you already have the thumbnail, you only need to download from that point on. If you are 80% sure people are going to click on the link to zoom, you could preload medium and then only load the final quality after they click.

One of the surprises of progressive loading, and why it's so good that JPEGXL has it, is how quickly you get to "good enough" and showing that before you get all the way to perfect.


What about meta-data?


The usual XMP and Exif metadata are supported in the file format, as well as JUMBF extensible metadata. It can optionally be Brotli-compressed too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: