Limitations of detecting ImageFormat / ContainerFormat from file extension

[elyoh]

ComputeSharp/src/ComputeSharp/Graphics/Helpers/WICFormatHelper.cs

Line 112 in 94fe99a

public static Guid GetForFilename(ReadOnlySpan<char> filename)

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]

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 ...).