Thanks for the patch!

Appending [0] after the file path causes an error when image filenames already contain [0], like a.jpg[0] or b.jpg[0][0]:

`magick` exited with error code: 1

without manually appending [0], they can be previewed normally with the magick previewer.

Perhaps some kind of escaping is needed for the file path here?

This turned out to be more difficult than I thought. There a combination of two problems.

1. Apparently, magick does not provide a way to escape individual characters in a file path. Moreover, you cannot even pass an input path to magick in such a way that it does not internally process the characters in it at all. For the output path, there is a setting that allows this (-define filename:literal=true), but looks like its implementation for the input path was not added: Expand -define filename:literal=true to also encompass inputs ImageMagick/ImageMagick#8035 (comment)
2. You can only select a frame by adding square brackets to the end of the path. There is no alternative argument for this operation.

So, as I understand it, magick works with filenames as follows:

• If a file exists with exactly the name that was passed as an argument, it uses that file. It doesn't matter whether it contains special characters or not, everything is interpreted as part of the path. Therefore, files like a.jpg[0] are now handled correctly.
• If a file with exactly that name does not exist, magick tries to parse the options passed in [], but it also parse the [] that were part of the filename, which leads to an error.

In other words, you can avoid using magick's functions that activated by special characters in the filename, and everything will be fine with any filenames. But if you use at least one of these functions (and we need Frame Selection, which is only available by adding [] to the filename), then ALL special characters in the filename start being treated as special. There is no option in between, like escaping some characters and having special use for others.

At first, I thought about checking path for a trailing ] (that was the only source of issues with square brackets). But then I found that magick also have special meaning for :, @, and %. And having these in a filename while trying to use Frame Selection ([0]) trips up magick too, because it now tries to interpret them. It becomes too complicated to deal with, so maybe it's better not to use Frame Selection at all (maybe sometime in the future if magick adds a proper argument for it).

Alternative way to get the first frame

-delete 1--1 argument discards all frames from the second (1) to (-) the last (-1).

The only concern is performance. I'm not good at benchmarking (perhaps someone else should run more tests) but here are my observations:

For a multiframe file:

• [0] is the fastest. As I understand it, it does not depend on the number of frames, because it doesn't even load them for processing, only the first one. But we cannot use this.
• -delete 1--1 is significantly slower, because it loads all frames and then deletes the extras.
• no arguments is even slower than the previous option (but not for much). That's how it works now, creates one file per frame — not what we need.
• -flatten takes about the same time as the previous option.

For a single-frame file:

• no arguments is how it works now, nothing is done with frames.
• [0] takes the same time as above.
• -delete 1--1 takes the same time as above.
• -flatten is slightly slower.

So if we use -delete 1--1, performance for single-frame files should not change. For multi-frame files, performance will not be the maximum that magick could achieve, but still it will be the same/faster than now (and working previews will be generated instead of a bunch of numbered frames).