Detect image type based on content instead of file extension about typst HOT 7 OPEN

I think a more useful request would be to allow overriding whatever the built-in detection process does, e.g. image(..., format: "png").

Edit: this already exists, so I believe there is no need to change the built-in detection process since you can always override it.

from typst.

Alternatively, one could add content-based detection as a fallback if the extension-based detection leads to an error.

from typst.

By the way, there is the imagesize crate which seems to be relatively lightweight and has a method to detect the type of an image. Might be a bit more reliable than our current approach of looking at "magic bytes", although I haven't tested it.

from typst.

By the way, there is the imagesize crate which seems to be relatively lightweight and has a method to detect the type of an image. Might be a bit more reliable than our current approach of looking at "magic bytes", although I haven't tested it.

Right now, we use the image crate. From a quick look imagesize also seems to look at the first few bytes, so what's the difference?

from typst.

True, nevermind, I looked at the size function instead of the matches function, which also seems to mainly look at the first few bytes. My bad.

from typst.

Originally, there are three types of formats:

1. Override format
2. Format specified by the file extension
3. Detected format

With the precedence being: 1 > 2 > 3.

Initially, I considered keeping only methods 1 and 3. However, upon further investigation, I realized that method 3 (as well as the PIL Image lib) only supports raster images, leaving us with the need to handle SVG(including PDF in the future) files as well. Additionally, I discovered that LaTeX also relies on file extensions ref (although I believe depending on a pre-defined list varying among different Latex engines is a compatibility compromise rather than a modern feature).

Alternatively, one could add content-based detection as a fallback if the extension-based detection leads to an error.

This way sounds reasonable but complicates the clear priority logic.

Finally, I think maybe we could maintain the precedence but expand the file type detection method to support universal file types (like the file command). We can then use it as a fallback method when no extension is present. Potential error outputs of method 1&2 could include a hint about the detected file type when an error occurs, like:

error: failed to decode image (Format error decoding PNG: Invalid PNG signature.)  ***It seems to be a xxxx file. **

I'm not entirely sure if it's worth the effort, and I'd like to hear your thoughts on this.

from typst.

Currently, Typst does the auto-detection if it doesn't know the extension. Upon further thought that seems like a backwards incompatibility hazard. If I have a .png JPEG file, it would detect as PNG and fail to decode, but I have a .webp JPEG file, Typst wouldn't know the extension and decode as JPEG. This would then break if we add WEBP support in the future. Only doing content-based detection when no file extension is present would be better in my opinion.

Adding a hint when the extension specifies one image format, but detection determines it as another seems fine, though not useful very often. I think expanding it to any file type is overkill, and would probably also require a new dependency.

from typst.