JpegImageFormatDetector IsJfif and IsExif checks are not needed as IsJpeg is always true for valid JPEG files.

[vbaderks]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp
• I have verified if the problem exist in both DEBUG and RELEASE mode
• 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 decoder doesn't support it.
I noticed a couple of issues during this development that I like to share. For easy tracking I have a separate report for each issue:

Every valid JPEG file starts with a SOI marker. The JpegImageFormatDetector.cs checks this but also checks if there is a Jfif application segment present or an Exif segment. These 2 checks are redundant as files with an Jfif or Exif segment will also start with a SOI marker.

ImageSharp/src/ImageSharp/Formats/Jpeg/JpegImageFormatDetector.cs

Line 25 in 4584377

&& (IsJfif(header) || IsExif(header) || IsJpeg(header));

Steps to Reproduce

N.A. checks are valid, just not really needed.

Images

No response

[JimBobSquarePants]

I was developing a new JPEG-LS (lossless jpeg) codec interop for ImageSharp as the build-in decoder doesn't support it.

Would it be possible to extend the current decoder instead?

Every valid JPEG file starts with a SOI marker. The JpegImageFormatDetector.cs checks this but also checks if there is a Jfif application segment present or an Exif segment. These 2 checks are redundant as files with an Jfif or Exif segment will also start with a SOI marker.

Yeah.... It's redundant with the current code. The reason for the checks were that initially we were explicitly supporting only the EXIF and JFIF variants of the Jpeg format.

Ideally, we shouldn't really be doing the last SOI check like that as in the wild there will be instances of SPIFF or JPEG/XT images which both start with the same SOI marker. While they are supposed to be backward compatible, these may cause unpredicted issues with our decoder which may hit unmanaged memory and become a security concern since the decoder is untested against such examples.

I'm not sure how we would rewrite detector since the byte could be SOI followed by many different JPEG markers APP0, DQT etc...