- cl-gd-devel@lists.common-lisp.net - mailman3.common-lisp.net

Re: [cl-gd-devel] cl-gd patch
by Edi Weitz 16 Nov '09

16 Nov '09

Hi, That nobody seems to have looked at it is probably a bit exaggerated as at least Hans and I looked at it, and Hans also asked for a revision (and I agree with this request) to which you haven't replied yet. FWIW, here are the patch guidelines again: http://weitz.de/patches.html Thanks, Edi. On Sun, Nov 15, 2009 at 4:40 AM, Jeff Cunningham <j.k.cunningham(a)comcast.net> wrote: > Dear Dr Weitz; > > I posted a patch to the cl-gd project through the mailing list about a week > ago which no one seems to have looked at. I believe it solves a minor > irritation with SBCL users (warnings go away), is backwards compatible and > disturbs nothing else. I was hoping you would adopt it. I know you are very > busy and probably since this list is so inactive seldom look at it anymore. > But I use this library all the time and am planning to release a scientific > plotting library built on top of it very shortly, so I'd like to have all > the interfaces working as cleanly as possible. > > Best regards, > Jeff Cunningham > >

2 2

[cl-gd-devel] proposed patch for WITH-TRANSFORMATION macro
by Jeff Cunningham 09 Nov '09

09 Nov '09

Hi, I use cl-gd extensively and decided to figure out how to eliminate the incessant SBCL generated warnings that trace back to the WITH-TRANSFORMATION macro. It looks like work has already been done there. I came up with a pretty clean solution which removes the existing argument checking, provides it through a different mechanism and satisfies SBCL and backwards compatibility. I don't have any other platforms to test with but I think it will run on anything. I've attached the patch. Regards, Jeff Cunningham

2 3

[cl-gd-devel] performance issue with CL-GD on SBCL, UFFI vs. CFFI
by Anon Alex 27 May '09

27 May '09

Hello, I wanted to report a performance-related issue with CL-GD and UFFI vs CFFI-UFFI-COMPAT Here is a simple function for comparing two images: As you can see, this loops over every pixel of both images, compares the R,G,B components. (defun compare-images (image1 image2) "Comapre two images -- uses API exported by CL-GD" (declare (optimize (debug 0) (speed 3)(safety 0))) ;(declare (optimize (debug 3) (speed 0))) (let ((err 0) (height (cl-gd:image-height image1)) (width (cl-gd:image-width image1))) (declare (fixnum err height width)) (format t "height1=~a, height2=~a" height width) (assert (and (= height (cl-gd:image-height image2)) (= width (cl-gd:image-width image2)))) (loop for y fixnum from 0 below height do (loop for x fixnum from 0 below width do (let ((img-color (cl-gd:get-pixel y x :image image2)) (target-color (cl-gd:get-pixel y x :image image1))) (incf err (square (- (the fixnum(cl-gd:color-component :red img-color :image image2)) (the fixnum(cl-gd:color-component :red target-color :image image1))))) (incf err (square (- (the fixnum (cl-gd:color-component :blue img-color :image image2)) (the fixnum(cl-gd:color-component :blue target-color :image image1))))) (incf err (square (- (the fixnum(cl-gd:color-component :green img-color :image image2)) (the fixnum(cl-gd:color-component :green target-color :image image1)))))))) err)) Here's another version, which uses non-exported functions to speed it up a little bit (and for benchmarking, eliminate some of the the API-level overhead) (defun compare-images-raw (image1 image2) "Compare two images -- use internal functions to eliminate overhead added by CL-GD API" (declare (optimize (debug 0) (speed 3)(safety 0))) ;(declare (optimize (debug 3) (speed 0))) (let ((err 0) (height (cl-gd:image-height image1)) (width (cl-gd:image-width image1)) (img1 (cl-gd::img image1)) (img2 (cl-gd::img image2))) (declare (fixnum err height width)) (format t "height1=~a, height2=~a" height width) (assert (and (= height (cl-gd:image-height image2)) (= width (cl-gd:image-width image2)))) (loop for y fixnum from 0 below height do (loop for x fixnum from 0 below width do (let ((img2-color (cl-gd:get-pixel y x :image image2)) (img1-color (cl-gd:get-pixel y x :image image1))) (incf err (square (- (the fixnum(cl-gd::gd-image-get-red img2 img2-color)) (the fixnum(cl-gd::gd-image-get-red img1 img1-color))))) (incf err (square (- (the fixnum(cl-gd::gd-image-get-green img2 img2-color)) (the fixnum(cl-gd::gd-image-get-green img1 img1-color))))) (incf err (square (- (the fixnum(cl-gd::gd-image-get-blue img2 img2-color)) (the fixnum(cl-gd::gd-image-get-blue img1 img1-color)))))))) err)) This is the result of running the above pair of functions on a 1024x768 image. ---- First, the timing with the standard CL-GD: (SBCL 1.0.28, CL-GD 0.5.6, UFFI-1.6.1, 3GHz Intel Core2 Duo, Linux)) CL-GD uses UFFI by default on SBCL EVO-LISA> (progn (defparameter *image1* (cl-gd:create-image-from-file "023.JPG")) (defparameter *image2* (cl-gd:create-image-from-file "023.JPG")) (time (compare-images *image1* *image2*))) height1=1024, height2=768 Evaluation took: 1.684 seconds of real time 1.688105 seconds of total run time (1.688105 user, 0.000000 system) 100.24% CPU 5,061,067,326 processor cycles 141,296 bytes consed 0 EVO-LISA> (progn (defparameter *image1* (cl-gd:create-image-from-file "023.JPG")) (defparameter *image2* (cl-gd:create-image-from-file "023.JPG")) (time (compare-images-raw *image1* *image2*))) height1=1024, height2=768 Evaluation took: 1.476 seconds of real time 1.424088 seconds of total run time (1.420088 user, 0.004000 system) 96.48% CPU 4,437,702,108 processor cycles 106,112 bytes consed 0 ----- After changing cl-gd.asd so that CFFI-UFFI-COMPAT is used for SBCL instead of UFFI: ;;;;;;;; EVO-LISA> (progn (defparameter *image1* (cl-gd:create-image-from-file "023.JPG")) (defparameter *image2* (cl-gd:create-image-from-file "023.JPG")) (time (compare-images *image1* *image2*))) height1=1024, height2=768 Evaluation took: 0.336 seconds of real time 0.336021 seconds of total run time (0.336021 user, 0.000000 system) 100.00% CPU 1,010,111,976 processor cycles 21,712 bytes consed 0 EVO-LISA> (progn (defparameter *image1* (cl-gd:create-image-from-file "023.JPG")) (defparameter *image2* (cl-gd:create-image-from-file "023.JPG")) (time (compare-images-raw *image1* *image2*))) height1=1024, height2=768 Evaluation took: 0.282 seconds of real time 0.284018 seconds of total run time (0.284018 user, 0.000000 system) 100.71% CPU 845,516,097 processor cycles 21,936 bytes consed 0 ------------ Surprisingly, there is a 5x difference between using CFFI and UFFI. Pixel-level access to an image, as provided by cl-gd:get-pixel, and cl-gd:color-component, is usually used in image processing, where cl-gd:get-pixel, and cl-gd:color-component will be called for many pixels on the image (usually the whole image), so the speed of these accessors is critical for image processing, and for some reason, CFFI (viat cffi-uffi-compat) offers 5x faster pixel level access than UFFI. I don't know much about either CFFI or UFFI, but CFFI-UFFI-COMPAT is the default already for CLISP and OpenMCL. Maybe it's worth considering making CFFI-UFFI-COMPAT the default for SBCL as well? Regards, Alex Fukunaga

2 1

[cl-gd-devel] problem compiling cl-gd-glue.c on 64-bit sytem
by Jeff Cunningham 17 Oct '08

17 Oct '08

Has anyone had a problem compiling the cl-gd-glue.c into the shared library on a 64-bit system? It's never given me any problem on 32-bit systems, and I could swear I've done it on a 64-bit AMD Debian system before, but I just tried it on a new one and got this error: make gcc -I/usr/local/include -fPIC -c cl-gd-glue.c ld -shared -lgd -lz -lpng -ljpeg -lfreetype -liconv -lm -lc cl-gd-glue.o -o cl-gd-glue.so -L/usr/local/lib ld: /usr/local/lib/libz.a(compress.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libz.a: could not read symbols: Bad value make: *** [cl-gd-glue.so] Error 1 I'm trying to install cl-gd-0.5.6 straight from Edi's site. gd-2.0.35 is installed, along with the other dependencies. This is puzzling. Jeff

1 1

[cl-gd-devel] PNG compression
by Andrei Stebakov 02 Oct '08

02 Oct '08

I was experimenting with write-png-to-stream trying :compression-level from -1 to 9 but it doesn't change the size of the image. For jpeg quality level works though. What can I check for PNG compression to work? Thank you, Andrew

2 7

[cl-gd-devel] Re: CL-GD: Documentation error for COLOR-COMPONENT
by Edi Weitz 01 Oct '08

01 Oct '08

On Sun, 28 Sep 2008 13:13:25 -0700, "J\.P\. Larocque" <jpl(a)thoughtcrime.us> wrote: > The documentation for CL-GD seems to be wrong for the > COLOR-COMPONENT function: > > [Function] > color-component color component &key image => component > > Returns the specified color component of color. component can > be one of :RED, :GREEN, :BLUE, and :ALPHA. > > The color and component parameters should be swapped: > > [Function] > color-component component color &key image => component > > This seems to reflect the state of CL-GD 0.5.6, and the example for > COLOR-COMPONENT in the documentation. Thanks for catching that. Will be fixed in the next release. > Thanks for yet another great library, You're welcome... :)

1 0

[cl-gd-devel] New invitation from Paul Thirumalai
by Paul Thirumalai 05 Sep '08

05 Sep '08

You have been invited to connect as friends with Paul Thirumalai <paul.thirumalai(a)gmail.com> Please accept or reject this invitation by clicking below: http://www.bebo.com/in/7750480921a926669489b135 ...................................................................... Please do not reply directly to this email. This email was sent to you at the direct request of Paul Thirumalai <paul.thirumalai(a)gmail.com>. You have not been added to a mailing list. If you would prefer not to receive invitations from ANY Bebo members please click here - http://www.bebo.com/unsub/7750480921a926669489 Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.

1 0

[cl-gd-devel] images from binary data
by Ryszard Szopa 30 Apr '08

30 Apr '08

Hi, CL-GD makes it very easy to output images as bytes to streams. However, I haven't noticed any solutions for doing the opposite, that is to create a picture from binary data (all the macros want either strings or pathnames). How would I do it? Is it going to be very difficult? What are the caveats? (I am thinking of storing images in BDB through Elephant.) Cheers and thanks in advance, -- Richard -- http://szopa.tasak.gda.pl/

3 8

[cl-gd-devel] with-resized-image macro
by Ryszard Szopa 28 Apr '08

28 Apr '08

Hi Edi, I was needing to resize images quite often, so I rolled a `with-resized-image' macro: (defmacro with-resized-image ((name x &key y (image '*default-image* img-provided)) &body body) "Rescale `image' so that its width is equal `x' pixels. If `y' is provided, make its height equal `y' pixels. If `y' isn't provided, try to keep the proportions of the image right." (let ((%image (gensym "image")) (%new-y (gensym "new-y")) (%y (gensym "y"))) `(let* ((,%image ,image) (,%y ,y)) (multiple-value-bind (old-x old-y) (image-size ,%image) (let* ((new-to-old-proportion (/ ,x old-x)) (,%new-y (or ,%y (round (* old-y new-to-old-proportion))))) (with-image (,name ,x ,%new-y t) (copy-image ,%image ,name 0 0 0 0 old-x old-y :resize t :dest-width ,x :dest-height ,%new-y) ,@body)))))) (defmacro with-resized-image* ((x &key y image) &body body) `(with-resized-image (*default-image* ,x :y ,y ,@(when image (list :image image))) ,@body)) Do you think it does what is supposed to do properly? I mean, I know it *does* resize images, but I am not so sure it does it in the *right* way (right relative to cl-gd). :) Anyway, if you were interested in including this into cl-gd, I can provide a proper patch with unit tests and such stuff. Cheers, -- Richard -- http://szopa.tasak.gda.pl/

1 0

[cl-gd-devel] cl-gd on 64 bit Lisp with do-pixel
by Hans Hübner 16 Feb '08

16 Feb '08

Hi, I'm trying to use cl-gd on a 64 bit platform and I have a problem with DO-PIXELS applied to a truecolor image: (with-image-from-file (image "/home/hans/affe.jpg") (do-pixels (image) (format t "~A~%" (raw-pixel)))) fails with a memory access violation error, both on openmcl and on sbcl on FreeBSD/amd64. Do others see this, too, on 64 bit Lisps? I want to rule out that it is a problem with gd on FreeBSD or the fact that I am using CFFI-UFFI-COMPAT. I have only quickly looked at cl-gd/misc.lisp and I saw that it uses :int as type specifier where I think a more specific data type like uint32 or some such would have been required. But it could all be me. So, does anyone here run cl-gd on a 64 bit Lisp? Thanks, Hans

2 4