<p>What you are referring to is called a &quot;progressive JPEG&quot; 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.</p>
<p>So this is a property of the file, but it is <em>also</em> 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.</p>

CC BY-SA 4.0
2023-01-15T02:02:05.100Z
2023-01-17T02:42:27.950Z
2023-01-17T02:42:27.950Z
Nicol Bolas
<p>Others have interpreted your question as being about “progressive JPEG”, but “line by line from top to bottom” is <em>not</em> 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 <em>non</em>-progressive (“baseline”) JPEG image.</p>
<p><strong>Both types of JPEG <em>can</em> be decoded incrementally,</strong> 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 <em>often</em> <strong>not designed to be able to perform loading of partial data.</strong></p>
<p>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 <em>also</em> a useful feature — but also not a common requirement.)</p>
<p>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).</p>
<p>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.</p>

CC BY-SA 4.0
2023-01-21T09:14:10.797Z
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.
jhk999
CC BY-SA 4.0
2023-01-20T18:07:19.187Z
2023-01-20T18:07:19.187Z
Kevin Reid
<p>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.</p>

CC BY-SA 4.0
2023-01-14T20:42:10.253Z
Some images are optimized for the web. This allows them to be downloaded interleaved. You can't do it with just any image.
pmw1234
<image-processing>
How to decode a JPEG file which is not fully loaded yet?
jhk999
# How to decode a JPEG file which is not fully loaded yet?

(Asked by: username_0 on 2023-01-14)

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.

**Tags:** image-processing

> **Comments:**
> **username_1**: Some images are optimized for the web. This allows them to be downloaded interleaved. You can't do it with just any image.  

---

## 2 answers

### Answer by username_3 on 2023-01-20. Score: 4 | Accepted answer

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.

> **Comments:**
> **username_0**: 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.  

---

### Answer by username_2 on 2023-01-15. Score: 3

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.


---

