TGA format conflict with J2K format

[programatix]

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

Description

I have implemented my own J2K format decoder/encoder for ImageSharp. However, the new TGA format conflict with it because the file header for J2K somehow matches the TGA file header check. Byte 1 and 2 of the J2K file header is 0x00 and 0x00, where TgaImageFormatDetector.cs identified as a TGA file. I believe since the TGA format is registered first before my own custom J2K format, TGA decode take precedent and throw the InvalidImageContentException.

Would be great if I can control the priority of the decoder to use.

Steps to Reproduce

Load a J2K image file.

System Configuration

• ImageSharp version: 1.0.0-rc0001
• Other ImageSharp packages and versions: ImageSharp.Drawing v1.0.0-beta0008
• Environment (Operating system, version and so on): Win10
• .NET Framework version: 4.8
• Additional information:

[brianpopow]

Because the file header of a tga file does not contain a magick byte sequence like all the other image formats its hard to tell from the first few bytes if its really a tga. The current approach can lead to false positive, if the first 3 bytes are valid for a tga file.

As far as i know tga is the only image format which does not have a magick bytes sequence at the start. The J2K file should start with 0xFF 0x4F, or am i wrong? Could you provide the image file please?

[programatix]

J2K has "jP " as the magic byte sequence (see https://www.file-recovery.com/jp2-signature-format.htm). However, its first 3 bytes are "00"s, which causes the current TGA detector to identify it as a TGA format. Since I'm registering my J2K encoder/decoder as an add-on, TGA take precedent causing the exception during TGA decoding.

You can download a J2K sample image file at https://www.fnordware.com/j2k/jp2samples.html

[JimBobSquarePants]

A potential fix would be to order our format by header length upon load for reading. Since jpeg2k would be longer it would always match first.

[programatix]

J2K magic string would be 8 bytes, where TGA format header declared is 18 bytes, but the detector only checks byte 1 and byte 2.

[brianpopow]

i think i can improve the heuristic of detecting a TGA file a bit. If the second byte (color map type) is zero, the color map specification bytes should also be zero.

[JimBobSquarePants]

J2K magic string would be 8 bytes, where TGA format header declared is 18 bytes, but the detector only checks byte 1 and byte 2.

The format detector should really only be declaring a length of the byte span it is checking. The Tga one is declaring 18 but only checking two.

[tocsoft]

how popular is TGA? could we not just make it so that we never auto detect from headers for that format and change it to require manually specifying the decoder/format for decoding them?

We can then improve our Image.Load('FileName.tga') path to fallback (if we failed to detect from headers) to looking up a format from the file extension and using that instead?