#66 converting runs slowly when subimage is specified

[Markus R]

I wondered why the conversion of a jpeg file could take so long (in.jpg: 20kb, between 2 and 12 sec) and examined the command line:

gm convert -geometry 60x85! -colorspace RGB -quality 80 in.jpg[0] out.jpg

I played around with the parameters and found out that only the subimage identifier was causing the time problem. The following command runs in a fraction of a second:

gm convert -geometry 60x85! -colorspace RGB -quality 80 in.jpg out.jpg

Perhaps there is something special with my jpeg. Perhaps it is a bug.

[Bob Friesenhahn]

Logged In: YES
user_id=128624
Originator: NO

I am quite sure that this is a sort of bug. The problem is likely in the bit of code which decides if "in.jpg[0]" is some sort of file (shell) wildcard expression or if it is truely a subimage specification. The problem is that they use similar syntax. GM includes built in support for many forms of shell-style wildcard expansions. So while it is "slow" it is likely trying to do a wildcard expansion based on files in the directory. In order to do this, it must obtain a list of files in the directory and then do "glob" style matching.

Here is a bit of shell wildcard expansion documentation:
[...] Matches any one of the enclosed characters. A pair of
characters separated by - matches any character lexi-
cally between the pair, inclusive. If the first char-
acter following the opening [ is a !, any character
not enclosed is matched.

Are there a large number of other files in the same directory?

[Markus R]

Logged In: YES
user_id=647987
Originator: YES

Thanks for responding so quickly. You are right. In the original directory there are >43000 files.
When I copy in.jpg to an empty directory and try to convert it with the indexer specified, it takes just 0.029 seconds to resize the file (instead of 15.48 when converting it from the original directory).

[Bob Friesenhahn]

Logged In: YES
user_id=128624
Originator: NO

This problem is fixed in GraphicsMagick CVS and will be in the next release. Thanks for the report.

[Niels Sandmann]

I can still reproduce this bug in version 1.3.20.

In a dir with more than 140000 files i get these results:

Nielss-MacBook-Pro:141068 nsp$ time gm convert sko.jpg[0] output.jpg

real 0m4.687s
user 0m0.736s
sys 0m3.654s
Nielss-MacBook-Pro:141068 nsp$ time gm convert sko.jpg output.jpg

real 0m0.469s
user 0m0.416s
sys 0m0.046s

[Bob Friesenhahn]

It seems that there must have been a regression and this bug has re-appeared.

[Bob Friesenhahn]

The re-emergence of this bug is fixed in Mercurial by changeset 14373:43f29980dcfa