Convert not using multiple threads

[Bingo]

Hi all,

I am using IM 6.9.3-8 Q16 x64 2016-04-10 (I know it's quite old, but I've had some problems trying to upgrade, I might start another thread on the subject).

I run this command :

Code: Select all

convert.exe -limit memory 5000 -density 1600 -set colorspace RGB -background white source.eps -flatten +matte -compress LZW -depth 8 -crop 1000x1000 dest.tif

It runs fine, but it only uses a single core.
Since the eps is quite large, and using density 1600, the output image is very big and would definitively benefit from multiple threads.

version tells me I have a version compiled with OpenMP, so I don't know what limits the number of core used ?

output of version :

Code: Select all

Version: ImageMagick 6.9.3-8 Q16 x64 2016-04-10 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2015 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Visual C++: 180040629
Features: Cipher DPC Modules OpenMP
Delegates (built-in): bzlib cairo freetype jng jp2 jpeg lcms lqr openexr pangocairo png ps rsvg tiff webp xml zlib

Any help would be appreciated !

[snibgo]

Reading the EPS is done by a delegate, Ghostscript, and IM has no influence over whether GD [EDIT: I meant GS] uses multiple threads.

"-flatten" and writing the LZW compressed tif might be capable of being multithreaded, but I don't think the writing (in coders/tiff.c) is.

[Bingo]

Ah, yes, GhostScript ! I forgot about that, thanks !
So if flatten & LZW compressed tif is multithreaded, should I see an increase in the number of threads used at the end of the conversion process ?

[snibgo]

Sorry, I wasn't clear. I've looked at the code that writes LZW compressed TIFF (and any other form of TIFF), and I don't think it's multi-threaded. It does "SetMagickThreadValue()", and I don't know what that does, but I don't think the actual code uses multiple threads.

"-flatten" uses MergeImageLayers() which uses CompositeImage() which does use multithreading. But this doesn't mean it will always be multi-threaded; IM uses a formula to determine whether multi-threading is worth the effort.

I expect "-flatten" to be a very small part of your overall command. It's just a single pass over the image. Even if multi-threading reduced the time taken to "-flatten" to zero, it wouldn't have much impact on the overall command.

[Bingo]

Yes, I never really benchmarked the command, but I believe that reading the EPS and expand it to a raster is the most expensive operation.
And that is handled by GhostScript.
BTW, since EPS are using a delegate, I checked in delegates.xml, and there is no dNumRenderingThreads option in the command line. Is there a reason for this ?

[snibgo]

I don't know, sorry. Perhaps a developer will comment. You could try adding it, and see if that makes a difference.

[Bingo]

I added it but AFAICT there is no difference.
I thought that gs was the most expensive operation, but from what I see in Process Explorer it definitively isn't.
I do see convert running on all cores at some point though, but again this is very brief and most of the time it is running in a single thread.

Thanks for your help !