Color reversal Qt Embedded and 24bpp
-
Seeing an issue using Qt Embedded 4.8.5 on linux framebuffer.
Platform is little-endian, framebuffer is 24bpp RGB.
It seems that Qt is storing the pixels to the framebuffer in
big-endian order ([R], [G], [B]) instead of little-endian order
([B], [G], [R]), causing the blue and red colors to be “reversed”.We checked the fbinfo returned by the framebuffer and it
seems to be correct.Is this a known issue? Is it resolved in Qt 5?
MV
-
Hi and welcome to devnet,
AFAICS, it's not an big vs little indian problem, it's rather a color channel swapping problem. On what device do you have that ?
-
@SGaist
Hi, thanks for your reply. This is a custom device based on ARM926 running little-endian .
The SoC's LCDC documentation specifies the format of a 24-bit pixel value as having red
in the high-order byte, green in the middle byte, and blue in the low-order byte.Being little-endian, looking that the FB as an array of bytes, I would expect the
blue byte to be stored at the lower address, followed by the green byte and then
the red byte. If I write to the FB in this format, colors are displayed on LCD as expected.But when I write an image of a red logo via Qt (displays correctly as red on a different
--32bpp--platform), the logo shows as blue on the LCD. And when I dump the FB, I see
the red byte comes first. Which is what suggested an endianness issue to me.When I look at the source, it seems to me that the pixel-format classes assume a
big-endian framebuffer, since they always store the three bytes in red, green, blue
order of ascending addresses.I have worked-around the issue by setting "pixeltype = QScreen::BGRPixel;" when
the fbinfo matches "rgb888".MV
-
RGB vs BGR is really not an endianness question, you can hit that problem with both. It's about how the data is stored. However the endianness can come up when transferring that data further down which is what might be hitting you. Anyway, glad you found a workaround
