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 <rsaxvc@xxxxxxxxx> 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 > <source-root>/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 _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
