Running on an AMD64 K8 *IN 32 BIT MODE*, i.e. using X86 install (2006.0?) I use "convert" to salvage underexposed digital photos, using formulas that preferentially boost darker pixels. E.g. using imagemagick-6.2.2.3-r1 convert -depth 8 input.tif -fx "u^0.8" output.tif takes 20 seconds to process a 2048x1536 tif on AMD 3000+ k8. convert -depth 8 ${1} -fx "ln(u*(16-1)+1)/ln(16)" output.tif takes 60 seconds to process a 2048x1536 tif. But with 6.2.4.2-r1, "convert" runs, and returns *INSTANTLY*, instead of taking time to process the file. The output file is a straight copy of the input file, minus metadata, with no processing at all. I've put the line... >media-gfx/imagemagick-6.2.2.3-r1 in /etc/portage/package.mask as a temporary stopgap. /etc/make.conf contains... CFLAGS="-O2 -pipe -fomit-frame-pointer -march=athlon -m3dnow -mmmx -msse -msse2 -mfpmath=sse" CHOST="i686-pc-linux-gnu" CXXFLAGS="${CFLAGS}" MAKEOPTS="-j1" USE="-* 3dnow X a52 aac alsa bzip2 cdr dga dio divx4linux dri dvd dvdr dvdread e ncode exif ffmpeg flac fortran gb gif gtk2 imlib jpeg maildir mikmod mime mmap m mx mng mp3 mpeg ncurses nptl nptlonly nsplugin offensive ogg opengl plotutils pn g posix quicktime readline sdl sharedmem slang sockets sse theora threads tiff t ruetype vcd vorbis win32codecs wmf xpm xv zlib" Over the past few months, I've noticed that I always have to hang back 1 or 2 ebuilds behind the latest stable ebuild to avoid this problem.
Could you test the problem with imagemagick-6.2.6.0?
I ran "emerge --sync" and updated "sys-apps/manpages". Everything else was up to date. 6.2.6.0 doesn't work. It seems to expect a different library somewhere. $ convert -depth 8 p1010251.tif -fx "ln((u*(16-1)+1)/ln(16))" x.tif convert: error while loading shared libraries: libMagick.so.6: cannot open shared object file: No such file or directory "revdep-rebuild --ask" did not find any problems. I su'd to root and found libMagick.so.10.0.0, so I ran the commands [m3000][root][~] cd /usr/lib [m3000][root][/usr/lib] ln -s /usr/lib/libMagick.so.10.0.0 libMagick.so.6 Then back to regular user... $ convert -depth 8 p1010251.tif -fx "ln((u*(16-1)+1)/ln(16))" x.tif convert: symbol lookup error: convert: undefined symbol: ConvertImageCommand Note; if I "su" and run the same command as root, it returns instantly, without an error message. More data about my settings... [m3000][root][~] emerge --pretend --verbose imagemagick These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] media-gfx/imagemagick-6.2.6.0 +X +bzip2 +doc -fpx -graphviz -gs -jbig +jpeg -lcms -minimal +mpeg -nocxx -perl +png +tiff +truetype +wmf -xml2 +zlib 0 kB
*DIFFERENT DEPENDENCIES* I was getting ready to restore the working ebuild (6.2.2.3-r1) when I noticed that "emerge --pretend --verbose" gives different dependencies between the two versions... Calculating dependencies ...done! [ebuild UD] media-gfx/imagemagick-6.2.2.3-r1 [6.2.6.0] +X -cups +doc -fpx -graphviz -jbig +jpeg -lcms -minimal +mpeg -perl +png +tiff +truetype +wmf -xml2 Calculating dependencies ...done! [ebuild R ] media-gfx/imagemagick-6.2.6.0 +X +bzip2 +doc -fpx -graphviz -gs -jbig +jpeg -lcms -minimal +mpeg -nocxx -perl +png +tiff +truetype +wmf -xml2 +zlib 0 kB 6.2.6.0 adds "+bzip2 -gs -nocxx" and removes "-cups" from the dependency list. Does that mean anything?
You can close out bug # 122511. The work-around is to run a dummy "convert" pass to convert a "tif" to a tif. "convert" can then do all sorts of fancy stuff on the converted version. My guess is that my Panasonic FZ5 camera creates non-standard tiff files that can't be easily manipulated, but can be converted to a standard tiff file. Now that I know the root cause of the problem, I can take it to the imagemagick mailing list, and throw in a sample file.
(In reply to comment #4) > You can close out bug # 122511. The work-around is to run a dummy "convert" > pass to convert a "tif" to a tif. "convert" can then do all sorts of fancy > stuff on the converted version. My guess is that my Panasonic FZ5 camera > creates non-standard tiff files that can't be easily manipulated, but can be > converted to a standard tiff file. Now that I know the root cause of the > problem, I can take it to the imagemagick mailing list, and throw in a sample > file. I've posted this on the imagemagick mailing list, and sent a sample photo from my camera to the developers. I'm closing out my bug report as having been referred to "upstream".
