You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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.
Beta Was this translation helpful? Give feedback.
All reactions