MSDN says that the bitmap used in GetDiBits should not be selected into a DC before calling this function. But from my experience(with BitBlt) I know that I cannot draw an a bitmap unless it is selected.
How does GetDiBits circumvents this? Can I just use an unselected, newly created bitmap as argument to this function?
GetDiBits as well CreateDibSection returns an array. But MSDN says about the first function:
"bits of the specified compatible bitmap"
I thought DI stands for DeviceIndependent. Why is there a contradiction? This means that, according to MSDN, GetDiBits can be used only with CreateCompatibleBitmap (which is DD)? Then I can't send this array to another machine to display it,right?
Both functions use a hDC. If CreateDibSection is truly DIndependent why does it need a hDC? All the needed info is provided through the bitmapinfoheader...
I cannot draw an a bitmap unless it is selected. How does GetDiBits circumvents this?
GetDIBits doesn't do any drawing. It reads pixel data from a bitmap and converts it into the desired color format. SetDIBits doesn't "draw" either, but it will set the pixel data in a bitmap.
Naming confusion.
The DI in GetDIBitmap refers to the fact that the pixel data is returned in a device-independent format (specifically, the one you ask for). The source bitmap can be a compatible bitmap or a device-independent bitmap.
Similarly SetDIBitmap takes device-independent pixel data and converts it to the type of the target bitmap.
These functions are confusingly named.
What's the DC for?
The DC is used to answer any questions about the pixel format on the device. For example, if the source format is a palette-based device-dependent bitmap, GetDIBits will assume the palette selected into the DC is the correct one. Note that the palette is not in the BITMAPINFOHEADER.
CreateDIBSection creates a hybrid bitmap that stashes data in a device-independent method, but may also keep a device-dependent copy in sync with it for performance. So it needs to know the DC of the intended device.
Related
I've known that framebuffer is the final destination of the rendering pipeline and swapchain contains many image. So what is the relation between those two things? Which one is the actual render target? And does the framebuffer later attach the final picture of the current frame on the image view? If so, how will it transfer?
Describing this via paint or diagram would be pleased.
VkFramebuffer + VkRenderPass defines the render target.
Render pass defines which attachment will be written with colors.
VkFramebuffer defines which VkImageView is to be which attachment.
VkImageView defines which part of VkImage to use.
VkImage defines which VkDeviceMemory is used and a format of the texel.
Or maybe in opposite sequence:
VkDeviceMemory is just a sequence of N bytes in memory.
VkImage object adds to it e.g. information about the format (so you can address by texels, not bytes).
VkImageView object helps select only part (array or mip) of the VkImage (like stringView, arrayView or whathaveyou does). Also can help to match to some incompatible interface (by type casting format).
VkFramebuffer binds a VkImageView with an attachment.
VkRenderpass defines which attachment will be drawn into
So it's not like you do not use an image. You do, through the Vulkan Framebuffer.
Swapchain image is no different from any other image. Except that the driver is the owner of the image. You can't destroy it directly or allocate it yourself. You just borrow it from the driver for the duration between acquire and present operation.
There's (usually) more of the swapchain images for the purposes of buffering and advance rendering. AFAIK you would need a separate VkFramebuffer for each image (which is annoying, but more in tune with what actually happens underneath).
Probably the best single sentence from the Vulkan spec that describes framebuffers is:
The specific image views that will be used for the attachments, and
their dimensions, are specified in VkFramebuffer objects.
Yes, you would need a VkFramebuffer object for each image in a swapchain, but you generally would need to allocate only one VkMemory for a depth buffer VkImage and then add the VkImageView for that single depth buffer VkImage to all of your framebuffers.
I have an existing buffer full of (DIB) bitmap data, i.e. width x height x 4 bytes (RGBA) in size. What I want to do is draw this bitmap to the screen, but looking at the CreateBitmap... / CreateDIB... functions, they don't appear to do what I'm looking for. I don't want to copy the memory in, I want to retain access to it, so I can continue to write to it in the next frame (without incurring a penalty for copying the data). Does such a method exist, or do I have to create a new bitmap and call SetDIBits on it?
If you want simple code, then you can use a BITMAP structure and assign it's bmBits to point to your actual image data (RGBA 8-Bit).
Then you can use GDI method
HBITMAP CreateBitmapIndirect(const BITMAP *pbm);
to create HBITMAP for displaying the image to screen.
But actually I think the system still do the copying while creating HBITMAP, that's why after CreateBitmapIndirect returns, you can safely free your image data.
But at least you only have to create the buffer once, and using it repeatedly as long as the size of the image doesn't change.
I use this method to display raw video from RED's Camera.
You can't write a DIB directly to a device context - you'll have to create a bitmap and copy the pixels in. Annoying, I know!
Looks like this question has a succinct way of doing that in the accepted answer.
How can I get image bytes from hbitmap if I am given an HBITMAP pointer, and my application is console application.
I tryed using GetDIBits which require such parameter as HDC, which I can't get.
EDIT:
I load bitmap from file:
HBITMAP bm = 0;
BITMAP Bitmap;
bm = (HBITMAP)LoadImage (0, TEXT("C:\\img1.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE);
I pass the HBITMAP to the function and expect to get another HBITMAP of processed image:
HBITMAP out1 = func(bm);
Where func is:
HBITMAP func(HBITMAP im);
And the problem is how to get image bytes from HBITMAP.
The easiest way is not to use GetDIBits (nor GetBitmapBits). These functions suck because they copy the data.
If you want the data directly, just use (for a DDB bitmap)
BITMAP bitmap;
GetObject(hBitmap, sizeof(bitmap), (LPVOID)&bitmap);
For a DIB bitmap use
DIBSECTION dib;
GetObject(hBitmap, sizeof(dib), (LPVOID)&dib);
GetObject info, See:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd144904%28v=vs.85%29.aspx
This will not involve any copying of data, thus avoids the complicated issues associated with GetDIBits, See:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd144879%28v=vs.85%29.aspx
Esp. the comments at the bottom for an explanation of the difficulties with GetDIBits.
Note that you do not get the palette info, but since most bitmaps are 24 or 32 bits anyway this is hardly an issue most of the time.
Since you're using LoadImage to get the HBITMAP, then it is indeed a DIB (Device-Independent Bitmap) (they call it a DIBsection). However, you don't have the color information.
This MSDN HOWTO shows you how to select the DIBsection into a memory DC. They then go on to use GetDIBColorTable to get the palette. However, I believe from there, with that DC you can use GetDIBits to get the RGB bitmap information as you were trying to do.
Here's the general gist of it:
// Create a memory DC and select the DIBSection into it
hMemDC = CreateCompatibleDC( NULL );
(HBITMAP)SelectObject( hMemDC, hBitmap );
GetDIBits(hMemDC, hBitmap, ...);
You'll note in their code that SelectObject returns a handle to the what was in the DC. They then restore that before calling DeleteDC. I'm not sure its entirely necessary, but they do it. I left it out here for clarity.
What worked for us is this: call GetDIBits while the correct palette (if indexed colour) is still selected into the device context. (Without the palette selected, the colours got garbled.)
But in our use case, it turned out that DIB sections performed a lot better, so check those out as well and benchmark. However, there are some gotchas. Windows wouldn't use the palette, we had to call SetDIBColorTable before use. But the device context still needed a one entry (black only) dummy palette selected and realised into the device context otherwise Windows would also ignore the palette set by SetDIBColorTable. Both SetDIBColorTable and RealizePalette needed to be present otherwise the colours would be garbled.
See new answer since question was edited...
You cannot do this without a handle to the device context (HDC). This is because GetDIBits expects an HBITMAP which is
A handle to the bitmap. This must be a compatible bitmap (DDB).
A DDB is a Device-Dependent Bitmap, (as opposed to a DIB, or Device-Independent Bitmap). That means:
Note that a DDB does not contain color values; instead, the colors are in a device-dependent format.
Which is why GetDIBits requires an HDC. Otherwise it cannot get the color information.
Perhaps a good question is, where did you get an HBITMAP without an accompanying HDC?
If you're trying to create this bitmap in memory, first you can call CreateCompatibleDC to create an in-memory DC compatible with some device, then CreateCompatibleBitmap with that DC. Then you have an HBITMAP and HDC to work with as you please. Otherwise, if you don't know what your HBITMAP is pointing to, you can't expect to do anything useful with it.
You can try GetBitmapBits API even from console. More here:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd144850%28v=vs.85%29.aspx
Just pass HBITMAP handle and you'll get your bytes
I am trying to draw some basic graphics primitives(line, rectangle etc.) using GDI+ apis on 4-bit indexed bitmaps. I am using Bitmap() functions for creating the bitmap and loading the bitmaps.
Bitmap myBitmap(100/*width*/,100/*height*/,PixelFormat4bppIndexed/*Pixel format*/);
Graphics graphics(&myBitmap);
SolidBrush brush(Color(255,128,0,0));
graphics.FillRectangle(&brush,0,0,100,100);
But this doesn't work(No Rectangle created).
What could be the problem? I tried manually using LockBits and modifying the bits manually, it works well, then why it doesn't work with Graphics gdi+ operations.
Finally I managed to solve my problem. To perform gdi+ operations using Graphics object on 4 bit indexed bitmap, we need to perform following steps.
Create 4bpp HBITMAP directly or load image from file using LoadImage.
If loading from 4bpp file, then load palette from file in HPALETTE object.
Create desktop compatible dc.
Select and realize you palette in newly created dc.
select HBITMAP in your dc.
Create Graphics object using your dc.
Perform GDI+ operations on 4bpp indexed.
Though I didnt try with 8bpp but I think similar operations can be performed on 8bpp also.
Hope this help others also.
MSDN displays the following for CreatePatternBrush:
You can delete a pattern brush without
affecting the associated bitmap by
using the DeleteObject function.
Therefore, you can then use this
bitmap to create any number of pattern
brushes.
My question is the opposite. If the HBRUSH is long lived, can I delete the HBITMAP right after I create the brush? IE: does the HBRUSH store its own copy of the HBITMAP?
In this case, I'd like the HBRUSH to have object scope while the HBITMAP would have method scope (the method that creates the HBRUSH).
The HBRUSH and HBITMAP are entirely independent. The handles can be deleted entirely independent from each other, and, once created, no changes to either object will effect the other.
The brush does have its own copy of the bitmap. This is easily see by deleting the bitmap after creating the brush and then using the brush (works fine)
Using GetObject to fill a LOGBRUSH structure will return the original BITMAP handle in member lbhatch, though, and not the copy's handle, unfortunately. And using GetObject on the returned bitmap handle fails if the bitmap is deleted.
Anyone any idea how to get the original bitmap dimensions from the brush in this case? I wish to create a copy of the pattern brush even though the original bitmap is deleted. I can get a copy of the original bitmap simply by painting with the brush, but I don't know it's size. I tried using SetbrushorgEx (hdc, -1,-1), hoping the -1's would be reduced modulo its dimensions when brush selected into device context and get values when I retrieve with GetBrushOrgEx. Doesn't work.
I think the bitmap must outlive the brush: the brush just references the existing bitmap rather than copying it.
You could always try it and see what happened.
I doubt that the CreatePatternBrush() API copies the bitmap you give it, since an HBITMAP is:
a GDI handle, the maximum number of which is limited, and
potentially quite large.
Win32 and GDI tend to be conservative about creating internal copies of your data, if only because when most of their APIs were created (CreatePatternBrush() dates to Windows 95, and many functions are older still), memory and GDI handles were in much more limited supply than they are now. (For example, Windows 95 was required to run well on a system with only 4MB of RAM.)