When renderdoc opens an image file, it treats it as a
"somewhat special" capture. However compressing it only corrupts
the source image file, without doing anything useful. So disable
that menu item for "image" captures.
Move all of EXR reading/preparation code into load_exr_from_file,
similar to how load_dds_from_file is done.
ImageViewer::RefreshFile code now uses very similar flow
for both DDS and EXR files (i.e. "what can have mipmaps")
All places that used is_exr_file already had first four bytes
of the file read into memory. So make is_exr_file work just
like is_dds_file does and check those bytes directly, no need
to hit stdio again.
Tiled EXR files can have mipmaps levels. When they do,
and the odd size rounding mode matches what all the
graphics APIs do ("round down"), load them when loading
the exr file. Using the same machinery that the DDS
mipmap loading uses.
And move it out into a tex_data.h header. This is in preparation
for getting mipmaps out of EXR files, where read_dds_data for
that would be a bit confusing.
A tiny bit faster, and I think it is easier to understand too.
Time taken to load 4K video resolution EXR files, on Ryzen 5950X/VS2022:
- FP16 file (27MB): 77ms -> 75ms
- FP32 file (69MB): 118ms -> 113ms
EXR files internally are split into independent "parts", which can
be decoded separately. Tinyexr already supports that via
TINYEXR_USE_THREAD.
Time taken to load 4K video resolution EXR files, on Ryzen 5950X/VS2022:
- FP16 file (27MB): 536ms -> 77ms
- FP32 file (69MB): 793ms -> 118ms
Various EXR images especially from movie assets do not simply have "R"
etc as channel names; the convention seems to be to have "layer name",
".", "color channel name". For example, channels in EXR might be
"rgb.R", "rgb.G", "rgb.B", which RenderDoc was not detecting previously
and displaying an all-black image.
* We can safely use the non-DSA function since this always happens in the
texture chunk, not during capture (we do not support mid-capture texture
resizes for obvious reasons).
baldurk