Free Technical Articles

Write HBITMAP Object in to BMP File

2008-07-26T07:57:00.000-07:00

The following Visual C++ code segment can be used to save a HBITMAP object in to BMP file format.

void WriteBMPFile(HBITMAP bitmap, LPTSTR filename, HDC hDC)
{
BITMAP bmp;
PBITMAPINFO pbmi;
WORD cClrBits;
HANDLE hf; // file handle
BITMAPFILEHEADER hdr; // bitmap file-header
PBITMAPINFOHEADER pbih; // bitmap info-header
LPBYTE lpBits; // memory pointer
DWORD dwTotal; // total count of bytes
DWORD cb; // incremental count of bytes
BYTE *hp; // byte pointer
DWORD dwTmp;

// create the bitmapinfo header information

if (!GetObject( (bitmap, sizeof(BITMAP), (LPSTR)&bmp)){
AfxMessageBox("Could not retrieve bitmap info");
return;
}

// Convert the color format to a count of bits.
cClrBits = (WORD)(bmp.bmPlanes * bmp.bmBitsPixel);
if (cClrBits == 1)
cClrBits = 1;
else if (cClrBits <= 4)
cClrBits = 4;
else if (cClrBits <= 8)
cClrBits = 8;
else if (cClrBits <= 16)
cClrBits = 16;
else if (cClrBits <= 24)
cClrBits = 24;
else cClrBits = 32;
// Allocate memory for the BITMAPINFO structure.
if (cClrBits != 24)
pbmi = (PBITMAPINFO) LocalAlloc(LPTR,
sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD) * (1<< cClrBits));
else
pbmi = (PBITMAPINFO) LocalAlloc(LPTR, sizeof(BITMAPINFOHEADER));

// Initialize the fields in the BITMAPINFO structure.

pbmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
pbmi->bmiHeader.biWidth = bmp.bmWidth;
pbmi->bmiHeader.biHeight = bmp.bmHeight;
pbmi->bmiHeader.biPlanes = bmp.bmPlanes;
pbmi->bmiHeader.biBitCount = bmp.bmBitsPixel;
if (cClrBits < 24)
pbmi->bmiHeader.biClrUsed = (1<
// If the bitmap is not compressed, set the BI_RGB flag.
pbmi->bmiHeader.biCompression = BI_RGB;

// Compute the number of bytes in the array of color
// indices and store the result in biSizeImage.
pbmi->bmiHeader.biSizeImage = (pbmi->bmiHeader.biWidth + 7) /8 * pbmi->bmiHeader.biHeight * cClrBits;
// Set biClrImportant to 0, indicating that all of the
// device colors are important.
pbmi->bmiHeader.biClrImportant = 0;

// now open file and save the data
pbih = (PBITMAPINFOHEADER) pbmi;
lpBits = (LPBYTE) GlobalAlloc(GMEM_FIXED, pbih->biSizeImage);

if (!lpBits) {
AfxMessageBox("writeBMP::Could not allocate memory");
return;
}

// Retrieve the color table (RGBQUAD array) and the bits
if (!GetDIBits(hDC, HBITMAP(bitmap), 0, (WORD) pbih->biHeight, lpBits, pbmi,
DIB_RGB_COLORS)) {
AfxMessageBox("writeBMP::GetDIB error");
return;
}

// Create the .BMP file.
hf = CreateFile(filename, GENERIC_READ | GENERIC_WRITE, (DWORD) 0,
NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL,
(HANDLE) NULL);
if (hf == INVALID_HANDLE_VALUE){
AfxMessageBox("Could not create file for writing");
return;
}
hdr.bfType = 0x4d42; // 0x42 = "B" 0x4d = "M"
// Compute the size of the entire file.
hdr.bfSize = (DWORD) (sizeof(BITMAPFILEHEADER) +
pbih->biSize + pbih->biClrUsed
* sizeof(RGBQUAD) + pbih->biSizeImage);
hdr.bfReserved1 = 0;
hdr.bfReserved2 = 0;

// Compute the offset to the array of color indices.
hdr.bfOffBits = (DWORD) sizeof(BITMAPFILEHEADER) +
pbih->biSize + pbih->biClrUsed
* sizeof (RGBQUAD);

// Copy the BITMAPFILEHEADER into the .BMP file.
if (!WriteFile(hf, (LPVOID) &hdr, sizeof(BITMAPFILEHEADER),
(LPDWORD) &dwTmp, NULL)) {
AfxMessageBox("Could not write in to file");
return;
}

// Copy the BITMAPINFOHEADER and RGBQUAD array into the file.
if (!WriteFile(hf, (LPVOID) pbih, sizeof(BITMAPINFOHEADER)
+ pbih->biClrUsed * sizeof (RGBQUAD),
(LPDWORD) &dwTmp, ( NULL))){
AfxMessageBox("Could not write in to file");
return;
}

// Copy the array of color indices into the .BMP file.
dwTotal = cb = pbih->biSizeImage;
hp = lpBits;
if (!WriteFile(hf, (LPSTR) hp, (int) cb, (LPDWORD) &dwTmp,NULL)){
AfxMessageBox("Could not write in to file");
return;
}

// Close the .BMP file.
if (!CloseHandle(hf)){
AfxMessageBox("Could not close file");
return;
}

// Free memory.
GlobalFree((HGLOBAL)lpBits);
}

2008-06-01T02:43:00.000-07:00

Program to Copy Screen to HBITMAP Object

The following code segment can be used to copy a portion or full screen in to a HBITMAP GDI object in visual C++. This code is tested on Visual C++ 6.0

HBITMAP CopyScreenToBitmap(int x1, int y1, int x2, int y2)
{
HDC hScrDC, hMemDC; // screen DC and memory DC
HBITMAP hBitmap, hOldBitmap; // handles to deice-dependent bitmaps
int nX, nY, nX2, nY2; // coordinates of rectangle to grab
int nWidth, nHeight; // DIB width and height
int xScrn, yScrn; // screen resolution

// create a DC for the screen and create
// a memory DC compatible to screen DC

if((hScrDC = CreateDC("DISPLAY", NULL, NULL, NULL))==NULL){
AfxMessageBox("Can not create display DC");
return NULL;
}
if((hMemDC = CreateCompatibleDC(hScrDC))==NULL)
{
AfxMessageBox("Can not create compatible DC");
return NULL;
}

// get points of rectangle to grab

nX = x1;
nY = y1;
nX2 = x2;
nY2 = y2;

// get screen resolution

xScrn = GetDeviceCaps(hScrDC, HORZRES);
yScrn = GetDeviceCaps(hScrDC, VERTRES);

//make sure bitmap rectangle is visible

if (nX < 0)
nX = 0;
if (nY < 0)
nY = 0;
if (nX2 > xScrn)
nX2 = xScrn;
if (nY2 > yScrn)
nY2 = yScrn;

nWidth = nX2 - nX;
nHeight = nY2 - nY;

// create a bitmap compatible with the screen DC
if((hBitmap = CreateCompatibleBitmap(hScrDC, nWidth, nHeight))==NULL)
{
AfxMessageBox("Can not create compatible bitmap");
return NULL;
}

// select new bitmap into memory DC
hOldBitmap = (HBITMAP)SelectObject(hMemDC, hBitmap);

if(hOldBitmap == NULL)
{
AfxMessageBox("Can not select old object");
return NULL;
}

// bitblt screen DC to memory DC
if(!BitBlt(hMemDC, 0, 0, nWidth, nHeight, hScrDC, nX, nY, SRCCOPY))
{
AfxMessageBox("Can not read screen memory");
return NULL;
}

// select old bitmap back into memory DC and get handle to bitmap of the screen

hBitmap = (HBITMAP)SelectObject(hMemDC, hOldBitmap);
if(hBitmap == NULL)
{
AfxMessageBox("Can not select object");
return NULL;
}
// clean up
DeleteDC(hScrDC);
DeleteDC(hMemDC);

// return handle to the bitmap

return hBitmap;
}

2008-05-16T20:57:00.000-07:00

Five Point Agenda for Software Development

With day to day modernization, our systems are becoming more complex in nature. It is true for software also. Compare today’s software with the software developed 20 years back. There is a huge difference in appearance, features, ease of use, robustness and many more things. In our early days, normal practices of software development with Waterfall life cycle was followed. Intense requirement analysis followed by architectural design, coding, testing phases and finally deployment of the product was carried out.

This development practice had its drawbacks. It was found that requirements were changing with the course of time and it became difficult to make changes in the design at later stages. Integration problems were also encountered at final stages of the development life cycle. Due to ambiguous communication among the user and the development team the development deviated from the actual user requirement. The total management of the software development process was hard to maintain.

Finally it was realized that software development methodologies that could help to overcome all these kinds of anomalies should be chosen. There should be a common language that should be used for communication among different parties. After carrying out studies in latest trends in software engineering the strength of other methodologies for software development was realized. Importance of CASE tools in software management during the entire development life cycle is also realized.

The CASE tools like Rational Rose® are being used nowadays very effectively for software development process. The CASE tool uses the Unified Modeling Language (UML) for visualizing, specifying, constructing and documenting the artifacts of a software.

The five point agenda that most of the CASE tools recommend is discussed below.

1. Iterative Development

The software should be developed incrementally in an iterative fashion. Each iteration results in an executable release. In iterative development, it is very easy to handle requirement changes even at the later stages.

2. Requirements Management

Requirements are managed systematically so that finding, documenting, organizing, and tracking a system's changing requirements becomes easy. This can be done manually or using CASE tools.

3. Use of Component architecture

The component based architecture must be used to reduce the effective size and complexity of the solution. The reusable components not only helps in fast development of the software but also increases robustness.

4. Visual Modeling using UML

The modeling of the software should be done using UML notations which helps in visualizing, specifying, constructing, and document the structure and behavior of a system's architecture. The use of UML keeps the end user, software architect, software developer etc. on the same platform. UML is the common language. Everybody must talk in UML.

5. Continuously Verify Quality

The quality must be verified in every iteration. It helps in the detection of inconsistencies present in the software design.

These five points agenda can be used in managing and controlling the entire software development process. Practicing these guidelines enhances our capabilities day by day.

2008-05-10T00:08:00.000-07:00

Introduction to MPEG Video

Digital techniques have made rapid progress in audio and video. Digital Information is more robust and error resilient. This means that generation losses during recording and losses in transmission can be eliminated. The compact disk (CD) was the first consumer product to demonstrate this. Digital recording and transmission techniques allow content manipulation that is not possible in analog. Once audio or video is digitized, the contents are in the form of data. Such data can be handled in the same way as any other kind of data. However, production standard digital video generates over 200 megabits per second of data, and this bit rate requires extensive capacity for storage and wide bandwidth for transmission. This extensive storage and bandwidth requirement can be reduced by compression. Compression is a way of expressing digital audio and video by using less data.

MPEG is one of the most popular audio/video compression techniques because it is not just a single standard. Instead, It is a range of standards suitable for different applications but based on similar principles. MPEG is an acronym for the Moving Picture Expert Group established by ISO (International Standards Organization) and IEC (International Electrotechnical Commission). A video is a sequence of pictures and each picture is an array of pixels. This video data is organized in a hierarchical fashion in an MPEG video stream. MPEG video sequence consists of different layers, GOP, Pictures, Slices, Macroblock, Block.

Video Sequence
Begins with a sequence header, includes one or more groups of pictures, and ends with an end-of-sequence code.

Group of Pictures (GOP)
A header and a series of one or more pictures intended to allow random access into the sequence.

Picture
This is primary coding unit of a video sequence. A picture consists of three rectangular matrices representing luminance (Y) and two chrominance (Cb and Cr) values. The Y matrix has an even number of rows and columns. The Cb and Cr matrices are one half the size of the Y matrix in horizontal and vertical directions.

Slice
It contains one or more contiguous macroblocks. The order of the macroblocks within a slice is from left to right and top to bottom. Slices are important in the handling of errors. If the bitstream contains an error, the decoder can skip to start of the next slice.

Macroblock
This is basic coding unit in the MPEG algorithm. It is a 16x16 pixel segment in a frame. If each chrominance component has one-half the vertical and horizontal resolution of the luminance component, a macroblock consists of four Y, one Cr, and one Cb block.

Block
This is smallest coding unit in the MPEG algorithm. It consists of 8x8 pixels and can be one of three types: luminance(Y), red chrominance(Cr), or blue chrominance(Cb).

Picture Types
The MPEG standard specifically defines three types of pictures:
Intra Pictures (I-Pictures)
Predicted Pictures (P-Pictures)
Bidirectional Pictures (B-Pictures)

These three types of pictures are combined to form a group of picture (GOP). Typical GOP structures are as follows:

IBBPBBPBBPBBPI……
IPPIPPIPPIPPIP……
IIIIIIIIIIIIII……

Intra Pictures
Intra pictures, or I-Pictures, are coded using only information present in the picture itself, and provides potential random access points into the compressed video data. It uses only transform coding and provide moderate compression.

Predicted Pictures
Predicted pictures, or P-Pictures, are coded with respect to the nearest previous I or P-Pictures. This technique is called forward prediction. P-Pictures use motion compensation to provide more compression than is possible with I-pictures.

Bidirectional Pictures
Bidirectional pictures, or B-pictures, are pictures that use both a past and future picture as a reference. This technique is called bidirectional prediction. B-pictures provide the most compression since it uses the past and future picture as a reference, however the computation time is largest.

Encoding Intra Picture
The MPEG transform coding algorithm for Intra picture includes the following
steps:
• Discrete cosine transform (DCT)
• Quantization
• Run-length encoding

The 8x8 block in a picture generally contains high spatial redundancy. To reduce this redundancy, the MPEG algorithm transforms 8x8 blocks of pixels from the spatial domain to the frequency domain with the discrete cosine transform (DCT). The combination of DCT and quantization results in many of the high frequency coefficients being zero. To take maximum advantage of this, the coefficients are organized in a zigzag order to produce long runs of zero. This zigzag sequence is then coded with a variable length code (Huffman Encoding), which uses shorter coded for commonly occurring pairs and longer codes for less common pairs.

Encoding of Predicted Picture
A P-picture is coded with reference to a previous image (reference image) that is an I or P pictures. Motion compensation based prediction is used to exploit the temporal redundancy. Since the frames are closely related, it is possible to accurately represent or predict the data of one frame based on the data of a reference image, provided the translation is estimated. This translation is known as motion vector of macroblock. In P pictures, each 16x16 sized macroblock is predicted from a macroblock of a previously encoded I picture. A search is conducted in the I frame to find the macroblock which closely matches the macroblock under consideration in the P frame. The difference between two macroblock is the prediction error. This error can be coded in the DCT domain and quantized. Finally it uses the run-length encoding and Huffman encoding to encode the data.

Encoding of Bi-directional Pictures
A B picture is bidirectional predicted picture. Two frames are used to predict the current B picture, the previous frame and the next frame. Hence B pictures are coded like P pictures except the motion vectors can reference either the previous reference picture, the next picture, or both. Consider a B picture B. B will be predicted from two reference frames R1 and R2. R1 is previous I/P picture and R2 is next I/P picture. For each macroblock MB of B, find the closest match MB1 in R1 and MB2 in R2. The predicted macroblock, PM is calculated as given below.

PM = NINT (a1 MB1 + a2 MB2)
where,
NINT is nearest integer operator and a1 and a2 are described below.
a1 = 0.5 and a2 = 0.5 if both matches are satisfactory.
a1 = 1 and a2 = 0 if only first match is satisfactory.
a1 = 0 and a2 = 1 if only second match is satisfactory.
a1 = 0 and a2 = 0 if neither match is satisfactory.

Finally the error block E is computed by taking the difference of MB and PM. This error block E is coded as per Intra coding standards.