upvote
Yes, but figuring out the "5% of the file or whatever" is the hard part!

Let's say JXL does progressive decoding by encoding the image as a checkerboard (it doesn't but for the sake of argument): First you send the average of each 8x8 block, then you send the adjustments needed for the 4x4 blocks within that, then you send the adjustments needed for 2x2, and then 1x1.

If the client knows that it is going to display the image at a low resolution, anything beyond 8x8 might be completely useless, so it would be valuable to know where the 8x8 section starts and the 4x4 section begins. Under-guess and you don't have all the data needed to display it, over-guess and you're fetching data you are going to throw away.

This makes it very useful if it is trivial to analyze the image to determine that, say, the first 5kB are needed for 500x500px display, the first 150kB are needed for 1000x1000px display, and the full 500kB for 2000x2000px and above - either to dynamically generate a <picture> srcset server-side, or to have the browser determine when to abort the fetch after parsing its header.

reply
Knowing where to truncate before you get there is related to the codec itself. Can I figure out where the quarter resolution data ends from the header alone?
reply