Initializes and allocates a bitmap, without loading any data.
L_LTKRN_API L_INT L_CreateBitmap(pBitmap, uStructSize, uMemory, uWidth, uHeight, uBitsPerPixel, uOrder, pPalette, uViewPerspective, pData, dwSize)
Pointer to the bitmap handle referencing the bitmap to be created.
Size in bytes, of the structure pointed to by
pBitmap, for versioning. Use sizeof(BITMAPHANDLE).
Flags that indicate the type of memory to allocate. The following are valid values:
|TYPE_CONV||[0x0001] Use conventional memory if the image will fit, otherwise swap to disk.|
|TYPE_USER||[0x0002] Create a bitmap where the user maintains the data pointer.|
|TYPE_DISK||[0x0080] Do not use conventional memory. Swap to disk only.|
|Note: If the image is allocated as TYPE_DISK, then the image should not be used in multiple threads.|
|TYPE_NODISK||[0x0100] Do not swap to disk using LEAD's virtual memory. Windows virtual memory is not affected.|
|TYPE_COMPRESSED||[0x0200] (Document and Medical Imaging toolkits) Allocate an RLE-compressed bitmap. You can use this flag with TYPE_CONV or TYPE_NODISK. For more information, refer to Speeding Up 1-Bit Documents.|
|TYPE_SUPERCOMPRESSED||[0x0400] (Document and Medical Imaging toolkits) Keep images compressed in memory. This option causes slow access, but very low memory usage. This option is available for 1-bit, 8-bit grayscale, and 24-bit images only.|
Width of the bitmap in pixels.
Height of the bitmap in pixels.
The number of bits per pixel. Valid values are 0, 1, 2, 3, 4, 5, 6, 7, 8, 12, 16, 24, 32, 48, and 64.
Use 0 to create an 8-bit grayscale bitmap. In that case, the function ignores the
Color order for 16-, 24-, 32-, 48- and 64-bit bitmaps. If the resultant bitmap is less than 16 bits per pixel, this will have no effect since palletized images have no order. Possible values are:
|ORDER_RGB|| Red, green, and blue color order in memory|
|ORDER_BGR|| Blue, green, and red color order in memory|
|ORDER_GRAY|| 12 or 16-bit grayscale image. 12 and 16-bit grayscale images are only supported in Document and Medical Imaging toolkits.|
|ORDER_ROMM|| ROMM order in memory. ROMM only supports 24 and 48-bit images.|
Pointer to the palette that the bitmap will use. You can specify your own palette, or use NULL for LEAD's fixed palette.
Where the beginning of the image is stored. Most file formats start in the lower left corner while some formats start in the upper left corner. For valid values, refer to Accounting for View Perspective.
Data pointer that will contain the bitmap data when
uMemory is TYPE_USER. This data must be aligned on a four byte boundary. If pData is NULL, the data pointer must be passed later, by calling L_SetBitmapDataPointer, before the bitmap can be used.
Size of the data buffer pointed to by
pData. This should be at least
pBitmap->Size. This parameter is only valid when
uMemory is set to TYPE_USER.
|SUCCESS||The function was successful.|
|< 1||An error occurred. Refer to Return Codes.|
Support for 12 and 16-bit grayscale images is only available in the Document and Medical Imaging toolkits.
You can specify 0 bits per pixel to create an 8-bit grayscale bitmap. In that case, the function ignores the
Creating a bitmap of type TYPE_USER does not allocate memory for the bitmap. Instead, the data pointer
pData is used.
There is some speed penalty (loss) for accessing tiled bitmaps. Therefore, it is not recommended for use with all bitmaps.
The tiled bitmaps are not used by default. LEADTOOLS will create them only if it failed to create conventional bitmaps and TYPE_NOTILED was not specified.
There are now three distinct types of bitmaps:
Conventional (uncompressed and contiguous) This is the most common type.
Compressed (1-bit only)
Tiled (uncompressed, stored internally as up to 64MB tiles)
If you pass TYPE_USER, you are responsible for freeing the bitmap data. L_FreeBitmap will not do this for you.
Some image processing functions, such as L_RotateBitmap and L_ColorResBitmap, need to re-allocate the image data. If you create a bitmap with TYPE_USER, and pass it to these functions, they will change the bitmap to TYPE_CONV and re-allocate the memory. Your original
pData will no longer be used.
If the image is allocated as TYPE_DISK, then the image should not be used in multiple threads.
Win32, x64, Linux.
This example loads a temporary bitmap, creates a new bitmap, and copies the temporary bitmap’s
image data to the new bitmap.
BITMAPHANDLE LeadBitmap; /* Bitmap handle for the final image */
BITMAPHANDLE TmpBitmap; /* Bitmap handle for the initial image */
RGBQUAD Palette; /* Palette for the final image */
/* Load a bitmap at 8 bits per pixel so that we can demonstrate palette handling */
nRet = L_LoadBitmap (MAKE_IMAGE_PATH(TEXT("ImageProcessingDemo\\Image3.cmp")), &TmpBitmap, sizeof(BITMAPHANDLE), 8, ORDER_BGR, NULL, NULL);
/* Load the new palette */
nRet = L_GetBitmapColors(&TmpBitmap, 0, 256, Palette);
/* Create the new bitmap */
nRet = L_CreateBitmap(&LeadBitmap, sizeof(BITMAPHANDLE),TYPE_CONV,
TmpBitmap.ViewPerspective, NULL, 0);
/* Copy image data to the new bitmap */
nRet = L_CopyBitmapData(&LeadBitmap, &TmpBitmap);
/* Clean up */
Medical Web Viewer .NET
.NET, Java, Android, and iOS/macOS Assemblies
C API/C++ Class Libraries