B/W *.BMP's in an *.IPF show up as negatives - OS2

This is a discussion on B/W *.BMP's in an *.IPF show up as negatives - OS2 ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: B/W *.BMP's in an *.IPF show up as negatives

  1. B/W *.BMP's in an *.IPF show up as negatives


    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?



    ---

  2. Re: B/W *.BMP's in an *.IPF show up as negatives

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

  3. Re: B/W *.BMP's in an *.IPF show up as negatives

    [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

  4. Re: B/W *.BMP's in an *.IPF show up as negatives

    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

  5. Re: B/W *.BMP's in an *.IPF show up as negatives


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



    ---

  6. Re: B/W *.BMP's in an *.IPF show up as negatives


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



    ---

  7. Re: B/W *.BMP's in an *.IPF show up as negatives

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


  8. Re: B/W *.BMP's in an *.IPF show up as negatives


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



    ---

  9. Re: B/W *.BMP's in an *.IPF show up as negatives

    [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

  10. Re: B/W *.BMP's in an *.IPF show up as negatives

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

+ Reply to Thread