Rockbox

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:
http://www.thealmightyguru.com/BadCompany-BadCo3.jpg

This displays corrupt:
http://www.thealmightyguru.com/BadCompany-BadCo4.jpg

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:
http://www.thealmightyguru.com/BadCompany-Corrupt.jpg

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: http://gerrit.rockbox.org/r/#/c/1232/