Originally it was just assuming that any Vector3ub or Color3ub is a
normalized format. That was kinda enough for many cases, but it started
to get annoying with sRGB image comparisons, as those had to be
manually reinterpret with a sRGB-less format in order to pass.
Now the pixel format detection looks at the expected image format as
well, and if the underlying type and component count matches, it
inherits the sRGB and normalized property from it as well. If not, it
falls back to an integer format for vectors, and normalized format for
colors. For vectors this is different from previous behavior but
shouldn't cause any problem in practice -- the only result will be that
the image comparison fails with a different message for pixel format
mismatch than before.
This now also properly and fully tests the pixelFormatFor() helper, and
adds a missing Color3 specialization of it.
It makes no difference in this case, the State struct is not exported
even without the attribute. OTOH, it would need to have an EXPORT
attribute if it was desired to be exported, for example like done with
nested classes in GL::Framebuffer.
Basically mirroring the changes done for Corrade::Compare::*File*,
including storing the filenames as string views to avoid unnecessary
copies (and then paying extra attention to not pass temporaries to them
in its own tests).
The 32-bit float depth be needed for the upcoming OpenEXR plugin, added
also the remaining ones that will be eventually supported by KTX and DDS
plugins.
Too much burden to implement. Nope. Sorry. All APIs were just asserting
that it's not enabled at the moment, so I may as well just remove it
completely.
Currently just does per-pixel comparison and calculates absolute delta,
failing the comparison if max/mean delta threshold is above specified
values. Useful enough for the case I have right now, might fail in other
case -- but still better than whatever else I was using before :)