search

Sergio0694 / ComputeSharp

A .NET library to run C# code in parallel on the GPU through DX12, D2D1, and dynamically generated HLSL compute and pixel shaders, with the goal of making GPU computing easy to use for all .NET developers! 🚀
MIT License
2.65k stars 122 forks source link

Limitations of detecting ImageFormat / ContainerFormat from file extension #799

Open elyoh opened 1 month ago

elyoh commented 1 month ago

https://github.com/Sergio0694/ComputeSharp/blob/94fe99a0a8e93bf5ee1aa34c9611fdd4733a72c8/src/ComputeSharp/Graphics/Helpers/WICFormatHelper.cs#L112

When loading / saving a texture back to a file, we find that WICFormatHelper.GetForFilename performs a case sensitive search on the file extension to determine the desired format. However, at least on Windows, file extensions are case insensitive and therefore this unexpectedly gives an ArgumentException for upper or (pathological) mixed case extensions.

Further, the list of supported extensions also appears incomplete. Taking the results returned by .NET WPF's System.Windows.Media.Imaging.BitmapDecoder.CodecInfo.FileExtensions as a baseline, we might expect at least the following to be mapped as well: .dib, .rle => GUID.GUID_ContainerFormatBmp .jpe, .jfif, .exif => GUID.GUID_ContainerFormatJpeg .tif => GUID.GUID_ContainerFormatTiff

Clearly users can work round the above by using the SaveTexture overload which passes a FileStream and ImageFormat directly but it would be nice if the above concerns were addressed.

rickbrew commented 1 month ago

Since this is using WIC then it should be possible in principle to support and correctly map all of the file extensions that WIC specifies support for.

See IWICBitmapCodecInfo::GetFileExtensions

It'd require a linear scan through all of the codecs and their extensions, but that shouldn't be very expensive (compared to the decoding and file I/O ...).