Hello, I encountered a problem with ImageMagick, it would be great if someone could see if they can replicate the problem.
The version of ImageMagick in Kiel (6.7.3) does not have the bug, I first noticed this witj the version in Bratislava (6.8.8) 16-bit greyscale images (fits or tiff) are not handled properly on Solaris/SPARC which is big endian. On Solaris/x86 (little endian) and Linux/x86 there is no problem. Also 8-bit greyscale images are not affected. I habe no idea if the issue is actually related to endianness. As it works on Solaris/x86, I conclude that it is not Solaris specific. To reproduce the problem: - view a 16-bit greyscale image (fits or tiff) using display - convert a a 16-bit greyscale image to a 8-bit format (e. g. as png) and view it In my case the fits-image is displayed (or converted to) completely black and the tiff-image to grey noise. I've already reported this upstream, but no one has confirmed the problem: http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=25919&sid=e2b38c6d2c2db0333abd5c4bb817ccdf A completely unrelated issue also involving ImageMagick, it is actually more an emacs issue. GNU emacs can actually display images inline. Some images formats (likes fits are displayed using ImageMagick). It appears that the version of ImageMagick was changed without rebuilding emacs. This causes emacs to crash when opening an image file: $ emacs file.fits ld.so.1: emacs-24.3-athena: fatal: libMagickWand-6.Q16HDRI.so.1: open failed: No such file or directory ld.so.1: emacs-24.3-athena: fatal: relocation error: file /opt/csw/bin/emacs-24.3-athena: symbol MagickWandGenesis: referenced symbol not found killed emacs Note: DISPLAY has to be set to see the problem. ldd also shows the problem: kester@unstable10s [unstable10s]:~ > ldd -ur /opt/csw/bin/emacs | grep "not found" libMagickWand-6.Q16HDRI.so.1 => (file not found) libMagickCore-6.Q16HDRI.so.1 => (file not found) symbol not found: MagickGetException (/opt/csw/bin/emacs-24.3-athena) Regards Kester