Thank you for finding that! The fact that it is not a problem with truncation points towards being caused by skipping scans when decoding, e.g. displaying the 7th scan on top and the 1st scan (DC only) on the bottom, perhaps this has something to do with what coef_bits_latch stores.

It's probably expected behavior, the result of not enough information yet being decoded to support block smoothing. I'll investigate, though.

The app has a couple of options:

• "partial load, multi pass" - This loads the image at 2g speeds and stops at a particular byte
• "partial load" - This loads the image as fast as possible and stops at a particular byte

Only the former recreates the bug. I think this is because multiple scans are rendered in the former, but not the latter. The latter produces the same partial image, but without the blockiness. Given that they're working with the same amount of data, I think something else is going on here.

To illustrate the above, here's what it looks like when the image downloads at ~2g speeds and stops at 45625 bytes (resulting in many render passes):

Whereas here's what it looks like when the browser receives all 45625 bytes at once (resulting in one render pass):

OK, well, in that case, someone else needs to investigate it and figure out whether it's actually a bug in libjpeg-turbo. It takes a while for me to dig into these block smoothing issues, and since the specific funding for that feature has been exhausted, I'm not willing to spend any of the General Fund on this unless it can be shown to be a legitimate issue.

The first variation where no interpolated AC coefficients are preserved for area which did not receive any AC coefficients seems like a bug that likely could be fixed.

The second image is more complicated.

My possibly flawed understanding of this:
The smoothing correctly and beautifully computes new virtual AC coefficients from the DC. This forms a consistent image.

When some actual AC coefficients are loaded, they don't make a consistent image neither together with the virtual AC coefficients, nor when the virtual AC coefficients have been replaced by zeros. Another strategy would be needed to get a consistent image at that stage.

Two possibilities to fix this come to mind:

1. smoothing the image at such situations. Smoothing in pixel space is a lot more computation, i.e., deployments would have more performance risk, particularly so on low powered devices.

2. wait before redrawing the image until a sufficient amount of coefficients have been delivered. The heuristic for delaying the second draw could be something like at least 14 AC coefficients have been send with no more than 2 bits missing from them (I'm just guessing, didn't do actual testing if this leads to better perceived quality than the initial smoothing guess). Another visually solid alternative would be to wait for the second draw until all but last bit of all AC coefficients has been sent.

Intuitively 2) will be easier to implement in real-life systems.

The other piece of information I need with regard to this issue is whether it also exists in libjpeg-turbo 2.0.x. I am still not convinced that it is a bug, and you'll probably observe that the behavior in libjpeg-turbo 2.0.x is worse, but it's still a good data point to have.

This issue has been languishing for over a year. Can anyone provide any additional details on it?

Thanks for bringing this up again! I don't have time to look at it right now, but plan to do is in the coming months.