Yeah, sorry, I know, the enums are renamed for second or third time in a
row, first they were Image::Format, then ImageFormat, then ColorFormat
and now PixelFormat. But this time it's final and last time they are
renamed and now everything is finally consistent:
* ColorFormat::DepthComponent -- depth is not a color, thus
PixelFormat::DepthComponent makes a lot more sense.
* There will be PixelStorage classes, which will be stored in images
alonside PixelFormat/PixelType enums, making everything nicely
aligned.
* The GL documentation about glTexImage2D() etc. denotes the <format>
and <type> parameters as format and type of *pixel* data, so now we
are _finally_ consistent with the official naming.
I wonder why did I not choose PixelFormat originally. Anyway, the old
<Magnum/ColorFormat.h> header, ColorFormat, ColorType and
CompressedColorFormat types are now aliases to the new ones, are marked
as deprecated and will be removed in some future release (as always, I'm
waiting at least six months before removing the deprecated
functionality).
I hoped to use them to store pixel pack/unpack configuration, but I have
better solution now.
The AbstractImage.h header is now removed along with the base classes,
I'm not expecting that anyone used these empty classes, so I'm not doing
anything to preserve backwards compatibility.
Added (now empty) AbstractCompressedImage class that inherits (now also
empty) AbstractImage class.
Added CompressedBufferImage, CompressedImage and CompressedImageView
classes, which are just copies of BufferImage, Image and ImageView
classes with format/type pair replaced by just format, but they
additionally need data size parameter.
Because of different use cases in Trade, the Trade::ImageData class now
handles both uncompressed and compressed format, checking the API
usage with runtime assertions. The reason for this is that a material
could just reference a image file by ID and we need to be able to
extract image of that ID without prior knowledge whether it is
compressed or not. Requiring prior knowledge of image format from the
user would make both the API and the usage far more complicated than
having Trade::ImageData which handles both cases.
On the other hand, the Image*/CompressedImage* distinction is done for
easier usage and type-safe APIs in all other cases.
Vladimír Vondruš