Open benstevens48 opened 5 years ago
I realised my initial title was incorrect - I was testing CreateImageSourceFromWic directly without setting the alpha mode to premultiplied which was the problem. However, the remaining comments still stand.
The HDR support in Win2D image loading is definitely on the simplistic side. I don't remember exactly why we limited this to Jpeg-XR format - probably a combination of caution (avoid risk of regressing existing functionality while adding HDR support) plus this is the only WIC format used by Win2D that is actually capable of encoding HDR data.
Automatic load time format conversions is a big can of worms, particularly if you look at things like going between unorm and float formats. What's the right behavior if range is reduced and data must be truncated? Should the conversion tonemap, and if so in what colorspace? Advanced HDR apps need to deal with these questions (or might just pick a specific format and require that the hardware support it) but that's a high level of complexity beyond what we felt made sense for the high-level-and-simple-but-doesn't-expose-all-the-knobs style of Win2D image loading helper. So we just took the easy option of preserving HDR data only if that could map directly to the hardware.
What cases are you seeing where image files don't map directly to GPU format capabilities? It would be helpful to understand details of what the formats involved here are.
Hi Shawn, Ok, I agree automatic conversion might be complicated. So perhaps the better suggestion would be to have an addition Load overload that specifies a DirectX pixel format (only a few would be supported) and the load function would convert to the corresponding WIC format before creating the virtual bitmap from the WIC bitmap source. The unknown pixel format could correspond to the existing automatic conversion behaviour. In addition, you could expose the pixel format used at a property of the VirtualCanvasBitmap (although not sure how it would work with interop).
In terms of use cases - I'm developing a photo viewing app and would like to support high-quality rendering or image processing of as many formats as possible. In terms of formats I have actually seen people using, I guess 64bpp uint is the main high bit-depth format I have seen, which is supported by PNG, TIFF and HEIC as well as JPEG-XR.
The function
DefaultBitmapAdapter::CreateWicBitmapSource
attempts to support HDR pixel formats, but I think this function could do better in terms of its pixel format support. Firstly I don't see why it needs to check that the container format is JPEG-XR - surely it is sufficient to look at the pixel format. Secondly, instead of checking for an exact match of pixel formats it could do something like this function.And then use this to get the corresponding WIC formats
Note this function does not consider the DDS formats. You could also add some sort of option to the CanvasVirtualBitmap and CanvasBitmap LoadAsync methods to specify the format (for example here I have added a max pixel size because loading a full 128bpp image takes a lot of memory and is unnecessary if it is going to be drawn to a 32bpp swap chain), but then again for simplicity you might want to omit this option.
In addition, it would then be helpful to add a PixelFormat property to the CanvasVirtualBitmap so it is possible to tell what format is being used. This is actually necessary in order to determine what color space conversion to then apply. (I already created an issue for this).
I have been trying to solve this using interop, but I have run into another issue whereby interop causes the app to hang (I've already submitted that issue). I hope you will consider implementing this. I am happy to do a bit of work on it, although I am not very familiar with WRL (I'm using C++/WinRT).