ImageMagick Q8

Tomasz Pala gotar at
Tue Jun 24 13:09:23 CEST 2014


most images these days are 8-bit/component, most IM use cases covers
simple one-pass actions like converting formats or resizing, so while
defaulting to Q16 is the right way to go as suggested by IM docs itself,
we should also provide Q8 version, especially for wide range of
server-side processing of user supplied content. And the overhead of Q16
is HUGE - 30-50% more of CPU time and TWICE as much of memory. All that
wasted when most of the time anyone uses IM.

There is Q8 in .test-builds/i686 currently if anyone wants to compare

As far as I can see these versions can coexist safely, so the question
is: is there a way to build package twice automatically when STBRed? Or
the second pass needs to be explicitly handled by some loop inside spec?

There are a few things that need to be adjusted - packages suffixes (I'd
keep Q16 as it is, append to alternatives only), binaries suffixes,
removing overlapping files, but putting all this double or triple times
(Q32?) inside spec is a no-go (considering %files only). This would be
better done in kernel* way, but I doubt anyone would remember to send
the Q8 version among default when updating.

And if nobody cares, it's pointless to work on. I've just made
QuantumDepth overridable from --define and to be honest - it suits me, I
don't need to mix different versions. OTOH, there are other packages
linked with Q16 lib:

autotrace, calibre, digikam, digikam, dvdauthor, emacs, emacs-athena,
emacs-motif, gtatool-conv-magick, imgworks, libdmtx-utils,
php-pecl-imagick, php53-pecl-imagick, php55-pecl-imagick, psiconv,
ruby-RMagick, transcode, transcode-export, transcode-filter,
transcode-import, virtuoso-plugins-hosting, xine-decode-image,
xlockmore, zbar

which might gain some performance when build with Q8, but building them
all with alternatives would be an overkill (especially the ones that are
not performance greedy and don't do much of image processing - like
thumbnailing, which won't hurt on quality of Q8, but won't gain much of
a performance either).

So, any comments?

Tomasz Pala <gotar at>

More information about the pld-devel-en mailing list