Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSuggestion: CanvalVirtualBitmap should expose a PixelFormat property #654
Comments
|
You don't need to convert images to floating point formats before drawing them onto a floating point swapchain, but you do need to be aware of color space if you are developing an HDR application. You'll need to know the color space of each image you are displaying, and insert the appropriate color transforms before drawing any images that don't match the colorspace of your output swapchain. This isn't doing automatically, although non-HDR apps can mostly get away with ignoring the issue since non-HDR swapchains and non-HDR images are pretty much always in sRGB space. |
|
Ok, thanks, that basically answers the second part (actually I did already get this working by using an sRGB to scRGB color transform effect). I'll have to investigate whether interpolation during resizing is done in linear or sRGB space by creating some small examples and looking at the pixels. However, for the first part the ability to determine what pixel format the CanvasVirtualBitmap is using is still necessary. |
I'd like to support loading HDR images. I see that support has been added to CanvasVirtualBitmap in some cases. However, this is only part of the solution. I'd like to be able to determine whether the image loaded is a floating-point format and use a 64bpp floating point swap chain in that case (for monitors that support HDR) and a normal 32bpp uint swap chain otherwise. I can't see any easy way to perform this check at the moment other that by using WIC to query the image format, and also relying on the Win2D implementation in terms of pixel format conversion to stay the same, which is not ideal. Any chance a PixelFormat property could be added to the CanvasVirtualBitmap? I know that the underlying direct2d object might not have a pixel format but I think it can be inferred from the iwicbitmapsource it was given.
Another approach I might take is to always use a 64bpp floating point swap chain for monitors that support HDR. In this case I think it might be necessary to convert uint format images to a floating point format before loading them using direct2d. So I think in addition it might be nice to have an overload of the CanvasVirtualBitmap load options that takes a pixel format. Without this conversion it appears that no gamma correction is applied when loading the image so it looks far too light. This actually surprised me and leaves me with the following question which perhaps you can answer. If I draw a normal uint CanvasVirtualBitmap onto a normal uint swap chain, with resizing of the image, is the image resizing interpolation done in the correct space (i.e. is it converted from sRGB to linear gamma during resizing and then back again)?
Some of the above may also apply to CanvasBitmap, but I'm not using that.
Thanks for your time.