Device Independent Bitmap (DIB)

For almost all acquisition types, a Device Independent Bitmap is returned by DTWAIN to your application (the only exception to this rule is if a buffered (memory) transfer is invoked with compression).

A Device Independent Bitmap (DIB) is a bitmap format that allows Windows to display the bitmap on any type of display device. The term 'device independent' means that the bitmap specifies pixel color in a form independent of the method used by a display to represent color.  The default filename extension of a Windows DIB file is .BMP.   When acquiring images using the native transfer mode, or if the buffered mode is used with no compression, TWAIN returns the image data that has been acquired from the device as a DIB.  Most Window imaging libraries handle DIBs extensively, so it is just a matter of the application to use the DIB correctly by passing it to the appropriate functions.

A list of Internet sites that contains functions that handle Device Independent Bitmaps

Name: ImgSource by SmallerAnimals

Web:   http://www.smalleranimals.com/isource.htm

Name: LeadTools

Web: http://www.leadtools.com

Also, if you use the Microsoft Visual C++ compiler, there are various sample programs that handle DIBs.  One of the samples is called DIBVIEW and it can be found in the Visual C++ SAMPLES directory.  The intricacies of DIB management is beyond the scope of this help file, however the DTWAIN example programs (example 1 and 2, plus the DTWDEMO example) that are available in your installation of DTWAIN show how to handle DIBs (using C and C++).

DTWAIN Data Type for a DIB

The data type for a DIB is the Windows HANDLE type.  The HANDLE data type is really a value that denotes a block of memory that contains the structure that make up the image.  DTWAIN returns the DIB memory as unlocked memory.  This means that the application must call the Windows API GlobalLock function to access the image.  A DIB consists of a BITMAPINFO structure which describes the image and color palette, immediately followed by an array of RGBQUAD values describing the actual bits of the image.

To release the memory that was allocated for the DIB, the application is responsible for calling the Windows API function GlobalFree (the GlobalUnlock function may also have to be called to unlock the memory prior to calling GlobalFree).

Who is responsible for deleting memory for a DIB?

DTWAIN leaves it the responsibility of the application to handle the DIBs correctly.  Some applications may use a third-party imaging library to display the DIB's or save the DIB's to a certain image file type.  The rationale for leaving DIB management up to the application is to ensure that the DIB is valid for whenever the application needs to use it.  For this reason, DTWAIN does not and cannot decide when to delete the DIB.  This also means that your application must handle all acquisitions from the Source, even if it is only to have the DIB deleted.  If not, the program will have severe memory leaks.