Legacy ImageMagick Discussions Archive

I'v got about 10000 small jpg images (size 2 to 10 kb). I'v tested how fast they are loaded. Results of 3 test:
40360 ms, 42968 ms, 41184 ms
It is almoust 4 times slower than in other libraries:
FreeImage - 11170 ms, 10731 ms, 10768 ms
CxImage - 11468 ms, 11859 ms, 11374 ms
One of reasons of so slow loading is function SetImageInfo() - it has a lot of disc access - for example it calls several times GetPathComponent() witch access disc (more than once) - I think it's not necessary. So I'v replaced the function with one that only calls CopyMagickString(image_info->magick,"JPEG", MaxTextExtent);
New results:
27795 ms, 27302 ms, 27000 ms
I think there could be an option to allow pass image type to ReadImage or check type only based on file name extension.
I' also measured time with removed all code from ReadImage after
image=GetMagickDecoder(magick_info)(read_info,exception);
I was able to process and display resulting image.
Times with removed code (from ReadImage and SetImageInfo):
19468 ms, 18576 ms, 18981 ms
It is still slower than other libraries, but it's not 4 times slower.

You can speed up loading a bit by explicitly setting the image format, for example,

• convert jpeg:image.jpg image.png

This skips some of the file access checks.

magick wrote: You can speed up loading a bit by explicitly setting the image format
This skips some of the file access checks.

Actually that check is what causes some of dics access:
if ((*p == ':') && (IsDirectory(path) < 0) && (IsAccessible(path) == MagickFalse)) - I don't quite get why those 2 calls are necessary.
But yes, now it is a little faster:
34857 ms, 33967 ms, 33876 ms
I think ImageMagick can try to load file based only on extension and only if it fails (and probably usually it won't) do what it does now (maybe without call to IsDirectory() & IsAccessible() ?) - it would make loading more than 30% faster. Unfortunatelly it will still be much slower than it could have been.

The directory checks are primarily for Windows and VMS (e.g. c:/image.jpg) but its possible under Unix as well (e.g. c:image.jpg may very well be a directory). We use the C standard library stat() which is considered lightweight in that it does not open the file, it just returns some basic metadata about the file.

I have done a little more profiling and found another function which slows down a lot loading. It's GetConfigureOptions() - it also acessed disc and re-reads the same information for every image. Removing GetConfigureOptions() and SetImageInfo() speeds up loading process more than 50%. Rest of time is spent in ReadJPEGImage() which I haven't found yet why is slower than other libraries which probably use similar code for loading jpegs.

I have a question regarding the reloaded file - sRGB.icm. If I build application which is statically linked with ImageMagick may I using current API replace all profile files with in-memory representation? Are there any other files outside of binary that are required for ImageMagick?

The sRGB profile is attached to a JPEG if the EXIF profile declares the image pixels are in the sRGB colorspace and no color profile is already attached. We could cache the sRGB profile in memory to speed up this process but there has not been a demand for it. In the mean-time you can use ProfileImage() to add or delete an image profile.