Writing 24bpp (depth=24, spp=3) PIX to BMP produces b0rked files

[GerHobbelt]

See also comment at #675 for code extract as sample code zip.

Relevant code sequence extract shown here (knowing pixReadWithHint is same as pixRead or BMP, but this was coded while looking at #675, where pixReadWithHint was initially used) :

    pix[5] = pixReadWithHint(DEMOPATH("test-rgba.bmp"), IFF_BMP);
    // identical to: pix[5] = pixRead(DEMOPATH("test-rgba.bmp"));

    d = pixGetDepth(pix[5]);
    assert(d == 32);
    spp = pixGetSpp(pix[5]);
    assert(spp == 4);
    pix[11] = pixConvert32To24(pix[5]);  // <<-- required to reproduce this issue: only happens for 24bpp PIX
    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);

Note that the expected output BMP filesize is around 15K (4 planes source is 20K; we dropped the A plane, so 25% size reduction estimate), but instead is a wild, quite large size.

Turns out d=24 will drive the bmp writer to use a cmapped / b<=8 code path, rather than the d=32/d=16 'full color' code path.

A pullreq with a patch is forthcoming.

(I need to extract/cherrypick that from my fork, so expect a ~30 mins delay on that.)

[GerHobbelt]

Closed & fixed as per #685.