ImageSharp
ImageSharp copied to clipboard
Method Image.InternalDetectFormat test always all format detectors instead of stopping when a match has been found
Prerequisites
- [X] I have written a descriptive issue title
- [X] I have verified that I am running the latest version of ImageSharp
- [X] I have verified if the problem exist in both
DEBUGandRELEASEmode - [X] I have searched open and closed issues to ensure it has not already been reported
ImageSharp version
3.1.5
Other ImageSharp packages and versions
3.1.5
Environment (Operating system, version and so on)
Windows
.NET Framework version
.NET 8.0
Description
I was developing a new JPEG-LS (lossless jpeg) codec interop for ImageSharp as the build-in JPEG decoder doesn't support it. I noticed a couple of issues during this development that I like to share. For easy tracking I have created a separate report for each issue:
One of the things I noticed is that the method InternalDetectFormat has a loop to detect which codec to use to decode the image:
foreach (IImageFormatDetector formatDetector in configuration.ImageFormatsManager.FormatDetectors)
{
if (formatDetector.HeaderSize <= headersBuffer.Length && formatDetector.TryDetectFormat(headersBuffer, out IImageFormat? attemptFormat))
{
format = attemptFormat;
}
}
https://github.com/SixLabors/ImageSharp/blob/5c2812901488bc7e97512e97b8a4aa2629c29185/src/ImageSharp/Image.Decode.cs#L132C2-L138C10
This current implementation of this loop doesn't stop when a good match has been found. This is less efficient (performance) then quitting the loop after a good match.
Note: I discovered this as my own codec would be added to the beginning of the list, but as the loop continues at the moment the build-in JPEG codec will always be selected as it also returns true for JPEG-LS files, even if the build-in codec cannot decode these JPEG-LS files. The current workaround is to not use the default DecoderOptions, but to create a new and only register 1 codec.
Steps to Reproduce
- install a external JPEG codec. It will not be selected.
Images
No response
Apologies for the slow resopnse here. I've been away on a much-needed break.
Yes, we should break early to allow correct detection here.
Would you be interested in submitting a PR?
Sure, I can create a PR for this issue.
Fixed via #2835