There are several types of bitmaps:
Conventional bitmaps: The most common bitmaps - support all bits/pixel and with the fastest access time. But they also require the highest amount of memory.
Compressed bitmaps: 1-bit only, using a proprietary RLE compression. They usually require less memory than the conventional bitmaps.
Super-Compressed bitmaps: 1-bit (uses Fax G4 compression) or 24-bit (uses MCMP compression) only. They require little memory but the read and write operations performed on the bitmap are slower. Also, the 24-bit compression is lossy, which means there is some small amount of degradation each the 24-bit super-compressed bitmap changes. (The 1-bit super-compressed bitmap uses lossless compression, so there is never any quality loss).
Disk bitmaps: all the bitmap data is on disk. But a memory view is used to access the disk, which causes more and more conventional memory to be used the as you read or write more bitmap pixels.
Tiled bitmaps: the bitmap is broken into separate tiles. Tiles can be disk or conventional memory.
You can specify the type of bitmap you want when you call L_CreateBitmap or L_AllocateBitmap. You can also instruct LEADTOOLS to react dynamically depending on the bitmap size or the amount of available memory using L_SetMemoryThresholds. The default memory type can only be Disk or Conventional memory.
When LEADTOOLS has to allocate a conventional bitmap, it does the following:
If the size of the bitmap being allocated is less than the fixed tile size (set through L_SetMemoryThresholds when uTileSize is > 0), the bitmap is allocated as conventional. If the allocation fails, the memory allocation function fails. If the allocation succeeds, the memory allocation function returns SUCCESS. No other steps are executed.
Checks the maximum size for a conventional bitmap (set through L_SetMemoryThresholds). If the size of the bitmap being allocated is greater than this threshold, a tiled bitmap will be allocated. Go to step 5. If the size of the bitmap being allocated is lower than the threshold, go to step 3.
Checks whether there is enough available memory to allocate a conventional bitmap. (This threshold is also set through L_SetMemoryThresholds). If there is not enough free memory, a tiled bitmap will be allocated and go to step 5. Else, go to step 4.
Try to allocate a conventional memory bitmap (bitmap which is contained entirely in conventional memory. If the allocation succeeds, the memory allocation returns success and no other steps are performed. If the allocation fails, go to step 5.
Try to allocate a tiled bitmap. There can be a mix of disk and conventional memory tiles. If the function succeeds, the allocation function returns success and no other steps are performed. If the allocation fails, go to step 6.
Try to allocate a tiled bitmap. Return success if the allocation succeeds, error otherwise.
To get the memory threshold information set by L_SetMemoryThresholds, call L_GetMemoryThresholds.
By default, the Windows temporary directory is used to store the disk files used for the disk tiles and disk images. You can change the location where these files are stored using L_SetTempDirectory. You can get the current location using L_GetTempDirectory.
Even when you have lots of RAM and enough space in the swap file, Windows might fail to allocate you one contiguous chunk of conventional memory. In this case, the bitmap will be allocated as tiled or disk.
Example: You attempt to allocate a 512MB bitmap. Windows might fail to allocate a contiguous 512MB memory chunk, but it might be able to allocate you 2x 256 MB chunks or 4x 128 MB chunks. In this case, LEADTOOLS allocates your 512MB bitmap using several smaller chunks in a tiled bitmap.
In a more extreme case, you might have not enough space to allocate the whole bitmap in conventional memory. Or you might have specified a maximum amount of conventional memory to be used with a bitmap. In either of these cases, LEADTOOLS will try to allocate a tiled bitmap with some tiles in conventional memory and others on disk.
The conventional memory tiles are always accessible (read further to see why this matters). Disk tiles will still need some chunks of conventional memory to read from disk/write to disk. We will refer to these chunks as "views". The more views you have, the more disk tiles can be accessed at a time and the faster the working with the bitmap will be. When you read or read from a disk tile, data is being cached to the view and no disk access is performed unless you move to another tile. The "move to another tile" operation is performed automatically when you read or write data to a certain row.
When you go to a disk tile that has no view, LEADTOOLS will:
create a new "view" (if you have not exceeded the maximum allowed of views and you have available memory) or
discard an old view and reassign it to the new tile. When the old view is discarded, data is written to the disk (if it has been modified since it was read). The writing of data to disk will cause a performance hit.
You can find out the memory allocation parameters for a bitmap using L_GetBitmapMemoryInfo. You can change the memory allocation parameters using L_SetBitmapMemoryInfo. The memory parameters are:
And, for tiled bitmaps only:
The number of tiles
The tile size
The number of tiles in conventional memory
The maximum number of tile views in the conventional memory (for disk tiles only)
The number of tile views in the conventional memory (for disk tiles only)
Help Collections
Raster .NET | C API | C++ Class Library | HTML5 JavaScript
Document .NET | C API | C++ Class Library | HTML5 JavaScript
Medical .NET | C API | C++ Class Library | HTML5 JavaScript
Medical Web Viewer .NET
Multimedia
Direct Show .NET | C API | Filters
Media Foundation .NET | C API | Transforms
Supported Platforms
.NET, Java, Android, and iOS/macOS Assemblies
Imaging, Medical, and Document
C API/C++ Class Libraries
Imaging, Medical, and Document
HTML5 JavaScript Libraries
Imaging, Medical, and Document