GDI/P - LoadPicture() return type - HBITMAP? Topic is solved

[TheArkive]

I know that LoadPicture() returns an HBITMAP, but what does that mean on the GDI side?

Is HBITMAP and DIB the same thing?

As far as I can tell from what I've come across so far, it seems to be a DIB. Just looking for confirmation, as I am new to this journey, and there is plenty to get lost in.

Other than that, does LoadPicture() always return a 32bpp image (when not a cursor or icon)? Even when loading a GIF? (I know that LoadPicture won't animate a gif.)

[lexikos]

HBITMAP is a GDI type...

Bitmaps can be device dependent or not. DIB = device independent bitmap.

LoadPicture uses a number of different methods, and mostly doesn't create the bitmap directly. I'm not sure whether all methods return a DIB. It doesn't matter most of the time.

[TheArkive]

Thanks lexikos.

I know that was a fairly simple question. I'm just trying to lay my foundation (and temper expectations) for my up-and-coming experiments.

[iseahound]

A GDI hBitmap is usually a 24bpp DIB. hBitmaps are word aligned, so a 24 bpp image will use 32 bits of space.

As a side note, conversion of images with transparency to hBitmaps is a lossy function as hBitmaps use pre-multiplied ARGB.

Unfortunately an hBitmap can really be anything. DDBs can store their pixel data in a hardware compatible form for the memory buffers of printers for example. You can create an hBitmap with 42 bits per pixel and 7 color channels if you wanted.

You may find the following table to be helpful for GDI+. I have not posted this anywhere else yet, but it explains how to read a pixelformat hexadecimal.

Code: Select all

     0x0 DontCare               No pixel format is specified.
     0xF Max                    The maximum value for this enumeration. (Note: There are only 16 pixel formats.)
    0xF0                        Don't put anything here.
   0x100  1bpp                  The format is  1 bits per pixel.
   0x400  4bpp                  The format is  4 bits per pixel.
   0x800  8bpp                  The format is  8 bits per pixel.
  0x1000 16bpp                  The format is 16 bits per pixel.
  0x1800 24bpp                  The format is 24 bits per pixel.
  0x2000 32bpp                  The format is 32 bits per pixel.
  0x3000 48bpp                  The format is 48 bits per pixel.
  0x4000 64bpp                  The format is 64 bits per pixel.
 0x10000 Indexed                The pixel data contains color-indexed values, which means the values are an index to colors in the system color table, as opposed to individual color values.
 0x20000 Gdi                    The pixel data contains GDI colors.
 0x40000 Alpha                  The pixel data contains alpha values that are not premultiplied.
 0x80000 PAlpha                 The pixel format contains premultiplied alpha values.
0x100000 Extended               Reserved.
0x200000 Canonical              The default pixel format of 32 bits per pixel. The format specifies 24-bit color depth and an 8-bit alpha channel.

     0x0 Undefined              The pixel format is undefined.
 0x30101 Format1bppIndexed      Specifies that the pixel format is 1 bit per pixel and that it uses indexed color. The color table therefore has two colors in it.
 0x30402 Format4bppIndexed      Specifies that the format is 4 bits per pixel, indexed.
 0x30803 Format8bppIndexed      Specifies that the format is 8 bits per pixel, indexed. The color table therefore has 256 colors in it.
0x101004 Format16bppGrayScale   The pixel format is 16 bits per pixel. The color information specifies 65536 shades of gray.
 0x21005 Format16bppRgb555      Specifies that the format is 16 bits per pixel; 5 bits each are used for the red, green, and blue components. The remaining bit is not used.
 0x21006 Format16bppRgb565      Specifies that the format is 16 bits per pixel; 5 bits are used for the red component, 6 bits are used for the green component, and 5 bits are used for the blue component.
 0x61007 Format16bppArgb1555    The pixel format is 16 bits per pixel. The color information specifies 32,768 shades of color, of which 5 bits are red, 5 bits are green, 5 bits are blue, and 1 bit is alpha.
 0x21808 Format24bppRgb         Specifies that the format is 24 bits per pixel; 8 bits each are used for the red, green, and blue components.
 0x22009 Format32bppRgb         Specifies that the format is 32 bits per pixel; 8 bits each are used for the red, green, and blue components. The remaining 8 bits are not used.
0x26200A Format32bppArgb        Specifies that the format is 32 bits per pixel; 8 bits each are used for the alpha, red, green, and blue components.
 0xE200B Format32bppPArgb       Specifies that the format is 32 bits per pixel; 8 bits each are used for the alpha, red, green, and blue components. The red, green, and blue components are premultiplied, according to the alpha component.
0x10300C Format48bppRgb         Specifies that the format is 48 bits per pixel; 16 bits each are used for the red, green, and blue components.
0x34400D Format64bppArgb        Specifies that the format is 64 bits per pixel; 16 bits each are used for the alpha, red, green, and blue components.
0x1C400E Format64bppPArgb       Specifies that the format is 64 bits per pixel; 16 bits each are used for the alpha, red, green, and blue components. The red, green, and blue components are premultiplied according to the alpha component.

[TheArkive]

Thanks @isahound! Yah I'm aware of those constants. That is good info.

I'm mainly trying to have a better understanding of bitmap, HBITMAP, DIB, DDB, etc, as it pertains to GDI (not GDI+). I know the 2 are very much related, i'm just trying to wrap my brain around the main differences at this stage.

In addition I'm also trying to understand the different tools that I can work with to ease the use of GDI (such as GDI+ and LoadPicture() from AHK).

Thanks again for the info!

EDIT:

One other aspect I'm trying to understand is how this information is used when converting image types for certain operations, like copying to clipboard, or making a duplicate of the image (if come kind of hidden conversion is done, etc.). I know this understand will come with time, but if there are any specific "rules" or "common things/struggles" to be aware of, I'm definitely ready to soak up that info.

I do understand what a "packed bitmap" is, and I know that format is required when doing clipboard operations. I do occasionally have drawing issues though, mainly when setting StretchBltMode = 4. Sometimes it's just black, or pure alpha (transparent). But that hasn't given me any major hurdles yet. Most of what i need to do to develop the lib is coming together nicely. I'm reading though docs.microsoft.com a LOT these days.

I know that most of what I'm working with in GDI so far is DDB and DIB, and it seems to mostly be 32bpp (given the device context, my video card, etc).

I also know that thanks to GDI+, i can easily load several file types into 32bpp format, and do some conversions rather easily. The GDI lib i'm making (class structured) is definitely using some GDI+ for the purpose of loading/saving files.

[iseahound]

One common setback is the top-down bottom-up distinction. Generally a pointer indicates the beginning of data and the pointer + size denotes the end of the data. But a bottom-up bitmap does things in reverse, because some mathematicians fell in love with the first quadrant of a unit circle, so if y is positive, they reasoned that y should go upwards as demonstrated in the xy Cartesian plane.



So it's a good practice to use a negative height with createDIBSection. The Scan0 (the first scanline of an image) is always equal to the pointer, but subsequent scanlines (Stride) will be above or below that first scanline in memory, given positive or negative height respectively.

[iseahound]

I don't think you should be using StretchBlt at all, because it uses nearest neighbor scaling. It's possible to implement your own scaling algorithm such as Lanczos, but I haven't had any luck with that because my C isn't amazing. Remember that createDIbSection gives you a pointer to the bits (pixels) and it's only a useful pointer when the height is negative.

[TheArkive]

Thanks @isahound. I definitely plan to implement some custom filters later on down the road, once I'm able to wrap my head around this stuff more.

Thanks for the tip about the bottom-up vs top-down. I forgot about that. And I'm sure that will cause me some headaches if I forget again prior to trying to implement custom filters.

I'm not to the point of actually editing the bits yet. But i do plan to get there!