New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 2821 link

Starred by 5 users

Issue metadata

Status: New
Area: ImageDecoder
NextAction: ----
Priority: Low
Type: Defect

Blocked on:
issue 3315
issue 3257

Sign in to add a comment

Incomplete, progressive JPEG image appears black when opened

Reported by, Aug 11 2014

Issue description

What steps will reproduce the problem?
1. Copy the attached image to the device
2. Open the image

What is the expected output? What do you see instead?
View the image properly. Black/grey image displayed.
If the image is corrupted, a message should be displayed informing the user

What version of the product are you using? On what operating system?
Nexus 5 (Android 4.4.4)

Please provide any additional information below.
Suspect a jpeg image decoding issue

49.3 KB View Download
Project Member

Comment 1 by, Aug 11 2014

Reproduced on 4.4.4, Moto X, although when accessing the file, prior to download, I did get an "unable to access document" error where I normally get to view the jpeg, so the system reported something was wrong with the file.  (I could still force the download, open with gallery and make the black display happen.)
Project Member

Comment 2 by, Aug 11 2014

Labels: -Priority-Medium Priority-Low
Confirmed code is reporting decoding issue.  Hal helped out with some quick libjpeg analysis/testing, seems to work on Linux/Mac viewers use of libjpeg, with Chrome's use of libjpeg-turbo, but the version of the library we pull in (or our use of it).
Project Member

Comment 3 by, Sep 22 2014

Labels: Area-ImageDecoder
Project Member

Comment 4 by, Nov 10 2014

jpeg_start_decompress returns false, although I haven't found a description of what the return value means.

While debugging, though, it stream->isAtEnd() returned true, so it appears we reached the end of the stream during that function.

This means our later calls would have nothing to read. I haven't figured out how other decoders successfully decode this image. (FWIW, I believe on Android we use libjpeg-turbo as well.)
Project Member

Comment 5 by, Jan 15 2015

Blockedon: skia:3257 skia:3315
As we update our decoders, we should make sure that we fix this.
Project Member

Comment 6 by, May 14 2015

Re: #4: Android does *not* use libjpeg-turbo; I was mistaken.

Reassigning to Matt, who is investigating switching to libjpeg-turbo and generally looking into jpeg bugs.
Project Member

Comment 7 by, Oct 23 2015

This is an incomplete, progressive jpeg image.

Notice, how the bottom 3/4 of the image appears very blurry.  That is because the end of the jpeg file (with more information on these pixels) is missing.

SkImageDecoder_libjpeg and SkJpegCodec choose not to decode progressive images progressively.  jpeg_start_decompress() will perform all of the entropy decoding upfront and then we will finish the decode line-by-line using jpeg_read_scanlines().

In this case, jpeg_start_decompress() cannot complete the entropy decoding because the image is truncated.  It will therefore, never allow us to enter the SCANNING state and begin decoding scanlines.  This is consistent with Leon's note above (#4) that indicates that jpeg_start_decompress() returns false.

Chromium (and most other decoders, it appears) try to decode progressive images progressively (in buffered_image mode).  This allows them to perform the entropy decoding as they go.  Therefore, they will not fail until the final pass, and the output will look somewhat reasonable.

We could adopt this strategy for progressive images but it would require using the libjpeg-turbo API differently for progressive images.  I am hesitant about this - it's not a great fit for Skia's scanline decoder API (it would look very similar to how we handle interlaced pngs).

IMO, jpeg_start_decompress() shouldn't fail even if it can't completely finish the entropy decode for progressive images.  I locally patched libjpeg-turbo to change this behavior.  It's a one line patch that I doubt they would accept.  And the output is still underwhelming compared most other decoders.  I am attaching it.  A more significant, tricky (and likely unacceptable) patch could probably allow us to duplicate the behavior of chromium decoder.

Right now this seems low priority to me.  I'm not sure exactly what the best fix for us is.
129 KB View Download
Project Member

Comment 8 by, Oct 23 2015

Project Member

Comment 9 by, Oct 26 2016

I suspect that Leon will fix this when he adds incremental decoding support to SkJpegCodec.
Project Member

Comment 10 by, Apr 6 2017

Summary: Incomplete, progressive JPEG image appears black when opened (was: JPEG images appearing black when opened)
> I suspect that Leon will fix this when he adds incremental
> decoding support to SkJpegCodec.

cblume@ is now looking to switch SkJpegCodec to incremental decoding. This will be a good test case.
This issue is fixed with the following CL

Sign in to add a comment