Extracting the Devil
The devil’s in the details. In order to forge ahead with my imaging code library I need to come to terms with various definitions and make my code conform to them. The first is the most important.
What is an image?
Before I delve into the deep, dark details of pixel color components and layouts, I need to define what an image is. An earlier version of my library differentiated between an Image and a PixelBuffer. After a bit of maturity, I discovered that most of the code for the Image class simply passed the functionality down to the embedded PixelBuffer object, as in:
bool Image::ConvertColorspace(args) { return pixelBuffer.ConvertColorspace(args); }
The only non PixelBuffer functions that were defined in the Image class called file I/O functions in the aforementioned 3rd party library. This was a waste. After all, what is an image, but a pixel buffer. Even if you want to extract a subsection of an image into a “pixel buffer”, the resulting data is still an image, even if it is a single pixel.
The same thing applies to such concepts as graphics and photos. These objects are still images; they are subsets that refer to the complexity of the image and/or its “reality”.
Since everything is now an image, I will now collect all the color/pixel-oriented functions that are scattered throughout the library and put them into an overriding Image class, making it quite a heavyweight. While management of this class might prove cumbersome, writing functions that are designed to operate on multitudes of pixels, vs. repeated calling to single-pixel-oriented class functions will improve performance.
With a bit of hindsight, it looks like I’ve maintained the same pixel content manipulation / file content manipulation divisions, except that the file I/O is much more robust and not embedded within one class.