StretchDIBits
jon siragusa
hi,
i'm having problems drawing to a DC using StretchDIBits.
i seem to have some sort of palette problem. i can see the image
that i want to show, however its in a strange palette. after looking
more closely, i noticed that my RGB values were getting "reversed" to
BGR. for example, in the following code for a WM_PAINT message,
i expect a blue line to be drawn. however, my line ends up red.
anyone know what i'm doing wrong?
my display is in 16-bit color mode, the same thing happens in 24-bit.
case WM_PAINT: {
PAINTSTRUCT paintStruct;
HDC hdc;
hdc = BeginPaint( hWnd, &paintStruct );
BITMAPINFO *lpbmi = new BITMAPINFO;
int h=1, w=20;
char *data = new char[h*w*3]; // 24 bit image
for(int i=0; i<w*h*3; i+=3) {
data[i] = 0;
data[i+1] = 0;
data[i+2] = 200;
}
memset(lpbmi,0,sizeof(BITMAPINFO));
lpbmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
lpbmi->bmiHeader.biWidth = w;
lpbmi->bmiHeader.biHeight = -h;
lpbmi->bmiHeader.biPlanes = 1;
lpbmi->bmiHeader.biBitCount = 24;
lpbmi->bmiHeader.biCompression = BI_RGB;
SetStretchBltMode(hdc,COLORONCOLOR);
StretchDIBits( hdc,
0, 0,
w, h,
0, 0,
w, h,
data,
lpbmi,
DIB_RGB_COLORS,
SRCCOPY);
delete lpbmi;
EndPaint( hWnd, &paintStruct );
break;
}
thanks,
jon
chris losinger
jon siragusa <sira...@vrex.com> wrote:
>hi,
>
>i'm having problems drawing to a DC using StretchDIBits.
>
>i seem to have some sort of palette problem. i can see the image
>that i want to show, however its in a strange palette. after looking
>more closely, i noticed that my RGB values were getting "reversed" to
>BGR. for example, in the following code for a WM_PAINT message,
>i expect a blue line to be drawn. however, my line ends up red.
>
StretchDIBits (and any kind of Windows Blt fn) reverses red and
blue. a .BMP file is red/blue reversed - and usually vertically
flipped.
annoying
-----------------------------------------------------------------------
c h r i s l o s i n g e r
chr...@netheaven.com http://www.netheaven.com/~chrisdl
The secret word is now "miscasting".
Paul Rowntree
chris losinger wrote:
>
> jon siragusa <sira...@vrex.com> wrote:
>
> SNIP
> >i'm having problems drawing to a DC using StretchDIBits.
> >
> blue. a .BMP file is red/blue reversed - and usually vertically
> flipped.
>
How is this possible? I have been using Blt functions for a quite a
while, doing my own palette manipulations etc, and I have never seen this
type of behaviour.
--
p. rowntree
Departement de chimie, Universite de Sherbrooke, Sherbrooke, Quebec,
Canada
Robert Schlabbach
Paul Rowntree <rown...@structure.chimie.usherb.ca> wrote in article
<3304FC...@structure.chimie.usherb.ca>...
> chris losinger wrote:
> > StretchDIBits (and any kind of Windows Blt fn) reverses red
and
> > blue. a .BMP file is red/blue reversed - and usually vertically
> > flipped.
>
> How is this possible? I have been using Blt functions for a quite a
> while, doing my own palette manipulations etc, and I have never seen
this
> type of behaviour.
He probably has a buggy video driver installed. For example, I noticed
that _all_ Matrox Windows NT 4.0 driver releases so far have the same bug
in 24bpp mode - swapping red, green and blue values on certain blit
operations...
Regards,
--
Robert Schlabbach
e-mail: rob...@powerstation.isdn.cs.TU-Berlin.DE
Technical University of Berlin, Germany
Helmut Leitner
jon siragusa wrote:
>
> hi,
>
> i'm having problems drawing to a DC using StretchDIBits.
>
> that i want to show, however its in a strange palette. after looking
> more closely, i noticed that my RGB values were getting "reversed" to
> BGR. for example, in the following code for a WM_PAINT message,
> i expect a blue line to be drawn. however, my line ends up red.
>
The problem doesn't come from the StretchDIBits function.
If you build a true color image bitmap, you must use BGR byte order
and reverse line order. That's the internal Windows format.
The reason for the BGR order seems to be, that almost all graphic cards
use this order in their screen buffer.
Don't know, why they chose the reverse line order.
Helmut Leitner
chris losinger
Helmut Leitner <lei...@hls.via.at> wrote:
>jon siragusa wrote:
>>
>> hi,
>>
>> i'm having problems drawing to a DC using StretchDIBits.
>>
>> i seem to have some sort of palette problem. i can see the image
>> that i want to show, however its in a strange palette. after looking
>> more closely, i noticed that my RGB values were getting "reversed" to
>> BGR. for example, in the following code for a WM_PAINT message,
>> i expect a blue line to be drawn. however, my line ends up red.
>>
>> anyone know what i'm doing wrong?
>
>The problem doesn't come from the StretchDIBits function.
>
>If you build a true color image bitmap, you must use BGR byte order
>and reverse line order. That's the internal Windows format.
>
oh yeah... forgot to mention i was assuming you were getting your
bits from a BMP.
-----------------------------------------------------------------------
c h r i s l o s i n g e r
chr...@netheaven.com http://www.netheaven.com/~chrisdl
Billy's first word was "dualistic".
Samy Mesbah
In article <01bc1adc$ecbd2f80$8add9582@powerstation>,
Robert Schlabbach <rob...@powerstation.isdn.cs.TU-Berlin.DE> wrote:
>Paul Rowntree <rown...@structure.chimie.usherb.ca> wrote in article
><3304FC...@structure.chimie.usherb.ca>...
>> chris losinger wrote:
>> > StretchDIBits (and any kind of Windows Blt fn) reverses red
>and
>> > blue. a .BMP file is red/blue reversed - and usually vertically
>> > flipped.
>>
>> How is this possible? I have been using Blt functions for a quite a
>> while, doing my own palette manipulations etc, and I have never seen
>this
>> type of behaviour.
>
>He probably has a buggy video driver installed. For example, I noticed
>that _all_ Matrox Windows NT 4.0 driver releases so far have the same bug
>in 24bpp mode - swapping red, green and blue values on certain blit
>operations...
>
I know that when you create a DIB as a file, and you choose a depth
without a pallete (ie 16bpp, 24bpp, 32bpp), when you actually put
data in for pixels the order is BGR and not RGB.
This has been consistent with everything I've used so far.
Interestingly, though StretchDIBits gives an error if the bmHeight
parameter is negative although Microsoft's docs claim a negative
height means a top-down bitmap as opposed to the standard bottom-up.
No-one (not even Paint that comes with windows) supports this feature!
Sam
Robert Schlabbach
Samy Mesbah <sa...@interlog.com> wrote in article
<5eg2bu$a...@gold.interlog.com>...
> I know that when you create a DIB as a file, and you choose a depth
> without a pallete (ie 16bpp, 24bpp, 32bpp), when you actually put
> data in for pixels the order is BGR and not RGB.
Maybe an LSB/MSB issue? Put bytes B, G, R, 0 in a file, the grab it into
an Intel 32-bit CPU register and you'll have 0x00RRGGBB in it... :)
Al Evans
In article <5eg2bu$a...@gold.interlog.com>, sa...@interlog.com (Samy Mesbah)
wrote:
> Interestingly, though StretchDIBits gives an error if the bmHeight
> parameter is negative although Microsoft's docs claim a negative
> height means a top-down bitmap as opposed to the standard bottom-up.
> No-one (not even Paint that comes with windows) supports this feature!
It's a little-known fact (at least, *I* didn't know it until a few days ago:-)
that not all display drivers support top-down DIBs.
The excruciatingly odd call you use to find out is:
// Fill out BITMAPINFO struct for DIB you want to display
int dibFlags;
Escape(yourDC, QUERYDIBSUPPORT, sizeof(yourBMInfo), &yourBMInfo, &dibFlags);
if (dibFlags & QDI_DIBTOSCREEN)
// The DIB described by yourBMInfo is supported
--Al Evans--
--
|||| Al Evans -- a...@powertools.com -- proud of Graphic Elements Release 3 ||||
==== A new standard for high-performance interactive Macintosh graphics ====
==== Available from mac.archive.umich.edu and mirrors in ====
|||| /mac/development/libraries/graphicelements3.0.sit.hqx ||||
Samy Mesbah
In article <al-ya02408000R2...@news.eden.com>,
Al Evans <a...@powertools.com> wrote:
>In article <5eg2bu$a...@gold.interlog.com>, sa...@interlog.com (Samy Mesbah)
>wrote:
>
>> Interestingly, though StretchDIBits gives an error if the bmHeight
>> parameter is negative although Microsoft's docs claim a negative
>> height means a top-down bitmap as opposed to the standard bottom-up.
>
>> No-one (not even Paint that comes with windows) supports this feature!
>
>It's a little-known fact (at least, *I* didn't know it until a few days ago:-)
>that not all display drivers support top-down DIBs.
>
>The excruciatingly odd call you use to find out is:
>
>// Fill out BITMAPINFO struct for DIB you want to display
>
>int dibFlags;
>Escape(yourDC, QUERYDIBSUPPORT, sizeof(yourBMInfo), &yourBMInfo, &dibFlags);
>if (dibFlags & QDI_DIBTOSCREEN)
> // The DIB described by yourBMInfo is supported
>
Wow! I didn't even consider the fact that it could be the display
driver but since it doesn't work with the Imagine Series II or the
Matrox drivers (under NT4 and 95 respectively) I just created the
bitmap upside down so when it's displayed it's right side up. At
least that should be compatible with everything out there.
BTW, where on earth did you dig up that piece of code?
Thanks for the info,
Sam
Al Evans
> BTW, where on earth did you dig up that piece of code?
I wish I could say I was inspired, but actually I got it from Bill Wagner,
who recently posted that not all display devices support top-down DIBs and
gave the URL for an article he wrote on the subject:
http://www.vcdj.com/vcdj/nov96/dib.htm
Glad I could pass it on!
T. Barlow
Samy Mesbah wrote:
>
> In article <al-ya02408000R2...@news.eden.com>,
> Al Evans <a...@powertools.com> wrote:
> >wrote:
> >
> >> Interestingly, though StretchDIBits gives an error if the bmHeight
> >> parameter is negative although Microsoft's docs claim a negative
> >> height means a top-down bitmap as opposed to the standard bottom-up.
> >
> >> No-one (not even Paint that comes with windows) supports this feature!
> >
> >It's a little-known fact (at least, *I* didn't know it until a few days ago:-)
> >that not all display drivers support top-down DIBs.
> >
> >The excruciatingly odd call you use to find out is:
> >
> >// Fill out BITMAPINFO struct for DIB you want to display
> >
> >int dibFlags;
> >Escape(yourDC, QUERYDIBSUPPORT, sizeof(yourBMInfo), &yourBMInfo, &dibFlags);
> >if (dibFlags & QDI_DIBTOSCREEN)
> > // The DIB described by yourBMInfo is supported
> >
>
> Wow! I didn't even consider the fact that it could be the display
> driver but since it doesn't work with the Imagine Series II or the
> Matrox drivers (under NT4 and 95 respectively) I just created the
> bitmap upside down so when it's displayed it's right side up. At
> least that should be compatible with everything out there.
>
It's all documented in MSDN. You can query the device for alot of
info. In addition, it also states that top-down wont always work.
Albeit most people consider that statement old ;-)
Troy