FS#12981 - JPEGs and album art with black backdrops don't display correctly.

Attached to Project: Rockbox
Opened by Dean Tersigni (TheAlmightyGuru) - Wednesday, 28 May 2014, 19:42 GMT
Last edited by Boris Gjenero (dreamlayers) - Friday, 01 April 2016, 17:49 GMT
Task Type Bugs
Category Plugins
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


The JPEG viewer fails to properly decode album art with a black backdrop. Images that have a lot of black become corrupt and garbled when displayed either as an image on disk or as album art.

I have tried the following to solve the problem:
* I have verified the image looks proper in multiple graphics programs.
* I have save the image with multiple graphics programs to rule-out bugs in the saving process of a particular graphics program.
* I have deleted and recopied the file with a different name to rule-out a bad secot on my flash drive.
* I have made a negative of the image (mostly white), and the negative displays properly.
* I have had another Sansa Clip Zip user verify this problem.

The following file will look corrupt when viewed on a Sansa Clip Zip:

However, a reverse with a white backdrop with be viewed properly:
This task depends upon

Closed by  Boris Gjenero (dreamlayers)
Friday, 01 April 2016, 17:49 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 26697d0 via G#1232
Comment by Dean Tersigni (TheAlmightyGuru) - Wednesday, 28 May 2014, 19:46 GMT
This problem also exists on today's build: 148e0ab
Comment by Thomas Martitz (kugel.) - Thursday, 29 May 2014, 08:53 GMT
So is this a problem only with the JPEG viewer or also on the WPS?
Comment by Dean Tersigni (TheAlmightyGuru) - Thursday, 29 May 2014, 13:44 GMT
The problem occurs both with the album art while a song is playing and with the JPEG viewer when you select a JPG to view while navigating through the folders.

A couple more points to add:
* It seems to only happen with JPG files. I saved the same file as a BMP and deleted the JPG, and it displays the BMP graphic just fine.
* It seems to have something to do with the top-left pixel. I changed just that one pixel to white instead of black, and it displays the graphic correctly. However, the other three corners can be white, and it will still display corrupt

This displays correctly on the Sansa Clip Zip:

This displays corrupt:

I wonder if having the first block of pixels all black is causing the plugin to read it as part of the header or something?
Comment by Dean Tersigni (TheAlmightyGuru) - Thursday, 14 May 2015, 19:22 GMT
Here is a photo of the corruption. The picture quality isn't that great, but you can see how the image is offset, the wrong color, and has a corrupt box in the top-left corner:
Comment by Boris Gjenero (dreamlayers) - Wednesday, 06 January 2016, 05:01 GMT
The problem happens when the entropy data starts with FF. In process_markers() in jpeg_decoder.c, the FF is treated as the start of a marker, and p_jpeg->p_entropy_end points to the next byte. It should point to the FF for proper decoding.

I wonder why process_markers() continues processing markers after SOS and sets p_jpeg->p_entropy_end this way? Wouldn't it make more sense to set p_jpeg->p_entropy_end to point right after the end of the SOS data and break out of the loop right there? Then hopefully this part may be unnecessary:

if (*p_src++ != 0xFF) /* no marker? */
p_src--; /* it's image data, put it back */
p_jpeg->p_entropy_data = p_src;
break; /* exit marker processing */

Entropy data ought to via a SOS marker. Can it ever just start as an invalid marker like that? I don't want to break compatibility with other JPEG files which may break the standard but be widely supported.
Comment by Boris Gjenero (dreamlayers) - Wednesday, 06 January 2016, 06:11 GMT
I just uploaded a fix to Gerrit: