C++ object for Device Independent Bitmaps

[David Cox]

Device independent bitmaps or DIBs consist of header information followed by
some number of color table entries followed by some number of pixels. The
number of color table entries and the number of pixels can only be
determined at runtime and must be stored in a block of memory immediately
following the header info. How would you model this in C++?

It is easy to create a C++ class called Bitmap that contains the header
information. But what about the color table and pixel array that are to
follow the header? Because their sizes cannot be determined until runtime,
what should be done with them?

class Bitmap {
// header info
// color table (size to be determined at runtime)
// pixels (size to be determined at runtime)
}

Is there a way to change a class definition at runtime? For example, at
compile time the color table would be declared as an array of 1 as well as
the array of pixels. Then at runtime, the color table would be redefined as
an array of 256 while the pixel array would be redefined to the number of
pixels. I don't think this is possible to do, but I thought I would ask.
What would be a good technique to handle this situation?

Thanks,
David

[benben]

"David Cox" <an*******@nowhere.com> wrote in message
news:l_*********************@twister.southeast.rr. com...

Device independent bitmaps or DIBs consist of header information followed by some number of color table entries followed by some number of pixels. The
number of color table entries and the number of pixels can only be
determined at runtime and must be stored in a block of memory immediately
following the header info. How would you model this in C++?

Design a class, manage a trunk of raw memory (the bitmap), then hold a
couple of pointers to the start of serveral sections in the trunk.
It is easy to create a C++ class called Bitmap that contains the header
information. But what about the color table and pixel array that are to
follow the header? Because their sizes cannot be determined until runtime, what should be done with them?

class Bitmap {
// header info
// color table (size to be determined at runtime)
// pixels (size to be determined at runtime)
}
class Bitmap
{
struct header
{
//...
};

struct color_entry
{
// ...
};

struct pixel
{
//...
};

header* p_header;
color_entry* color_entries;
pixel* pixels;

// ...
};

Is there a way to change a class definition at runtime? For example, at
compile time the color table would be declared as an array of 1 as well as
the array of pixels. Then at runtime, the color table would be redefined as an array of 256 while the pixel array would be redefined to the number of
pixels. I don't think this is possible to do, but I thought I would ask.
What would be a good technique to handle this situation?

Thanks,
David

[Cy Edmunds]

"David Cox" <an*******@nowhere.com> wrote in message
news:l_*********************@twister.southeast.rr. com...

Device independent bitmaps or DIBs consist of header information followed
by
some number of color table entries followed by some number of pixels. The
number of color table entries and the number of pixels can only be
determined at runtime and must be stored in a block of memory immediately
following the header info. How would you model this in C++?

It is easy to create a C++ class called Bitmap that contains the header
information. But what about the color table and pixel array that are to
follow the header? Because their sizes cannot be determined until
runtime,
what should be done with them?
I would dynamically allocate the memory needed.

class Bitmap {
// header info
// color table (size to be determined at runtime)
// pixels (size to be determined at runtime)
}
class Bitmap {
// header info
// pointer to color table (allocated at runtime)
// pointer to pixels (allocated at runtime)
}

[snip]

Thanks,
David

Here is a C language solution:

http://astronomy.swin.edu.au/~pbourke/dataformats/bmp/

When I needed a C++ class to read and write bmp files I just wrote a wrapper
for this code. It worked fine.

--
Cy
http://home.rochester.rr.com/cyhome/

[David Cox]

Has anyone tried using placement new with DIBs? I am thinking along the
lines of allocating a buffer for the entire DIB. Then use placement new to
point a header pointer to the first byte of the DIB, point an RGBQUAD
pointer to the first byte of the color table and a pixel pointer to the
first pixel.

These pointers would be private members of a Bitmap class and public
functions would manipulate the DIB with them.

"David Cox" <an*******@nowhere.com> wrote in message
news:l_*********************@twister.southeast.rr. com...

Device independent bitmaps or DIBs consist of header information followed by some number of color table entries followed by some number of pixels. The
number of color table entries and the number of pixels can only be
determined at runtime and must be stored in a block of memory immediately
following the header info. How would you model this in C++?

It is easy to create a C++ class called Bitmap that contains the header
information. But what about the color table and pixel array that are to
follow the header? Because their sizes cannot be determined until runtime, what should be done with them?

class Bitmap {
// header info
// color table (size to be determined at runtime)
// pixels (size to be determined at runtime)
}

Is there a way to change a class definition at runtime? For example, at
compile time the color table would be declared as an array of 1 as well as
the array of pixels. Then at runtime, the color table would be redefined as an array of 256 while the pixel array would be redefined to the number of
pixels. I don't think this is possible to do, but I thought I would ask.
What would be a good technique to handle this situation?

Thanks,
David

[James Aguilar]

It seems like it would be just as safe to simply reinterpret_cast
pointers to structs from a big allocated block. You just have to make
sure that you don't clobber the data from a later section when
manipulating the section before, but that shouldn't be any worse than
the care you have to take normally.

[James Aguilar]

Actually, it seems I lied. Reinterpret cast is never safe. All the
same, if portability is no concern, then it will probably work. Also,
placement delete (to match up with your placement news) is said to be
unavailable on some platforms, so I don't know if you're any better off
that way.

[macklin01]

Hi, I stumbled across this thread on a google search.

For what it's worth, I've written a class that does the sort of thing that you're describing. It's not terrific, but you can get it at http://easybmp.sourceforge.net.

The type of structure I'd use for such a class, if you were going to write it from scratch:

class BMP
{
 private:
  RGBQUAD* Colors;
  RGBQUAD** Pixels;
  int Width;
  int Height;
  int BitDepth;
 public:
  BMP();
  ~BMP();
  RGBQUAD GetPixel( int i, int j);
  void SetPixel( int i, int j, RGBQUAD NewColor );
  RGBQUAD GetColor( int i );
  void SetColor( int i, RGBQUAD NewColor );
  int TellWidth( void );
  int TellHeight( void );
  int TellBitDepth( void );
  void SetSize( int NewWidth, int NewHeight );
  void SetBitDepth( int NewBitDepth );
  void ReadFromFile( char* FileName );
  void WriteToFile( char* FileName );
}

There's no real reason to store the BITMAPINFOHEADER and BITMAPFILEHEADER info with the class; these can be generated when saving or loading a file. You can allocate memory for Pixels in the default constructor, ReadFromFile(), or in SetSize(). Also, you can allocate memory for the Colors in default constructor, ReadFromFile(), or SetBitDepth(). Colors should be NULL if BitDepth = 24 or BitDepth = 32. (Those would be logical places to do that.)

Also, I've always found it useful to treat bitmaps internally as 32-bit files, and only differentiate when reading or writing them. (Makes it easier to copy/paste between two different images, etc.)

I hope this is somewhat helpful. It can be a lot of fun to design such a class, and very reusable. :) Best of luck -- Paul