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();
myBitmap.open("file.bmp");
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.
3
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).
2