Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How would you implement / design a class which has to represent a bitmap? I'm stuck at handling the different possible color modes and I keep thinking that this should be somehow implementable using templates / design patterns in an elegant AND efficient way:

Suppose you have a file.bmp. You then want to open that file to use it in your application:

Bitmap myBitmap();

The bitmap you just opened could have RGB colors, or it could be a grayscale image, or even a 1 bit per pixel image (i.e. black and white). In my application, I want to operate on the image (pixel) data. For example, I need some sort of brightness filter where I black out pixels whose (Red + Blue + Green) / 3 is below some filter value (i.e. 100).

So I need access to the pixels:

Pixel somePixel = myBitmap.pixelAt(10,30);

But now I face the problem of NOT knowing what type of pixel this is. Of course, I could provide subclasses of Pixel (which then is an abstract base class) which ALL implement methods like getRGB(), getGrayScale(), ... where each subclass gives a way of converting between those colormodes (i.e. RGB to grayscale)

But this feels ... hm, "wrong".

Do you know some good way to implement this?

A nice feature I was thinking about is something like:

myBitmap.getMode(); // A RGBMode object, RGBMode being a subclass of Mode
myBitmap.setMode(new BlackWhiteMode()); // Converts the bitmap to a 1bpp image

Any ideas, recommendations, improvements?

So the really hard part is to represent the different color modes, like RGB (8bit and 4bit), HSV, Grayscale, BlackWhite, ... without messing the applications code.

share|improve this question
Of note, brightness doesn't map equally. To our eyes, green is brighter than red or blue. ppmtopgm uses l = 0.299 r + 0.587 g + 0.114 b for its conversion. –  MichaelT Dec 20 '12 at 23:30
Yes, I know, but thats not the problem. Once I know where (when) in the code I have to / should make that conversion, the conversion itself is pretty easy. –  Daniel Oertwig Dec 20 '12 at 23:33
Lightness is also of use to read. The mode you use is mentioned I = (R+G+B)/3. There is also the Y'601 which uses the same as the ppmtopgm mentioned above. The picture comparing the different models is useful to examine and consider. –  MichaelT Dec 20 '12 at 23:34
add comment

1 Answer

up vote 3 down vote accepted

Depending on your processing needs, I'd go with either:

a) A bitmap class that stores raw pixel data and format information; when loading, you resolve RLE compression, but otherwise leave the raw pixel values intact. Then add some methods to query the class for its pixel format, and possibly a getter/setter pair to transparently modify pixels in a format-independent way (i.e., convert to and from floating-point RGB representation on the fly). If you ever need to convert between pixel formats, you would do that in this model by loading the original bitmap, creating a new empty bitmap with the desired target format, and then copying pixels over through the floating-point RGB getters/setters. b) Store pixel data as RGB floats (or 16-bit integers, depending on the kind of transformations you want to do). When loading convert everything to that format, and then when saving, specify the target pixel format explicitly.

Method a) has the advantage that some filters can be implemented in a completely lossless way, by using raw data and adapting the filter to the actual pixel format; it is more complicated to write such filters though, and if apply do more than one floating-point filter, you'll get more rounding errors on each pass (because you convert to and from integer every time).

Method b) is easier to implement, especially because your filters only ever need to accommodate one pixel format, and it produces less rounding errors, but it does not allow for completely lossless filters (not even an identity filter: loading and then saving the same bitmap still introduces one round-trip's worth of integer-to-floating-point conversion errors).

share|improve this answer
Hi, I really like the first approach. What I thought of going with for now is the following: I load the raw pixel data (only resolving compression) and store it inside the bitmap, as you suggested. To get the values, i would try (i'm not sure if this works with C++ ... or any language, will have to try it) to overload a methods return type to return different types of pixels, i.e.: –  Daniel Oertwig Dec 24 '12 at 1:24
RGBPixel pixelAt(uint32_t x, uint32_t y) with RGBPixel having the attribute (or getter and setters or whatever) r, g and b, so I can use: myBitmap.pixelAt(10,40).r = 0.5f. Similarly, I would provide a method GrayScalePixel pixelAt(uint32_t x, uint32_t y) with GrayScalePixel having the attribute gray to be able to do myBitmap.pixelAt(10,40).gray = 0.9f. This should solve my needs. (For conversion I would go exactly the way you described it) –  Daniel Oertwig Dec 24 '12 at 1:24
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.