BITMAPINFO colorDepth:

Blair,

Because of a problem with my DeviceIndependentBitmap goodie I've been
looking into the setting of the colorDepth in bitmaps again -
specifically the number of RGBQUADS needed for bitmaps >= 16 bit.

In patch #1073 BITMAPINFO>>colorDepth: was modified to also use 0 for 32
bit bitmaps (as well at 24 bit), I think it also needs to be changed to
also use 0 for 16 bit bitmaps.  These changes all make the assumption
that the compression method used is BI_RGB, which is what the method
comment implies.

This change would then mean that this method matches the answer returned
by the BITMAPINFOHEADER>>numQuads method for RGB bitmaps.

BITMAPINFO>>colorDepth: colorDepth
    "Answer a new instance of the receiver capable of representing
        information about an RGB bitmap with the specified colour depth
        (e.g. 8, 16, 24 or 32 bpp).
    This assumes that biCompression = BI_RGB and biClrUsed =
        biClrImportant = 0 (for 16, 24 and 32) or the number of colours
        in the colorTable (for 1, 4 and 8)."

    | quads |
    quads := colorDepth < 16
        ifTrue: [2 raisedToInteger: colorDepth]
        ifFalse: [0].
    ^self new: self byteSize + ((quads - 1) * RGBQUAD byteSize)
--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote in message
news:fGVLb.21203$[hidden email]...
Ian, I'll defer to your greater knowledge on this subject. If you still
believe this to be correct (considering your later post) then we'll include
your suggested patch in PL4.

Regards

Blair

Blair,

> Ian, I'll defer to your greater knowledge on this subject.

Must be a different Ian you're thinking of ....

>                    If you
> still believe this to be correct (considering your later post) then
> we'll include your suggested patch in PL4.

There's a rather large can of worms in this area so it's probably best
to just forget about it :-).  The occasionally incorrect size of the
BITMAPINFO struct doesn't _seem_ to cause problems, most of the other
structures involved are aware that it needs a lot of flexibility and use
dynamically allocated offsets to get around it.

FWIW,

For a BI_RGB DIB (16, 24 or 32 bits) the bmiColors parameter can either
be null (i.e. it occupies 0 bytes) or else it can contain an array of
RGB values (to optimise colours in a palette based system apparently).

For a BI_BITFIELDS DIB (16 and 32 bits only) the bmiColors parameter is
always three DWORD values that act as masks. This may then be followed
by an array of RGBs as above.

For a BI_RGB DIB (1, 4 or 8 bits) Dolphin assumes that the ColorTable
will be the maximum size possible but that is not necessary. The number
of RGBs in the table is given by the BITMAPINFOHEADERs biClrUsed
parameter

Different OSs have different capabilities.

biBitCount can be 0 (for jpg and png images)

and on and on and on  .....

Should anyone be interested I've now got some methods that enable a
DIBSection (using either BI_RGB or BI_BITFIELDS) to work with the
Clipboard and be saved to a file.  It 'aint pretty though :-)

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.