Easier to add a new (external JPEG) codec by using the file extension as a first selection filter

[vbaderks]

In the process of adding a new JPEG-LS codec to ImageSharp I discovered that:

using Image image = Image.Load("my-image.jls");

would not work. The JPEG-LS format has its own official extension (.jls) and mime type (image/jls). The current implementation does not use this extension however as early in the process the path is converted to a Stream object.
The ImageSharp library then selects a codec based on asking every registered codec if they can decode the image.

This is a problem for JPEG files as examining the first few bytes of the header doesn't provide enough information. The build-in JPEG codec always reports that it can decode images that start with a JPEG SOI (start of image) marker. A more reliable way would be to check which SOF (start of frame) marker is present as this marker defines which algorithm has been used to encode the image. This would make the header checking however much more complex as more bytes of the header must be parsed.

A probable simpler extension would be to forward the file extension and select the codecs that tell that they can handle that extension/mime type (the current design already has this information) and then do the header check. If no match was found the overall list can be checked (like the current implementation) as fallback.

This 2 step detection mechanism would make it easier to add external codecs for new image types or override existing build-in codecs.

[JimBobSquarePants]

A probable simpler extension would be to forward the file extension and select the codecs that tell that they can handle that extension/mime type (the current design already has this information) and then do the header check. If no match was found the overall list can be checked (like the current implementation) as fallback.

This 2 step detection mechanism would make it easier to add external codecs for new image types or override existing build-in codecs.

You don't have access to the file extension for most of the Load/Identify overloads plus the extension should always be treated as untrustworthy.

Realistically the goal should be to extend the existing decoder not introduce a new one. It seems to me that adding lossless support should be possible, for example, this library includes the feature.

https://github.com/yigolden/JpegLibrary