Hello,

Suspected Bug:
I think I've found a bug when loading raw RGB565 data. If you load it on a big-endian machine, it produces garbled output. If you load it on a little-endian machine it works fine. If you swap the bytes in the file by hand, it appears to work fine. The bug is located in several places in /plugins/common/file-raw.c.

Proposed Fix: I think what we need is two modes - RGB565-LittleEndian(enum mode: RAW_RGB565LE), and RGB565-BigEndian(enum mode: RAW_RGB565BE). This would of course, require another menu entry and possibly a translated string.

What I would like to do about it: If this sounds good to the group, I'll happily cook up the required patches, and test images.

Why it affects me: As an embedded developer, sometimes we use screens that are the opposite endianness of the display. For newer ARM devices with rev16 support, this isn't much of an issue, but I still like to use GIMP to check our bitmap packer and sometimes our firmware images.

You guys are awesome: Thank you for writing GIMP.

-Richard Allen

https://bugzilla.gnome.org/show_bug.cgi?id=673315

A patch is posted to fix this by splitting 'RGB565' into 'RGB565-BigEndian' and 'RGB565-LittleEndian'.

Another patch adds BGR565(both endians), which I've dealt with in embedded system a few times, so I'd love to have it supported by gimp directly ( although I suppose I could load it with RGB565 and swap the channels later)

-Richard

On Sun, Mar 11, 2012 at 3:34 PM, Richard Allen wrote:

Hello,

Suspected Bug:
I think I've found a bug when loading raw RGB565 data. If you load it on a big-endian machine, it produces garbled output. If you load it on a little-endian machine it works fine. If you swap the bytes in the file by hand, it appears to work fine. The bug is located in several places in /plugins/common/file-raw.c.

Proposed Fix: I think what we need is two modes - RGB565-LittleEndian(enum mode: RAW_RGB565LE), and RGB565-BigEndian(enum mode: RAW_RGB565BE). This would of course, require another menu entry and possibly a translated string.

What I would like to do about it: If this sounds good to the group, I'll happily cook up the required patches, and test images.

Why it affects me: As an embedded developer, sometimes we use screens that are the opposite endianness of the display. For newer ARM devices with rev16 support, this isn't much of an issue, but I still like to use GIMP to check our bitmap packer and sometimes our firmware images.

You guys are awesome: Thank you for writing GIMP.

-Richard Allen