Recommendation of GraphicsMagick over ImageMagick

[Stefan Wild]

As you can see in SVN, I have reverted a couple performance
optimizations for ImageMagick to bring back compatibility with some
reaaaalllllyy old versions of ImageMagick as well as GraphicsMagick.
Also, the optimizations - when tested with a 180 MB TIFF file - showed
only 0-10% performance increase.

While testing GraphicsMagick compatibility I noticed that this
actually worked three to four times(!) faster than ImageMagick using
the exact same settings. Actually this makes sense, as GraphicsMagick
was developed based on ImageMagick with the goal to provide a more
consistent (in behaviour and available options), stable and fast
solution.

So, I strongly recommend using GraphicsMagick over ImageMagick. If you
have control over your server (and no other software that depends
strictly on ImageMagick) it's quite easy to replace. For debian etch
it's as easy as this:

1. # apt-get remove imagemagick
2. # apt-get install graphicsmagick graphicsmagick-imagemagick-compat
3. Done.

In any other (Linux) case just remove ImageMagick and install
GraphicsMagick plus the compatibility package, which is basically just
symbolic links. For ResourceSpace you will only need (gm detects that
it's run as the given command and will run with the right options):
identify -> gm
convert -> gm

Also, to enable the new Camera RAW abilities you will need to extend
the delegates of GraphicsMagick usually found in /usr/lib/
GraphicsMagick-<insert-version>/config/delegates.mgk. There should be
a line with decode="dcraw" in it. Copy that nine times and replace
"dcraw" with the extensions of all the Camera RAW formats. In my case
that part of delegates.mgk looks like this:

<delegate decode="dcraw" command='"dcraw" -c -w "%i" > "%o"' />
<delegate decode="dng" command='"dcraw" -c -w "%i" > "%o"' />
<delegate decode="nef" command='"dcraw" -c -w "%i" > "%o"' />
<delegate decode="x3f" command='"dcraw" -c -w "%i" > "%o"' />
<delegate decode="cr2" command='"dcraw" -c -w "%i" > "%o"' />
<delegate decode="crw" command='"dcraw" -c -w "%i" > "%o"' />
<delegate decode="mrw" command='"dcraw" -c -w "%i" > "%o"' />
<delegate decode="orf" command='"dcraw" -c -w "%i" > "%o"' />
<delegate decode="raf" command='"dcraw" -c -w "%i" > "%o"' />
<delegate decode="dcr" command='"dcraw" -c -w "%i" > "%o"' />

You might have guessed it already. This needs the dcraw tool.

Hope this all makes sense and works for you. Please let me know if
not.

Regards,
Stefan

[ronhof]

Hi great mod.

(Using rev 448)

This works to a certain extent. Uploading works fine, process showing
several convert/dcraw processes starting/ending.

But when viewing that particular NEF resource, the browser hangs for a
few seconds, showing only a small part of the page, then after a while
it shows the whole page correct. This happens in both IE and FF...

Keeping an eye on the process list actually reveals that dcraw is
beeing run for some unknown reason when viewing that particular
resource.

Please assist.

-Ron

[Dan Huby]

Since the recent rewrite to alter the way ImageMagick files are
handled, the 'identify' command is being executed on the resource view
to extract the image dimensions. This can be slow for large files. I
don't think this is an optimal way to do it - really the image size
should be calculated and stored once when the resource is uploaded.

Watch this space, I expect this will be resolved soon.

As a work-around, remove 'nef' from $im_formats in your config file.
This will hide the dimensions and prevent the identity command from
being executed.

Dan

[Dan Huby]

...I should also add that the problem is nothing to do with using
GraphicsMagick instead of ImageMagick.

Dan

[Stefan Wild]

As of r472 this is fixed. ResourceSpace will now read the original
images' dimensions from database. As stated in the commit message,
after updating please open "pages/update_sizes.php" in your browser
once to write sizes of all existing images to the database. This is
done automatically when processing new files.

Best regards,
Stefan

[Stefan Wild]

Please avoid r473 as this introduced a bug basically breaking the
whole system. r477 fixes this. Also, it removes the need (though still
recommended) to run the update_sizes script as dimensions are written
do database on demand.

Stefan