4
$\begingroup$

I see web browsers doing this all the time when the internet connection is slow, loading the JPEG images almost line by line from top to bottom. How is this done in practice? I experimented with several image decoding libraries in Rust for example and if I delete half the bytes in an JPEG file, they are not able to decode the image.

$\endgroup$
1
  • 1
    $\begingroup$ Some images are optimized for the web. This allows them to be downloaded interleaved. You can't do it with just any image. $\endgroup$
    – pmw1234
    Jan 14, 2023 at 20:42

2 Answers 2

4
$\begingroup$

Others have interpreted your question as being about “progressive JPEG”, but “line by line from top to bottom” is not how progressive JPEG appears. Progressive JPEG organizes the data in the file so that low-detail data (the average color of 8×8 blocks) is stored before the data required for higher detail. A slowly loading progressive JPEG will appear as a blocky image which then fills in with more detail. If the image is appearing gradually from top to bottom, then that is a non-progressive (“baseline”) JPEG image.

Both types of JPEG can be decoded incrementally, and that is what web browsers do. The reason you are seeing failures is because libraries for loading files of any format, not just JPEG, are often not designed to be able to perform loading of partial data.

The majority of applications for image decoding are loading from local disk, and are often non-interactive, so partial data loading is not a helpful feature for them. Furthermore, it is not uncommon for files to be unintentionally truncated (e.g. because a download or copy failed partway through), and in that case it is preferable to report an error (so that the application using the library can know the file is damaged) than to continue with an image missing data. (Of course, recovering what you can from damaged files is also a useful feature — but also not a common requirement.)

And, if a library does support loading partial data, it will almost certainly expect you to provide the data by some kind of streaming interface, rather than a truncated input (which would imply re-decoding the beginning of the file every time more data is available).

To solve your problem, you will need to find a library that does support incremental decoding, and use it in the appropriate fashion — or add support for it to an existing library, or write your own.

$\endgroup$
1
  • $\begingroup$ Thanks! This was a very useful explanation since so far I was led to believe that I could only use progressive JPEG files. I have managed to adapt the mozjpeg library to my needs. The library has the default behaviour of calling exit when it receives invalid files but this can be overridden. $\endgroup$
    – jhk999
    Jan 21, 2023 at 9:14
3
$\begingroup$

What you are referring to is called a "progressive JPEG" file. This is a property of the way the file was compressed file which allows its decompression to be done in stages, such that a less-detailed version of the image can be shown despite not having the entire file. This technology was originally invented for the early Internet, allowing slow dial-up connections to be able to display something during the several seconds it took to download the entire image. As such, if you cut off the back-end of a progressive JPEG, you can still get some version of the image.

So this is a property of the file, but it is also a property of the decompressor. Any JPEG decompressor can read a progressive JPEG file, but only those with special support can pull off the progressive display trick. And most decompressors don't bother these days. A JPEG decompressor with progressive support will likely have a special API for doing progressive JPEG decompression.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.