• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Plugins
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by TheAlmightyGuru - 2014-05-28
Last edited by dreamlayers - 2016-04-01

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

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:

Closed by  dreamlayers
2016-04-01 17:49
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Fixed in 26697d0 via G#1232

This problem also exists on today’s build: 148e0ab

So is this a problem only with the JPEG viewer or also on the WPS?

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?

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:

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.

I just uploaded a fix to Gerrit:


Available keyboard shortcuts


Task Details

Task Editing