RGB order changed when calling pixReadWithHint/pixWrite

[sinall]

auto pix = pixReadWithHint("source.bmp", IFF_BMP);
auto ret = pixWrite("target.bmp", pix, IFF_BMP);

The source.bmp is captured by ATL CImage on Windows 11.

Testing images are attached.

images.zip

[DanBloomberg]

pixReadWithHint() ignores the second arg if the input image format is not jpeg. So there's no issue there.

I wrote the following test code, run on linux, and there are no issues with component order. Try it, and let me know the results on Windows.

    pix1 = pixRead("source.bmp");
//    pix1 = pixReadWithHint("source.bmp", IFF_BMP);   // ignores 2nd arg
    pixWrite("/tmp/junk1.bmp", pix1, IFF_BMP);
    pixWrite("/tmp/junk1.png", pix1, IFF_PNG);
    pix2 = pixRead("/tmp/junk1.bmp");
    pix3 = pixRead("/tmp/junk1.png");
    pixEqual(pix2, pix1, &same);
    lept_stderr("same: %d\n", same);
    pixEqual(pix3, pix1, &same);
    lept_stderr("same: %d\n", same);
    pixDisplay(pix2, 300, 100);
    pixDisplay(pix3, 500, 100);
    pixWrite("/tmp/junk2.bmp", pix2, IFF_BMP);
    writeImageFileInfo("/tmp/junk1.bmp", stderr, 0);
    writeImageFileInfo("/tmp/junk2.bmp", stderr, 0);

[sinall]

pixReadWithHint() ignores the second arg if the input image format is not jpeg. So there's no issue there.

I wrote the following test code, run on linux, and there are no issues with component order. Try it, and let me know the results on Windows.

    pix1 = pixRead("source.bmp");
//    pix1 = pixReadWithHint("source.bmp", IFF_BMP);   // ignores 2nd arg
    pixWrite("/tmp/junk1.bmp", pix1, IFF_BMP);
    pixWrite("/tmp/junk1.png", pix1, IFF_PNG);
    pix2 = pixRead("/tmp/junk1.bmp");
    pix3 = pixRead("/tmp/junk1.png");
    pixEqual(pix2, pix1, &same);
    lept_stderr("same: %d\n", same);
    pixEqual(pix3, pix1, &same);
    lept_stderr("same: %d\n", same);
    pixDisplay(pix2, 300, 100);
    pixDisplay(pix3, 500, 100);
    pixWrite("/tmp/junk2.bmp", pix2, IFF_BMP);
    writeImageFileInfo("/tmp/junk1.bmp", stderr, 0);
    writeImageFileInfo("/tmp/junk2.bmp", stderr, 0);

auto pix = pixRead("source.bmp");
auto ret = pixWrite("target.bmp", pix, IFF_BMP);

The same as previous, not working!

[DanBloomberg]

Please send all output from that test code, both to stderr and files written.

[GerHobbelt]

Interestingly, when inspecting both BMP files with a hex inspection tool, it turns out source.bmp (here called test-rgba.bmp) and target.bmp differ quite a bit:

• source.bmp has a 32 bits (BGRA) per pixel setting in its (Windows format) BMP header,
• target.bmp has a 24 bits (BGR) per pixel setting in its (Windows format) BMP header.

See also this hex comparison (using Beyond Compare in Hex Compare mode): note the 20 00 vs. 18 00 little endian 32 vs. 24 bpp values at offset 0x1C (bits per pixel)

Another interesting thing to note is that the source BGRA values are rotated to RGB in the target. That's not possibly an endian swap mistake or suchlike, as then the alpha channel of the source (first value: 31) should have ended up front instead, instead of the observed 33 value (target, offset 0x36)

Ran the C++ code

auto pix = pixRead("source.bmp");
auto ret = pixWrite("target.bmp", pix, IFF_BMP);

on Win10/64 with latest leptonica (+ irrelevant patches) and was not able to produce target.bmp from source.bmp.

Other interesting things to note:

• leptonica pixRead + pixWrite keep the 32bits per pixel setting intact, so getting an actual 24 bits per pixel target.bmp from a 32 bpp source.bmp is done 🤔 somewhere else?
• also note that the original source.bmp has a 0(zero)-almost-everywhere A alpha channel which had me thwarted for a while as my image viewers (ImageGlass, ACDSee) showed the source BMP as all-grey (while their preview wasn't) which had me wonder for a bit if source.bmp was triggering bugs in those viewers. (Verdict for ImageGlass: apparently the preview bar doesn't do transparency, intentionally or otherwise. Off topic.) When you look at the A alpha channel in source.bmp, you'll see it's 0x00 (fully transparant) everywhere, except the first pixel, which has alpha = 0x31. target.bmp has dropped this alpha channel completely.

• in an attempt to see if I could reproduce target.bmp (goal: use only one or two leptonica calls, max, to change pix), I added code to create a 24bpp PIX from the 32bpp source:

  pix[5] = pixReadWithHint(DEMOPATH("source.bmp"), IFF_BMP);
  ret |= pixWrite("/tmp/lept/bmp-test/target-rgba1.bmp", pix[5], IFF_BMP);
  
  d = pixGetDepth(pix[5]);
  assert(d == 32);
  spp = pixGetSpp(pix[5]);
  assert(spp == 4);
  pix[11] = pixConvert32To24(pix[5]);    // <<--- attempt to create 24bpp BMP/header
  d = pixGetDepth(pix[11]);
  assert(d == 24);
  spp = pixGetSpp(pix[11]);
  assert(spp == 3);
  ret |= pixWrite("/tmp/lept/bmp-test/target-rgba24.bmp", pix[11], IFF_BMP);
  ret |= pixWrite("/tmp/lept/bmp-test/target-rgba24.png", pix[11], IFF_PNG);

  This uncovered something else (to be filed as issue), but after fixing that, did not produce the provided target.bmp: in fact, the size and header were now identical to the provided target.bmp, but leptonica correctly output BGR.BGR.BGR pixel byte sequences, instead of target.bmps RGB.RGB.RGB.

  Haven't been able to produce an exact byte-for-byte match of target.bmp;, though the above pixConvert32To24() plus a R-vs-B color channel plane exchange SHOULD produce the given target.bmp. My goal was to see if some simple one/two-line code/calls would produce this issue.

---

@sinall: So are you running an old version of leptonica -- I haven't run a git blame analysis to see if there ever was a bug in BMP I/O code that could trigger this -- or a patched/augmented system?

---

Code used to test: (test-rgba.bmp in there is identical to original source.bmp; DEMOPATH and a few other bits in there are specific to my patched copy of leptonica, so you'll have to adjust/remove those lines to make them work with regular leptonica)

issue675.zip

[DanBloomberg]

We are unable to find a problem on linux or Windows. Will leave this open for a while in case @sinall has more information to share.

[DanBloomberg]

This problem is fixed on linux and Windows.