FS#38273 - [graphicsmagick] Last update (1.3.18-6) breaks XPMs
Attached to Project:
Arch Linux
Opened by Christopher Reimer (CReimer) - Wednesday, 25 December 2013, 14:55 GMT
Last edited by Gaetan Bisson (vesath) - Tuesday, 07 January 2014, 03:05 GMT
Opened by Christopher Reimer (CReimer) - Wednesday, 25 December 2013, 14:55 GMT
Last edited by Gaetan Bisson (vesath) - Tuesday, 07 January 2014, 03:05 GMT
|
Details
Description:
Take a look at the attached pictures. The XPM suffixed with old was made with the perl module of graphicsmagick 1.3.18-5. And also take a closer look at the colorcodes in the xpm file (xpm is human readable) It's also impossible to detect what exactly caused this, because the GIT repository is not up-to-date. |
This task depends upon
Closed by Gaetan Bisson (vesath)
Tuesday, 07 January 2014, 03:05 GMT
Reason for closing: Implemented
Additional comments about closing: graphicsmagick-1.3.19-2 in [testing]
Tuesday, 07 January 2014, 03:05 GMT
Reason for closing: Implemented
Additional comments about closing: graphicsmagick-1.3.19-2 in [testing]
FS#37890is responsible. It also breaks binary compatibility.I switched to graphicsmagick from imagemagick because of the almost weekly API breakage. And now graphicsmagick is completely broken, too.
Please fix this soon. My vdr4arch project is now completely unusable https://github.com/CReimer/vdr4arch http://creimer.net/vdr4arch/repos/stable/
And I am not sure either how you propose to fix this. You wouldn't be happy with graphicsmagick-1.3.19 by any chance?
Quantum depth at 32 seems to break most of graphicsmagick's functionality, especially XPMs get corrupted.
The usual color depth for XPMs is 24bit, with quantum depth set to 32, graphicsmagick adds color codes with 96bit to the file.
Not even gimp is able to read those XPMs.
There are a few VDR plugins which depend on imagemagick or graphicsmagick. These plugins are unable to read PNG files.
But I cannot provide further information (code dump...), because it doesn't crash.
Please revert the changes you did for
FS#37890. ThanksIt's more than 8 and it doesn't break anything.
Also removed --with-openmp. configure doesn't recognize that setting
If there's not will from upstream to address this, I will revert to quantum-depths=16 but, before that, I'd like to be sure there is no other way.
What remains is the problem with VDR plugins. The VDR process just dies, without segfault or any error message.
But I don't think that's a graphicsmagick issue. gm convert works fine.
The plugins I want to use are just incompatible with 32bit quantum depth.
And as much as I know there's no common picture format, which supports more than 16bit quantum depth.
16bit is the default and recommended setting for imagemagick and Fedora enables 16bit for graphicsmagick, too. Debian stays with 8bit.
With a higher quantum depth (8->32) graphicsmagick gets 3 times slower and uses 3 times more RAM.
Could you please confirm that all your issues are resolved with it?
Thanks.