Please nominate your Qt Champions for 2021!

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?


  • Lifetime Qt Champion

    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".


  • Lifetime Qt Champion

    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

Log in to reply