From undtctbl at gmail.com Thu Nov 5 04:51:52 2009 From: undtctbl at gmail.com (fgsfds123) Date: Thu, 5 Nov 2009 14:51:52 +0200 Subject: [Magick-bugs] transparent background in gif Message-ID: <3be7ddd50911050451m2c5d811br81d8d1b7e59f7e05@mail.gmail.com> Attached. Also: convert lol.gif -scale 200% out.pnm convert lol.gif -sample 200% out.pnm correct but convert lol.gif -resize 200% out.pnm no Version: ImageMagick 6.5.6-1 2009-09-15 Q16 OpenMP From anlamarama at gmail.com Sat Nov 7 13:10:20 2009 From: anlamarama at gmail.com (Serdar Sahin) Date: Sun, 8 Nov 2009 08:10:20 +1100 Subject: [Magick-bugs] Bug Report Message-ID: <179a8b2a0911071310y4465fd1ft5bf823ed6d11a06@mail.gmail.com> Hi, I think, I am missing a configuration or something, but it could be also a potential bug. (in imagemagick or somewhere else) I have a CentOS 5.3 server, and am trying to convert PDF to JPG on that server. I have installed the 64 bit RPM package, so all the dependencies installed together via yum. However it does not convert correctly. The output is: http://img257.imageshack.us/img257/6631/iboss2.jpg I have removed it and installed 32 bit package, it worked correctly. http://img257.imageshack.us/img257/7078/iboss.jpg I don't know what is the problem, the problem could be something else. Any idea? (I am using official repositories of CentOS by the way) If you need additional details, I can give. Serdar, From pierre42d at 9online.fr Tue Nov 10 06:35:47 2009 From: pierre42d at 9online.fr (Pierre) Date: Tue, 10 Nov 2009 15:35:47 +0100 Subject: [Magick-bugs] Problem compiling ImageMagick 6.5.7-6 Message-ID: <4AF97A43.7080404@9online.fr> # make make all-am make[1]: Entering directory `/tmp/ImageMagick-6.5.7-6' CC coders/coders_png_la-png.lo coders/png.c: In function 'ReadOnePNGImage': coders/png.c:1826: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'png_uint_32' coders/png.c:1826: warning: format '%lu' expects type 'long unsigned int', but argument 7 has type 'png_uint_32' coders/png.c:1970: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'png_uint_32' coders/png.c:1970: warning: format '%lu' expects type 'long unsigned int', but argument 7 has type 'png_uint_32' coders/png.c:2098: error: 'png_info' has no member named 'trans_color' coders/png.c:2100: error: 'png_info' has no member named 'trans_color' coders/png.c:2101: error: 'png_info' has no member named 'trans_color' coders/png.c:2102: error: 'png_info' has no member named 'trans_color' coders/png.c:2118: error: 'png_info' has no member named 'trans_color' coders/png.c:2119: error: 'png_info' has no member named 'trans_color' coders/png.c:2120: error: 'png_info' has no member named 'trans_color' coders/png.c:2121: error: 'png_info' has no member named 'trans_color' coders/png.c:2127: error: 'png_info' has no member named 'trans_color' coders/png.c:2666: error: 'png_info' has no member named 'trans_alpha' coders/png.c: In function 'ReadOneJNGImage': coders/png.c:3146: warning: format '%16lu' expects type 'long unsigned int', but argument 6 has type 'png_uint_32' coders/png.c:3148: warning: format '%16lu' expects type 'long unsigned int', but argument 6 has type 'png_uint_32' coders/png.c: In function 'png_write_raw_profile': coders/png.c:6113: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'png_uint_32' coders/png.c:6134: warning: format '%8lu' expects type 'long unsigned int', but argument 4 has type 'png_uint_32' coders/png.c: In function 'WriteOnePNGImage': coders/png.c:6349: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'png_uint_32' coders/png.c:6351: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'png_uint_32' coders/png.c:6533: error: 'png_info' has no member named 'trans_alpha' coders/png.c:6534: error: 'png_info' has no member named 'trans_alpha' coders/png.c:6540: error: 'png_info' has no member named 'trans_alpha' coders/png.c:6556: error: 'png_info' has no member named 'trans_alpha' coders/png.c:6565: error: 'png_info' has no member named 'trans_alpha' coders/png.c:6572: error: 'png_info' has no member named 'trans_alpha' coders/png.c:6573: error: 'png_info' has no member named 'trans_alpha' coders/png.c:6773: error: 'png_info' has no member named 'trans_color' coders/png.c:6775: error: 'png_info' has no member named 'trans_color' coders/png.c:6777: error: 'png_info' has no member named 'trans_color' coders/png.c:6779: error: 'png_info' has no member named 'trans_color' coders/png.c:6781: error: 'png_info' has no member named 'trans_color' coders/png.c:6801: error: 'png_info' has no member named 'trans_color' coders/png.c:6801: error: 'png_info' has no member named 'trans_color' coders/png.c:6801: error: 'png_info' has no member named 'trans_color' coders/png.c:6814: error: 'png_info' has no member named 'trans_color' coders/png.c:6814: error: 'png_info' has no member named 'trans_color' coders/png.c:6814: error: 'png_info' has no member named 'trans_color' coders/png.c:6832: error: 'png_info' has no member named 'trans_color' coders/png.c:6833: error: 'png_info' has no member named 'trans_color' coders/png.c:6834: error: 'png_info' has no member named 'trans_color' coders/png.c:6835: error: 'png_info' has no member named 'trans_color' coders/png.c:6852: error: 'png_info' has no member named 'trans_color' coders/png.c:7054: error: 'png_info' has no member named 'trans_alpha' coders/png.c:7055: error: 'png_info' has no member named 'trans_alpha' coders/png.c:7056: error: 'png_info' has no member named 'trans_alpha' coders/png.c:7060: error: 'png_info' has no member named 'trans_alpha' coders/png.c:7079: error: 'png_info' has no member named 'trans_color' coders/png.c:7080: error: 'png_info' has no member named 'trans_color' coders/png.c:7081: error: 'png_info' has no member named 'trans_color' coders/png.c:7082: error: 'png_info' has no member named 'trans_color' coders/png.c:7109: error: 'png_info' has no member named 'trans_color' coders/png.c:7110: error: 'png_info' has no member named 'trans_color' coders/png.c:7603: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'png_uint_32' coders/png.c:7605: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'png_uint_32' coders/png.c: In function 'WriteMNGImage': coders/png.c:9086: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'unsigned int' coders/png.c:9089: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'unsigned int' make[1]: *** [coders/coders_png_la-png.lo] Error 1 make[1]: Leaving directory `/tmp/ImageMagick-6.5.7-6' make: *** [all] Error 2 From weberjn at gmail.com Sun Nov 15 07:19:35 2009 From: weberjn at gmail.com (Juergen Weber) Date: Sun, 15 Nov 2009 07:19:35 -0800 (PST) Subject: [Magick-bugs] Tiff16 + Exif -> JPEG : Exif lost Message-ID: <26360023.post@talk.nabble.com> Hi, I tried to convert (ImageMagick-6.5.7-Q16) a 16 Bit Tiff image to jpeg with convert -verbose -geometry 50% Profile.tif Profile.jpg The Tiff contains Exif data which is no longer in the Jpeg. I googled and it seems that ImageMagick cannot write Exif data into Tiffs. But in my case it should write Exifs into Jpegs (Converting Jpeg to Jpeg retains Exif). Thanks, Juergen -- View this message in context: http://old.nabble.com/Tiff16-%2B-Exif--%3E-JPEG-%3A-Exif-lost-tp26360023p26360023.html Sent from the Magick-bugs mailing list archive at Nabble.com. From pradip.devan at gmail.com Mon Nov 16 23:09:01 2009 From: pradip.devan at gmail.com (pradip devan) Date: Tue, 17 Nov 2009 12:39:01 +0530 Subject: [Magick-bugs] ImageMagick-6.5.7-3 upgrade Message-ID: From pradip.devan at gmail.com Tue Nov 17 00:09:57 2009 From: pradip.devan at gmail.com (pradip devan) Date: Tue, 17 Nov 2009 13:39:57 +0530 Subject: [Magick-bugs] ImageMagick-6.5.7-3 upgrade In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Pradip Devan Date: Tue, Nov 17, 2009 at 1:38 PM Subject: ImageMagick-6.5.7-3 upgrade To: "pradip.devan at gmail.com" Dear Sir, Currently we are using ImageMagick-5.5.7 on Solaris, and we would like to upgrade with latest release. I have downloaded the ImageMagick-6.5.7-3.tar.gz and tried to build this code with our code, but as there is no readymade code to build i am unable to build ImageMagick code with our code. As per my knowledge, to build Imagemagick code, Makefile.am should convert into Makefile. So i have tried the follows following suggested steps in installation guide. 1) run configure script 2) make 3) make install My observations are: First step has done successfully. Second step is taking much time to compile ImageMagick code. During this step, I have come across following warning many times. ?magick/deprecate.h:141: warning: `deprecated' attribute directive ignored? After configure script run, only top level Makefile.am has converted into Makefile, and not from sub folder. So, I have two questions here: 1. Could somebody please help me to resolve the errors above?. 2. Is there a direct way/option for getting the libs instead of building the ImageMagick code in our setup ana generating them? Thanks in advance. Regards, Pradip DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. From imagemagick-2009b at ryandesign.com Tue Nov 17 01:36:04 2009 From: imagemagick-2009b at ryandesign.com (Ryan Schmidt) Date: Tue, 17 Nov 2009 03:36:04 -0600 Subject: [Magick-bugs] ImageMagick-6.5.7-3 upgrade In-Reply-To: References: Message-ID: <64B2E8ED-9676-4D8F-9082-3FC0B48FFE63@ryandesign.com> On Nov 17, 2009, at 02:09, pradip devan wrote: > Currently we are using ImageMagick-5.5.7 on Solaris, and we would like to > upgrade with latest release. > I have downloaded the ImageMagick-6.5.7-3.tar.gz and tried to build this > code with our code, but as there is no readymade code to build i am unable > to build ImageMagick code with our code. > > > As per my knowledge, to build Imagemagick code, Makefile.am should convert > into Makefile. So i have tried the follows following suggested steps in > installation guide. > > 1) run configure script > 2) make > 3) make install > > My observations are: > First step has done successfully. > Second step is taking much time to compile ImageMagick code. > During this step, I have come across following warning many times. > ?magick/deprecate.h:141: warning: `deprecated' attribute directive > ignored? > After configure script run, only top level Makefile.am has converted into > Makefile, and not from sub folder. I don't pay enough attention to the build process to know if that is normal or not. > So, I have two questions here: > 1. Could somebody please help me to resolve the errors above?. I don't know about those warnings. I suggest you ignore them. Do you get any errors (where it says "error:" and not "warning:")? > 2. Is there a direct way/option for getting the libs instead of building > the ImageMagick code in our setup ana generating them? A Solaris binary is listed here: http://www.imagemagick.org/script/binary-releases.php I don't know what version it is but it was modified October 2008 so it's not the latest, but is hopefully newer than the 5.5.7 you have. From duc.sequere.aut.de.via.decede at imagemagick.org Tue Nov 17 05:54:31 2009 From: duc.sequere.aut.de.via.decede at imagemagick.org (duc.sequere.aut.de.via.decede at imagemagick.org) Date: Tue, 17 Nov 2009 05:54:31 -0800 Subject: [Magick-bugs] ImageMagick-6.5.7-3 upgrade Message-ID: <200911171354.nAHDsVQA009328@studio.imagemagick.org> > During this step, I have come across following warning many times. > magick/deprecate.h:141: warning: `deprecated' attribute directive ignored Its just a warning and can saefely be ignored. > After configure script run, only top level Makefile.am has converted into > Makefile, and not from sub folder. That's expected. ImageMagick builds from the top-level directory. Did ImageMagick compile and install as expected? From tomoko at u-aizu.ac.jp Tue Nov 17 15:35:15 2009 From: tomoko at u-aizu.ac.jp (=?ISO-2022-JP?B?GyRCTlMbKEIgGyRCQ1I7UhsoQg==?=) Date: Wed, 18 Nov 2009 08:35:15 +0900 Subject: [Magick-bugs] We cannot display PostScript file on Mac OS X Snow Leopard. Message-ID: <20091118083515.faec5e95.tomoko@u-aizu.ac.jp> Dear Sir, We are using binary package ImageMagick-i386-apple-darwin10.0.0.tar.gz on Mac OS X Snow Leopard 1.6(Intel). The window blinks intensely when the PostScript file is displayed by the following commnad: % display tiger.ps Best Regards, ---- Tomoko Hayashi E-Mail: tomoko at u-aizu.ac.jp From imagemagick-2009b at ryandesign.com Tue Nov 17 15:52:55 2009 From: imagemagick-2009b at ryandesign.com (Ryan Schmidt) Date: Tue, 17 Nov 2009 17:52:55 -0600 Subject: [Magick-bugs] We cannot display PostScript file on Mac OS X Snow Leopard. In-Reply-To: <20091118083515.faec5e95.tomoko@u-aizu.ac.jp> References: <20091118083515.faec5e95.tomoko@u-aizu.ac.jp> Message-ID: On Nov 17, 2009, at 17:35, ? ?? wrote: > We are using binary package ImageMagick-i386-apple-darwin10.0.0.tar.gz > on Mac OS X Snow Leopard 1.6(Intel). > > The window blinks intensely when the PostScript file is displayed by > the following commnad: > > % display tiger.ps I see the same issue with ImageMagick 6.5.7-0 installed on Snow Leopard using MacPorts. display /usr/share/doc/groff/1.19.2/examples/mom/penguin.ps But it doesn't seem isolated to PostScript files; if I "convert" penguin.ps to penguin.png, the same happens (though in that case, the window opens in a strange location on the screen). Some other documents I've tried work fine, such as dispay /usr/share/doc/groff/1.19.2/pic.ps From barton_lv at staff.easou.com Wed Nov 18 01:02:46 2009 From: barton_lv at staff.easou.com (barton_lv) Date: Wed, 18 Nov 2009 17:02:46 +0800 Subject: [Magick-bugs] a memory problem on Linux-redhat-AS5 Message-ID: <200911181702458755359@staff.easou.com> I met a problem about ImageMagick on redhat-AS5 but not found on readhat-AS4. I use ImageMagick++ to process amount of images with multiple threads on AS5. But I found that the program consumes amount of virtual memory. Every thread will consume about 100M-170M, and fastly the program will dump due to memory deficiency. And this do not happen on AS4. I am very anxious. Can you help me? My program is very simple as the attached. the main process of every thread is like this: int MakePic(...) { ...... Blob *blob = new Blob(buf, bytes); Image *image = new Image(*blob); image->quality(80); image->depth(4); image->zoom(Geometry(100, 202)); //this call will lead amount of memory consuming image->write(&outblob); printf("length=%d\n", outblob.length()); delete image; delete blob; ...... } Thank you! 2009-11-18 barton_lv From china From duc.sequere.aut.de.via.decede at imagemagick.org Wed Nov 18 05:14:14 2009 From: duc.sequere.aut.de.via.decede at imagemagick.org (duc.sequere.aut.de.via.decede at imagemagick.org) Date: Wed, 18 Nov 2009 05:14:14 -0800 Subject: [Magick-bugs] a memory problem on Linux-redhat-AS5 Message-ID: <200911181314.nAIDEESP008147@studio.imagemagick.org> > this call will lead amount of memory consumption Set this environment variable: export MAGICK_AREA_LIMIT=1mb That should help with the memory requirements. If you suspect a memory leak, try a recent version of ImageMagick (the latest is 6.5.7-8). From barton_lv at staff.easou.com Wed Nov 18 18:07:01 2009 From: barton_lv at staff.easou.com (barton_lv) Date: Thu, 19 Nov 2009 10:07:01 +0800 Subject: [Magick-bugs] a memory problem on Linux-redhat-AS5 Message-ID: <200911191007010154832@staff.easou.com> Thanks! I make a test, MAGICK_AREA_LIMIT does not has an effect. I found the main difference between AS4 and AS5 is: In AS5, if the thread does not exit, then the memory used by "Image::zoom" does not free. But AS4 does. Perhaps ImageMagick does not accord with all the the versions of pthread library 2009-11-19 barton_lv ???? duc.sequere.aut.de.via.decede ????? 2009-11-18 21:05:25 ???? barton_lv; magick-bugs ??? ??? Re: [Magick-bugs] a memory problem on Linux-redhat-AS5 > this call will lead amount of memory consumption Set this environment variable: export MAGICK_AREA_LIMIT=1mb That should help with the memory requirements. If you suspect a memory leak, try a recent version of ImageMagick (the latest is 6.5.7-8). _______________________________________________ Magick-bugs mailing list Magick-bugs at imagemagick.org http://studio.imagemagick.org/mailman/listinfo/magick-bugs From sbrabec at suse.cz Fri Nov 20 06:58:34 2009 From: sbrabec at suse.cz (Stanislav Brabec) Date: Fri, 20 Nov 2009 15:58:34 +0100 Subject: [Magick-bugs] regression in -colorspace sRGB behavior Message-ID: <1258729114.3454.634.camel@hammer.suse.cz> It seems that new versions consider -colorspace sRGB differently than -profile "sRGB Color Space Profile.icm". I think it is not a correct behavior. I was using following command in batch processing of images. Some of source images were in sRGB (and no profile was embedded in the image). Some of images were in AdobeRGB and profile was embedded. convert -colorspace sRGB $SRC $DEST In ImageMagick-6.4.0.4 it was working correctly: - If the image had no profile, no color conversion was done, expecting input in sRGB. - If the input was in AdobeRGB, conversion to sRGB was performed. In ImageMagick-6.4.3.6 (tested in 6.5.4.8) it changed its behavior and the result of the command is always much darker than expected. It is wanted change or a regression compared to the previous behavior? Note: It seems that this works in a similar way than the command above: convert -profile /usr/share/color/icc/Adobe\ ICC\ Profiles/RGB\ Profiles/sRGB\ Color\ Space\ Profile.icm $SRC $DEST But for sRGB images without embedded profile it complains: convert: associate profile with image, a source and destination color profile required for transform `icc' @ profile.c/ProfileImage/812. (Well, just in this case letting it without any conversion is exactly what I need.) But this again does not work properly (too dark), with or without embedded profile: convert -profile /usr/share/color/icc/Adobe\ ICC\ Profiles/RGB\ Profiles/sRGB\ Color\ Space\ Profile.icm -colorspace sRGB $SRC $DEST It seems to be related with: 2008-06-03 6.4.1-6 Cristy * The -colorspace option is an operator, not a setting. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec at suse.cz Lihovarsk? 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/