only use image loaders which could potentially read file

[ralfbrown]

Rather than blindly applying image loaders until one succeeds, use magic numbers at the start of the image file to determine which loader(s) to use, and apply only those. Also detect a variety of magic numbers for common non-image formats so that we don't even attempt to load them and can give an appropriately specific error to the user.

This PR will need thorough testing because it changes such a core operation. It will also have merge conflicts with #17367, which I will fix if both are accepted.

[jenshannoschwalm]

Fully agreed on this generally.

[HansBull]

I know this would render the code a little more complicated and is probably out of scope, but one could test if a jpeg file also has the 0xFFD9 end marker to determine a possible premature EOF.

[ralfbrown]

@HansBull I would expect that libJPEG reports that as corruption, but haven't actually checked into it.

[ralfbrown]

Rebased and merge conflicts fixed.

[ralfbrown]

If someone can tell my why CI keeps throwing an error (with empty log) on the "Check if it runs" step, I'll address that on the weekend.

[ralfbrown]

I was getting nowhere fast trying to trace the data flow to where temperature.c was spitting out its color matrix error message when an image file fails to load and/or aborting the pixelpipe before execution gets there, so I decided to simply suppress the message if the load failed....

[ralfbrown]

@HansBull libJPEG doesn't report corruption if the codestream for the image data proper is truncated, it just fills the missing pixels with gray. For JPEGs, showing as much of the image as is available is probably better behavior than refusing to show it at all. I haven't played around with actual file corruption other than truncation.

[TurboGit]

@ralfbrown : Just to be sure, reading the code it seems to me that if the magic number is not found (not recognized/supported) we fallback to loading as before (that is trying the different loader, right?).

[ralfbrown]

Correct. If a magic number is recognized, use the specific loader, otherwise use the old behavior of trying a bunch until one succeeds or we run out of loaders. This provides a minor speedup and more specific error reports for recognized file types.

[TurboGit]

This fixes QOI indeed but breaks RGBE HDR format that I could open before testing this PR.

Sample here, just decompress:

sample_1920×1280.zip

[TurboGit]

Bring back RGBE HDR support. Thanks!

[ralfbrown]

Different signature string - I guess they want to move away from the original manufacturer/software name ("#?RADIANCE" is documented, your file has "#?RGBE").

added alternate signature string

[TurboGit]

Will test this soon, question why this non recognized signature has failed to be loaded by the fallback mechanism?

[ralfbrown]

Because I didn't have the fallback run through all of the loaders on the assumption that some are specific enough to have been fully covered by the signatures....

[TurboGit]

Because I didn't have the fallback run through all of the loaders on the assumption that some are specific enough to have been fully covered by the signatures....

Good to see the fallback for all loaders because as experienced here a new signature could avoid dt to load a picture and for users this means waiting months to get the fix.

[TurboGit]

Looks good and testing ok on my side, let's move forward. Thanks!