Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ronald van Haren (pressh)
Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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]
Comment by Christopher Reimer (CReimer) - Wednesday, 25 December 2013, 16:56 GMT
 FS#37890  is responsible. It also breaks binary compatibility.
Comment by Christopher Reimer (CReimer) - Wednesday, 25 December 2013, 17:09 GMT
Graphicsmagick is no longer working for all VDR Plugins which depend on it.
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/
Comment by Gaetan Bisson (vesath) - Thursday, 02 January 2014, 10:18 GMT
It would be helpful to actually describe the issue instead of merely saying "take a look"...

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?
Comment by Christopher Reimer (CReimer) - Thursday, 02 January 2014, 10:49 GMT
Hmm, OK. My bug report is a bit too hysteric and vague. Please forget what I said before.

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 . Thanks
Comment by Christopher Reimer (CReimer) - Thursday, 02 January 2014, 12:56 GMT
The attached patch sets quantum depth to 16 (As Fedora does).
It's more than 8 and it doesn't break anything.

Also removed --with-openmp. configure doesn't recognize that setting
Comment by Gaetan Bisson (vesath) - Thursday, 02 January 2014, 20:24 GMT
Have those --quantum-depth=32 bugs been reported upstream? It would be best to have them fixed there, rather than work around them with lower quantum depths.
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.
Comment by Christopher Reimer (CReimer) - Friday, 03 January 2014, 11:36 GMT
The XPM bug, was fixed with the new release.

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.
Comment by Gaetan Bisson (vesath) - Monday, 06 January 2014, 05:48 GMT
I'll leave graphicsmagick-1.3.19-2 in [testing] for a while just to make sure it works smoothly.
Could you please confirm that all your issues are resolved with it?
Comment by Christopher Reimer (CReimer) - Monday, 06 January 2014, 11:38 GMT
Yes. All problems are resolved.

Thanks.

Loading...