> When using some black&white OS/2 *.BMP's (v1.x XOR v2.x bitmap formats,
> saved with PMView Pro 3.05) in an *.IPF file, both Newview and eCS show
> negatives of the bitmaps (white&black). Apps like PMView et al show it
> black&white. Converting the images to 4+-bit colors don't seem to solve
> this. Images with more colors don't show up as negatives.
>
> Is this a bug? How can I make sure the embedded images always show up
> correctly, and not as negatives of the original images?

Well, the interpretation of B&W bitmaps is not very clear, the PM
expects them differently than other tools. And as IPF files are
usually directly rendered by the PM you see this strange effect.

PMView (and other tools) usually write a colour palette into the
file which is unfortunately not used by PM. PM always uses a fixed
palette in ignores the one from the file. It expects that a 1 in
the data refers to the foreground color (which is usually black)
while 0 refers to the background color. If a tool provides a palette
that is the other way round, the PM still insists on its fixed mapping.
Though 4bpp images should not show this behavior because there
the colour palette is required and also used by PM.

I see the following choices for you:
1. Invert the bitmap in PMView if the palette window has the white
after the black before saving the bitmap.
2. Use the GBM tools to post process your bitmaps written by PMView.
You can specify whether the palette or the data should be inverted.
It is also possible to make the darkest color the first one in the
data which is usually what PM expects.

[A complimentary Cc of this posting was sent to
ML
], who wrote in article :
>
> When using some black&white OS/2 *.BMP's (v1.x XOR v2.x bitmap formats,
> saved with PMView Pro 3.05) in an *.IPF file, both Newview and eCS show
> negatives of the bitmaps (white&black). Apps like PMView et al show it
> black&white.

I think these sorts of bugs are very understandable. IIRC, GPI API
effectively has 3 (!) different "palettes" simultaneously at action.
Different APIs use different flavors of these 3.

So it is very easy to get lost, and set a wrong "palette" before
calling a particular API. The developer thinks he setup a correct
palette; in fact what infuence the result is a different palette
(which was setup up some time in the past before a different call).
As a result, it is similar to "uninitialized memory read": sometimes
it works, some time it does not.

(E.g., I have a similar problem with Tk; had no time to trace it doun,
or at least make an explicit list which drawing API uses which palette
- this is not clearly documented...)

Hope this helps,
Ilya

ML wrote:
> When using some black&white OS/2 *.BMP's (v1.x XOR v2.x bitmap formats,
> saved with PMView Pro 3.05) in an *.IPF file, both Newview and eCS show
> negatives of the bitmaps (white&black). Apps like PMView et al show it
> black&white. Converting the images to 4+-bit colors don't seem to solve
> this. Images with more colors don't show up as negatives.
>
> Is this a bug? How can I make sure the embedded images always show up
> correctly, and not as negatives of the original images?
>
>
>
> ---
As far as I recall, the difference is between the OS/2 and Windows
varieties of BMPs. The implication might be that some apps don't know
they are running in OS/2.
Peter

> PM always uses a fixed palette in ignores the one from the file.
> It expects that a 1 in the data refers to the foreground color
> (which is usually black) while 0 refers to the background color.

That seems to be spot on, both B/W (black background, white text) and
W/B (white background, black text) look like being inversed. If you
don't know the original image, to a human they all end up looking like
a black background with white text.

> 2. Use the GBM tools to post process your bitmaps written by PMView.
> You can specify whether the palette or the data should be inverted.

I'ld prefer to try both, since any common app should display the right
image then (perhaps not always, I'll settle for as good as it gets)::

Original 3x1 image: 010, palette 0=FF, 1=0
Improved 3x1 image: 101, palette 0=0, 1=FF

Theoretically, I'ld say black is the first color in the palette then,
PM satisfied, and any app respecting the palette also could get it
right.

> It is also possible to make the darkest color the first one in the
> data which is usually what PM expects.

AFAICT that should happen when both inversions (palette and data, in
2 separated passes) are applied, indeed white often is the first one
in the palette.

If it ain't too much trouble, can you provide an example of how to
invert both the data and the palette with GBM's tools? Or perhaps
just inverting the palette, a negative ought to invert the data (and
the palette with 1 bbp, which invertion then has to be undone).



---

> I think these sorts of bugs are very understandable. IIRC, GPI API
> effectively has 3 (!) different "palettes" simultaneously at action.
> Different APIs use different flavors of these 3.

Well, unless the "wrong" palette actually is "intelligently designed"
some way, overriding palette settings applyable, I hope inverting both
the data and the palette covers any reasonable situation.

Then the image should right as intended in my *.IPF file, the PM should
show it right, and if you may view an extracted image with a palette-
respecting app it still should look as intended, without the author of
such a palette-respecting app getting flamed for inverting the image.
In a way, "image=(!!)image;"...

BTW, e.g. PMView allows me to increase the number of bbp's to >1. But
I guess such a setting doesn't help that much, because the number of
actual colors remains 2. Maybe actually sneaking in a grey would help
then, albeit I'ld say that affects both the image and the file size.



---

> If it ain't too much trouble, can you provide an example of how to
> invert both the data and the palette with GBM's tools? Or perhaps
> just inverting the palette, a negative ought to invert the data (and
> the palette with 1 bbp, which invertion then has to be undone).

For B&W bitmaps you can specify output options to the BMP
encoder in every tool. For your purpose the simple converter
is sufficent (gbmconv.exe):

1. Invert palette:
gbmconv src.bmp dst.bmp,inv

2. Invert data:
gbmconv src.bmp dst.bmp,invb

3. Darkest color as foreground:
gbmconv src.bmp dst.bmp,darkfg

4. Lightest color as foreground:
gbmconv src.bmp dst.bmp,lightfg

I think 3. is what should suit your needs.

You can find all options and tool descriptions in the
GBM package or at the GBM homepage http://heikon.home.tlink.de/.
Look under "Bitmap Formats" for the above options.
Each encoder/decoder has different possibilities.
At the end of the tools page you'll find also some examples.

> For your purpose the simple converter is sufficent (gbmconv.exe):

Thanks! I did RTFiM off- and online more than once, but in this case
I kind of needed the tool factory's support department to reveal the
true power of the tools (mainly related to anything after the ,). :-)

> 1. Invert palette:
> gbmconv src.bmp dst.bmp,inv

> 2. Invert data:
> gbmconv src.bmp dst.bmp,invb

> 3. Darkest color as foreground:
> gbmconv src.bmp dst.bmp,darkfg

> 4. Lightest color as foreground:
> gbmconv src.bmp dst.bmp,lightfg

> I think 3. is what should suit your needs.

It should, earlier today I saw the colors were in reversed order
indeed. I'm also going to try 1&2, hoping that will result in a
correct image regardless of the viewer (e.g. eCS, GBMV2, Newview,
PMJPEG, PMView, ...). That's not that important, but it may provide
bugfixproveness because it always should (!?) look right then.

Anyway, thanks for your efforts.



---

[A complimentary Cc of this posting was sent to
ML
], who wrote in article :
>
> > I think these sorts of bugs are very understandable. IIRC, GPI API
> > effectively has 3 (!) different "palettes" simultaneously at action.
> > Different APIs use different flavors of these 3.
>
> Well, unless the "wrong" palette actually is "intelligently designed"
> some way, overriding palette settings applyable, I hope inverting both
> the data and the palette covers any reasonable situation.

No.

> Then the image should right as intended in my *.IPF file, the PM should
> show it right, and if you may view an extracted image with a palette-
> respecting app it still should look as intended, without the author of
> such a palette-respecting app getting flamed for inverting the image.
> In a way, "image=(!!)image;"...

If my conjecture is true, then how the image is shown by the
application depends on which APIs were called before displaying the
image. E.g., in which order you were viewing the pages...

> BTW, e.g. PMView allows me to increase the number of bbp's to >1. But
> I guess such a setting doesn't help that much, because the number of
> actual colors remains 2. Maybe actually sneaking in a grey would help
> then, albeit I'ld say that affects both the image and the file size.

I think it worths checking. The application may use a different API
to show 1-images which are forced to be 1-bit by their format, than
multi-bit images which HAPPEN to be 2-colors...

Hope this helps,
Ilya

>> BTW, e.g. PMView allows me to increase the number of bbp's to >1. But
>> I guess such a setting doesn't help that much, because the number of
>> actual colors remains 2. Maybe actually sneaking in a grey would help
>> then, albeit I'ld say that affects both the image and the file size.

I think the root cause is that PMView seems to optimize the size
of the bitmap and choses the format with the smallest required
palette. So if you just convert the 1bpp b&w to 4bpp and save it
without adding a 3rd color, the image on the disk will end up
still as 1bpp. When you reload the bitmap in PMView you can see
as what it was detected.
If my assumption is correct, you can try to upconvert one of your
1bpp b&w bitmaps with gbmbpp to 4bpp greyscale to see if it helps
(gbmbpp -m 4g 1bpp.bmp 4bpp.bmp).

> I think it worths checking. The application may use a different API
> to show 1-images which are forced to be 1-bit by their format, than
> multi-bit images which HAPPEN to be 2-colors...

Yes, I think there is at least one GPI function that always
draws 1bpp bitmaps b&w (can't remember the name yet). Others
respect the foreground and background color set on the HPS.
Maybe the intention was to optimize performance for printing
to b&w printers.

As GPI takes the 1's of a 1bpp bitmap as foreground color and the
0's as background color, the application has to take care for
extracting the color palette from the bitmap info header.
It has to create a logical color table and set the foreground
and background color explicitly (GpiSetColor(), GpiSetBackColor()).
If this is not done, the Presentation Space defaults are used
which are black for the foreground and white for the background.
And of course the right GPI bitmap drawing call has to be used.

For bitmaps >1bpp and <=8bpp the mechanism is different. The PM
directly uses the colors from the palette entries of the bitmap
info header. 24bpp bitmaps don't require a palette (though PM
may use it for rendering the bitmap on low color devices).
The colors are directly coded in the bitmap data as BGR triples.

The additional step for rendering 1bpp bitmap is easily overseen.

I think the mechanism for 1bpp bitmaps is implemented this way
because these bitmaps can also be used as masks by the GPI e.g.
for simple transparency. Unfortunately GPI does not support
transparency for more colors as it would be required for direct
rendering for instance of PNGs with alpha channel. The application
has to do the calculations manually pixel by pixel without support
from the graphics card (Windows supports alpha channel, OS/2 not).
That's also the reason why the rendering of a page with heavy use
of transparent PNGs makes Mozilla/SeaMonkey so CPU aggressive .