Huffman colors inverted?

[rupertwh]

I believe the colors in the Huffman sample file are (or should be) inverted.

Here is an original OS/2 Warp screenshot of pal1huffmsb.bmp opened with the system image viewer:

I remember reading something about a black-is-white and white-is-black confusion wrt Huffman encoding -- but can't find it anymore, of course. All I can find now is this CCITT (Huffman) Encoding page which states that "1 = black and 0 = white".

[rupertwh]

Maybe I spoke too soon. I had only tried the files from the 'q' directory.

After opening the 'good' 1-bit samples in OS/2, I don't understand what is going on:

Seems like the viewer is (was) inverting the colors? And somewhat, but not completely, ignoring the color table?

[jsummers]

Thanks. I had a chance to do some testing of my own, and I think I'm seeing the same thing as you, with the viewer from Warp 4.

Fax compression can be a problem, because it doesn't decompress to 0s and 1s. It decompresses directly to "background" and "foreground" pixels, where background is supposed to be the fax paper color, usually white.

If you use fax compression in a format like BMP, which has a color palette, then you have to decide whether the fax foreground color is always black, always white, stored in palette entry 0, or stored in palette entry 1.

In my sample image, the pixels at the lower-left corner are the fax foreground color, and I want them to be displayed as black.

The viewer more-or-less behaves as if the foreground color were palette entry 0. (Noting that it only displays black and white. It's not very good at figuring out which color is darker, but I think it does try to.) If that's correct, then my sample image is wrong. Its palette should be black then white, instead of white then black.

But since the viewer displays uncompressed 1-bit images as the negative of how every other BMP viewer displays them, then who knows what's correct?

[rupertwh]

I am almost convinced now that your sample image is correct, and that the OS/2 viewer deliberately swaps the foreground and background colors.

Back in the day of monochrome CRTs, you would have actually wanted scanned text pages to be displayed white (or rather green or amber) on black. Thus, having the foreground bits 1 and background bits 0 would work well for both printing and screen viewing.

But for a GUI on an RGB monitor, you would want the bits flipped between printing and screen viewing, and my suspicion is that IBM did just that as a service for the user -- under the assumption that 1-bit bitmaps must surely be old-fashioned 'made-for-printing'.

I have of course zero references for that, jut my current working theory.