I am creating a brush using CreatePatternBrush with a bitmap created with CreateBitmap.
The bitmap is 1 pixel wide and 24 pixels tall, I have the RGB value for each pixel, so I create an array of rgbquads and pass that to CreateBitmap.
This works fine when the screen color depth is 32bpp, since the bitmap I create is also 32bpp.
When the screen color depth is not 32bpp, this fails, and I understand why it does, since I should be creating a compatible bitmap instead.
It seems I should use CreateCompatibleBitmap instead, but how do I put the pixel data I have into that bitmap?
I have also read about CreateDIBPatternBrushPt, CreateDIBitmap, CreateDIBSection, etc.
I don´t understand what is a DIBSection, and find the subject generally confusing.
I do understand that I need a bitmap with the same color depth as the screen, but how do I create it having only the 32bpp pixel data?
You could create a DIB because you can use a Device Independent Bitmap independently of the screen color depth. See CreateDIBSection().
How can you create it having only the 32bpp pixel data? A DIB can be created with 32bpp data. As you can read in the documentation:
The CreateDIBSection function creates
a DIB that applications can write to
directly. The function gives you a
pointer to the location of the bitmap
bit values.
If hSection is NULL, the system
allocates memory for the DIB. If the
function succeeds, the return value is
a handle to the newly created DIB, and
*ppvBits points to the bitmap bit values.
Try something like this:
VOID *ppvBits = NULL;
BITMAPINFO BitmapInfo;
memset(&BitmapInfo, 0, sizeof(BITMAPINFOHEADER));
BitmapInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
BitmapInfo.bmiHeader.biWidth = 1;
BitmapInfo.bmiHeader.biHeight = 24;
BitmapInfo.bmiHeader.biPlanes = 1;
BitmapInfo.bmiHeader.biBitCount = 32;
BitmapInfo.bmiHeader.biCompression = BI_RGB;
HBITMAP hBitmap = CreateDIBSection(hDC, &BitmapInfo, DIB_RGB_COLORS, &ppvBits, NULL, 0);
In our case *ppvBits points to 1 * 24 * (32 / 8) allocated bytes.
It is important to know that if biHeight is positive, the bitmap is a bottom-up DIB and its origin is the lower-left corner. See BITMAPINFOHEADER Structure for more info.
I solved it by using CreateCompatibleBitmap and SetPixel. Not the best option I guess, but it works.
Related
I created an app in which I want to display text on top of google maps. I chose to use custom markers, but they can only be images, so I decided to create an image from my text utilizing SkiaSharp.
private static ImageSource CreateImageSource(string text)
{
int numberSize = 20;
int margin = 5;
SKBitmap bitmap = new SKBitmap(30, numberSize + margin * 2, SKImageInfo.PlatformColorType, SKAlphaType.Premul);
SKCanvas canvas = new SKCanvas(bitmap);
SKPaint paint = new SKPaint
{
Style = SKPaintStyle.StrokeAndFill,
TextSize = numberSize,
Color = SKColors.Red,
StrokeWidth = 1,
};
canvas.DrawText(text.ToString(), 0, numberSize, paint);
SKImage skImage = SKImage.FromBitmap(bitmap);
SKData data = skImage.Encode(SKEncodedImageFormat.Png, 100);
return ImageSource.FromStream(data.AsStream);
}
The images I create however have ugly artifacts on the top of the resulting image and my feeling is that they get worse if I create multiple images.
I built an example app, that shows the artifacts and the code I used to draw the text. It can be found here:
https://github.com/hot33331/SkiaSharpExample
How can I get rid of those artifacts. Am I using skia wrong?
I got the following answer from Matthew Leibowitz on the SkiaSharp GitHub:
The chances are you are not clearing the canvas/bitmap first.
You can either do bitmap.Erase(SKColors.Transparent) or canvas.Clear(SKColors.Transparent) (you can use any color).
The reason for this is performance. When creating a new bitmap, the computer has no way of knowing what background color you want. So, if it was to go transparent and you wanted white, then there would be two draw operations to clear the pixels (and this may be very expensive for large images).
During the allocation of the bitmap, the memory is provided, but the actual data is untouched. If there was anything there previously (which there will be), this data appears as colored pixels.
When I've seen that before, it's been because the memory passed to SkiaSharp was not zeroed. As an optimization, though, Skia assumes that the memory block passed to it is pre zeroed. Resultingly, if your first operation is a clear, it will ignore that operation, because it thinks that the state is already clean. To resolve this issue, you can manually zero the memory passed to SkiaSharp.
public static SKSurface CreateSurface(int width, int height)
{
// create a block of unmanaged native memory for use as the Skia bitmap buffer.
// unfortunately, this may not be zeroed in some circumstances.
IntPtr buff = System.Runtime.InteropServices.Marshal.AllocCoTaskMem(width * height * 4);
byte[] empty = new byte[width * height * 4];
// copy in zeroed memory.
// maybe there's a more sanctioned way to do this.
System.Runtime.InteropServices.Marshal.Copy(empty, 0, buff, width * height * 4);
// create the actual SkiaSharp surface.
var colorSpace = CGColorSpace.CreateDeviceRGB();
var bContext = new CGBitmapContext(buff, width, height, 8, width * 4, colorSpace, (CGImageAlphaInfo)bitmapInfo);
var surface = SKSurface.Create(width, height, SKColorType.Rgba8888, SKAlphaType.Premul, bitmap.Data, width * 4);
return surface;
}
Edit: btw, I assume this is a bug in SkiaSharp. The samples/apis that create the buffer for you should probably be zeroing it out. Depending on the platform it can be hard to repro as the memory alloc behaves differently. More or less likely to provide you untouched memory.
I created a bitmap using CreateDIBSection and specified .biWidth = 100 ; .biHeight = 100 like this pseudo-code :
pBitmapInfo->bmiHeader.biWidth = 100;
pBitmapInfo->bmiHeader.biHeight = 100;
....
CreateDIBSection(DibDC, pBitmapInfo, DIB_RGB_COLORS, 0, 0, 0);
Later, i want to reuse this bitmap, just change the bitmap size to 300x100 (and may clear the old image because i don't need it anymore). Many one say I need to create a new bitmap with new size and delete the old bitmap. But I expected in someway that we can re-use the old bitmap. I don't want to re-create a new bitmap because it cause slow performance while i need to do it repeatly many times. So is there any way to change the bitmap size without re-create a new bitmap?
If you are worried about performance it is indeed not a good idea to keep destroying and creating bitmaps.
There is however an easier solution. Simply create a pool of bitmaps in predefined sizes and use bitmaps from the pool as needed.
If you have a long lived DC, you can use:
hBitmap100x100 = CreateCompatibleBitmap(MyDC, 100,100);
hBitmap300x300 = CreateCompatibleBitmap(MyDC, 300,300);
If you keep changing DC's then use a DIB section
hBitmap100x100 = CreateDIBSection(DibDC, pBitmapInfo100x100, DIB_RGB_COLORS, null, 0, 0);
hBitmap300x300 = CreateDIBSection(DibDC, pBitmapInfo100x100, DIB_RGB_COLORS, null, 0, 0);
Just keep reusing these over and over.
You can even have a dozen of them in an array if you like.
You create them at program startup and dispose of them when done.
Just to learn Windows API, I'm trying to use a cheap fingerprint device I bought.
The library that came with it captures the fingerprint as an 8bit bitmap of 256x280 pixels and stores the raw pixels in a buffer.
I'm trying to copy this raw pixel stream into a Device Independent Bitmap (DIB) and then trying to use this DIB to draw onto a window.
I managed to display the image but the colors are all wrong. Heres the piece of code that handles the painting.
PAINTSTRUCT ps;
HDC hdc,memDC;
HBITMAP cp_bmp;
HBITMAP di_bmp;
BITMAPINFO di_bmp_info;
void *di_bmp_data;
int ptr;
int x,y;
int aux;
ZeroMemory(&di_bmp_info,sizeof(BITMAPINFO));
di_bmp_info.bmiHeader.biSize=sizeof(BITMAPINFOHEADER);
di_bmp_info.bmiHeader.biWidth=256;
di_bmp_info.bmiHeader.biHeight=280;
di_bmp_info.bmiHeader.biPlanes=1;
di_bmp_info.bmiHeader.biBitCount=8;
di_bmp_info.bmiHeader.biCompression=BI_RGB;
hdc=BeginPaint(hwnd,&ps);
// create the DIB
di_bmp=CreateDIBSection(hdc,&di_bmp_info,DIB_RGB_COLORS,&di_bmp_data,NULL,0);
// Copy the original bitstream onto the DIB
CopyMemory(di_bmp_data,fingerprint,256*280);
// create the mem dc
memDC=CreateCompatibleDC(hdc);
// create the DDB
cp_bmp=CreateCompatibleBitmap(hdc,256,280);
SelectObject(memDC,cp_bmp);
SetDIBits(memDC,cp_bmp,0,280,di_bmp_data,&di_bmp_info,DIB_RGB_COLORS);
BitBlt(hdc,10,10,256,280,memDC,0,0,SRCCOPY);
DeleteObject(cp_bmp);
EndPaint(hwnd,&ps);
Curious fact is that when I change the di_bmp_info.bmiHeader.biBitCount to 32, the colors display perfectly but the image gets smaller in size and gets repeated around 5 or six times horizontally.
Im stuck!. Thanks in advance.
In short, you have an indexed bitmap (each pixel is not an RGB value but instead an index into a defined palette of colors) and you haven't provided a palette for it to use.
BITMAPINFO is a variable sized structure - a BITMAPINFOHEADER, followed by at least one but potentially more RGBQUAD structures. For indexed bitmap depths (8 bpp and below), a palette needs to be provided following the BITMAPINFOHEADER in memory.
The number of palette entries required is determined by the biBitCount and biClrUsed fields. If biClrUsed is 0 the number of palette entries must be 1 << biBitCount, or 256 in the case of 8bpp. Setting biClrUsed to something other than 0 lets you provide fewer palette entries if the bitmap doesn't need them.
Because you haven't set biClrUsed a full 256 color palette is assumed to follow the BITMAPINFOHEADER in memory and essentially random memory is being used.
BITMAPINFO provides only a single RGBQUAD itself so you need to extend the structure to provide the rest, for example:
struct MyBitmapInfo
{
BITMAPINFOHEADER bmiHeader;
RGBQUAD palette[256];
};
Where you actually get the palette from is up to you, but you could e.g. use a grayscale palette like this:
struct MyBitmapInfo di_bmp_info;
ZeroMemory(&di_bmp_info,sizeof(struct MyBitmapInfo));
di_bmp_info.bmiHeader.biSize=sizeof(BITMAPINFOHEADER);
di_bmp_info.bmiHeader.biWidth=256;
di_bmp_info.bmiHeader.biHeight=280;
di_bmp_info.bmiHeader.biPlanes=1;
di_bmp_info.bmiHeader.biBitCount=8;
di_bmp_info.bmiHeader.biCompression=BI_RGB;
// initialise greyscale palette
for (int i = 0; i < 256; i++)
{
di_bmp_info.palette[i].rgbRed =
di_bmp_info.palette[i].rgbGreen =
di_bmp_info.palette[i].rgnBlue = i;
}
Here is some minimal code to show an issue:
static const int MAX_WIDTH = 320;
static const int MAX_HEIGHT = 320;
Gdiplus::Bitmap foregroundImg(MAX_WIDTH,MAX_HEIGHT,PixelFormat32bppPARGB);
{
Gdiplus::Graphics g(&foregroundImg);
g.Clear(Gdiplus::Color(10,255,255,255));
}
Gdiplus::Bitmap softwareBitmap(MAX_WIDTH,MAX_HEIGHT,PixelFormat32bppPARGB);
Gdiplus::Graphics g(&softwareBitmap);
g.SetCompositingMode(Gdiplus::CompositingModeSourceOver);
g.SetCompositingQuality(Gdiplus::CompositingQualityDefault);
g.Clear(Gdiplus::Color(255,0,0,0));
g.DrawImage(foregroundImg,0,0);
CLSID encoder;
GetEncoderClsid(L"image/png",&encoder);
softwareBitmap.Save(L"d:\\image.png",&encoder);
As result I'm getting image filled by RGB values equals to 10. It seems GDI+ uses the conventional algorithm:
255*(10/255) + 0*(1-10/255) == 10.
But I'm expecting that premultiplied algorithm will be used (because foreground image has the premultiplied PixelFormat32bppPARGB format):
255 + 0*(1-10/255) == 255
So my question, why GDI+ uses conventional formula when image is in premultiplied alpha format? And is there any workaround to make GDI+ to use the premultiplied alpha algorithm?
The format of your foreground image doesn't matter (given that it has alpha) because you're setting it to a Gdiplus::Color. Color values are defined as non-premultiplied, so gdiplus multiplies the components by the alpha value when it clears the foreground image. The alternative would be for Color values to have different meaning depending on the format of the render target, and that way lies madness.
You might be able to do what you intend by setting the source image bits directly, or you might not. Components with values greater than 100% aren't really valid in gdiplus's rendering model, so I'd not be surprised if it caps them during rendering. If you really want this level of control over the rendering, you'll have to lock the bitmap bits and do it yourself.
I'm trying to get the pixels of a bitmap using the GetDIBits function. As I have not studied the Windows GDI/API, I'm very unsure about the first argument, HDC. I've searched countless posts here on SO and the web but have been unable to find information or example about how to initialize HDC in this specific case. Here's how far I've gone reading pixel values:
HBITMAP hBitmap = (HBITMAP) LoadImage(0, L"C:/tmp/Foo.bmp" ,IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE);
// check hBitmap for error
BITMAP bm;
::GetObject( hBitmap , sizeof(bm) , &bm );
// TODO: GetDIBits()
Solution:
After scouring the web some more I've been able to cobble together the following:
/* Omitting error checks for brevity */
HDC dcBitmap = CreateCompatibleDC ( NULL );
SelectObject( dcBitmap, hBitmap );
BITMAPINFO bmpInfo;
bmpInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
bmpInfo.bmiHeader.biWidth = bm.bmWidth;
bmpInfo.bmiHeader.biHeight = -bm.bmHeight;
bmpInfo.bmiHeader.biPlanes = 1;
bmpInfo.bmiHeader.biBitCount = 24;
bmpInfo.bmiHeader.biCompression = BI_RGB;
bmpInfo.bmiHeader.biSizeImage = 0;
COLORREF* pixel = new COLORREF [ bm.bmWidth * bm.bmHeight ];
GetDIBits( dcBitmap , hBitmap , 0 , bm.bmHeight , pixel , &bmpInfo , DIB_RGB_COLORS );
The source bitmap is typically a device-dependent bitmap. Although it's less common nowadays, that might mean that the bitmap's pixel values are stored as indexes into a color table. In those cases GetDIBits would need access to the color table, which is stored in a device context.
If your bitmap uses RGB values instead of indexes, then the device context should be irrelevant, though in my experience you must still provide a valid one (see What is the HDC for in GetDIBits?), perhaps it looks at other aspects of the device context, like the color depth.
Is your goal to get the pixel color values, or to call GetDIBits? If you just want the pixel content, you can use GetObject to get the BITMAP structure corresponding to your HBITMAP handle, the bmBits pointer in that structure gives access to the pixels (note: it will be in the bitmap's original format, which might not be 24bpp, so check the other fields of the structure to see what the format is).