From ryszard.szopa at gmail.com Mon Apr 28 12:23:41 2008 From: ryszard.szopa at gmail.com (Ryszard Szopa) Date: Mon, 28 Apr 2008 14:23:41 +0200 Subject: [cl-gd-devel] with-resized-image macro Message-ID: <19e19e410804280523i2807d691l7d86a23ddc43550e@mail.gmail.com> 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) , at body)))))) (defmacro with-resized-image* ((x &key y image) &body body) `(with-resized-image (*default-image* ,x :y ,y ,@(when image (list :image image))) , at 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/ From ryszard.szopa at gmail.com Mon Apr 28 12:08:47 2008 From: ryszard.szopa at gmail.com (Ryszard Szopa) Date: Mon, 28 Apr 2008 14:08:47 +0200 Subject: [cl-gd-devel] images from binary data Message-ID: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> 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/ From edi at agharta.de Mon Apr 28 13:13:38 2008 From: edi at agharta.de (Edi Weitz) Date: Mon, 28 Apr 2008 15:13:38 +0200 Subject: [cl-gd-devel] images from binary data In-Reply-To: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> (Ryszard Szopa's message of "Mon, 28 Apr 2008 14:08:47 +0200") References: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> Message-ID: On Mon, 28 Apr 2008 14:08:47 +0200, "Ryszard Szopa" wrote: > 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? The reason this is not in there is that CL-GD is basically just a pretty thin layer atop the original GD library and at the time it was written this functionality obviously didn't exists in GD. That was some time ago and maybe it's in there now. I haven't kept track in the last years. Short of using temporary intermediate files I wouldn't know how to do what you want in portable CL based on the current CL-GD code. Cheers, Edi. From hans at huebner.org Mon Apr 28 13:15:05 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 28 Apr 2008 15:15:05 +0200 Subject: [cl-gd-devel] images from binary data In-Reply-To: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> References: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> Message-ID: On Mon, Apr 28, 2008 at 2:08 PM, Ryszard Szopa wrote: > 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? It would not be difficult, but only a little tedious as you would need to add new stub functions to cl-gd-glue.c that call the right gdImageCreateFrom*Ptr function (available in GD2) for the file format in question. Also, memory handling would be an issue, but you're certainly aware of that. I'm not sure how many cl-gd users there are, but I'm certainly one of them. So please, if you add this, do it in an additive fashion :) -Hans From edi at agharta.de Mon Apr 28 13:32:36 2008 From: edi at agharta.de (Edi Weitz) Date: Mon, 28 Apr 2008 15:32:36 +0200 Subject: [cl-gd-devel] images from binary data In-Reply-To: (Hans =?iso-8859-1?q?H=FCbner's?= message of "Mon, 28 Apr 2008 15:15:05 +0200") References: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> Message-ID: On Mon, 28 Apr 2008 15:15:05 +0200, "Hans H?bner" wrote: > gdImageCreateFrom*Ptr function (available in GD2) Ah, I wasn't aware of that. > I'm not sure how many cl-gd users there are, but I'm certainly one > of them. So please, if you add this, do it in an additive fashion > :) FWIW, I currently am /not/ a CL-GD user... :) I wonder if it would make sense to use a common-lisp.net repository instead of my local one so that "interested third parties" could go wild on the code. Hans? Ryszard? Anyone else? BTW, what are your thoughts on this issue? http://common-lisp.net/pipermail/cl-gd-devel/2008-January/thread.html As I said, I think the Right Thing[TM] would be to get rid of LOAD-GD-GLUE and to load the C libs on demand using relative pathnames to make integration with delivered applications painless. From hans at huebner.org Mon Apr 28 13:48:34 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Mon, 28 Apr 2008 15:48:34 +0200 Subject: [cl-gd-devel] images from binary data In-Reply-To: References: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> Message-ID: On Mon, Apr 28, 2008 at 3:32 PM, Edi Weitz wrote: > I wonder if it would make sense to use a common-lisp.net repository > instead of my local one so that "interested third parties" could go > wild on the code. Hans? Ryszard? Anyone else? I have no current plans to change cl-gd, but I would be gladly reviewing patches and act as a peer reviewer. > BTW, what are your thoughts on this issue? > > http://common-lisp.net/pipermail/cl-gd-devel/2008-January/thread.html > > As I said, I think the Right Thing[TM] would be to get rid of > LOAD-GD-GLUE and to load the C libs on demand using relative pathnames > to make integration with delivered applications painless. I agree - It would be preferable if the glue library would be integrated with the standard shared library loading mechanism that the host Lisp provides for. The explicit loading has been paining me a few times, but I always was able to somehow work around it. If someone wants to take the stab (Ryszard?) and put some work into cl-gd, I can test on several platforms and also review the code. Ryszard, the WITH-RESIZED-IMAGE macro looks useful, although as you might imagine I have my own version of this function. For the sake of the next user, I'd like to see your macro added. I would lose the % prefixes in your gensymed macro names, though, and use WITH-UNIQUE-NAMES instead. -Hans From ryszard.szopa at gmail.com Tue Apr 29 11:33:18 2008 From: ryszard.szopa at gmail.com (Ryszard Szopa) Date: Tue, 29 Apr 2008 13:33:18 +0200 Subject: [cl-gd-devel] images from binary data In-Reply-To: References: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> Message-ID: <19e19e410804290433q7188e358wc752504f42c382ef@mail.gmail.com> On Mon, Apr 28, 2008 at 3:15 PM, Hans H?bner wrote: > On Mon, Apr 28, 2008 at 2:08 PM, Ryszard Szopa wrote: > > 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? > > It would not be difficult, but only a little tedious as you would need > to add new stub functions to cl-gd-glue.c that call the right > gdImageCreateFrom*Ptr function (available in GD2) for the file format > in question. Also, memory handling would be an issue, but you're > certainly aware of that. > > I'm not sure how many cl-gd users there are, but I'm certainly one of > them. So please, if you add this, do it in an additive fashion :) Huh, the problem is that I have no C experience whatsoever and UFFI is like black magic for me... I looked at the documentation of both UFFI (cannot say it is really helpful) and libgd and I actually found the functions I should be calling. Moreover, I think I have quite a clear mental image of what I should be doing (ie. something like in create-image-from-file from the moment it gets an image pointer). My problem (lame as it may be) is that I don't have a clue on how to pass a CL array (exactly, the pointer to a lisp array) to the C function, and I didn't find any examples of code doing such thing. Also, why do I have to create a stub function in cl-gd-glue.c? Isn't it enough if I declared the gdImageCreateFrom*Ptr functions with def-function? Anyway, if I manage to figure this stuff out I will definitely share it (at least for the sake of code review:-)) My three cents for the load-gd-glue issue: I understand that a #-lispworks thingie is too much of a kludge for you? :) Lispworks users would have to call load-cl-glue explicitly, and all the thousands of SBCL happy hamsters (me among them) would just keep using cl-gd as before, without noticing anything...OTOH... yeah, that sounded very sbcl-centric and selfish... Let's admit, having to explicitly call load-gd-glue is (at least for me) bothering from the aesthetic point of view. To make things worse, I know of at least one case of CL-GD being broken with SBCL on a Mac, and it was an issue related to not being able to find libraries (I haven't investigated that thing thoroughly, but now my suspect is load-gd-glue). So, I would go for some ASDF magic. For what I know, Elephant has quite a complex loading scheme, with delayed loading: maybe taking a look on what they do would be a good point to start? As for "going wild with cl-gd's code" thing: I have the feeling that as a guy who is clueless about C and UFFI I would be a rather poor choice for a maintainer of a library that's a wrapper over a C library. I hope that you guys agree. :) But, I can rewrite my macro to use with-gensyms, and I can try to help with the loading issue. Cheers, -- Richard -- http://szopa.tasak.gda.pl/ From hans at huebner.org Tue Apr 29 12:09:30 2008 From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 29 Apr 2008 14:09:30 +0200 Subject: [cl-gd-devel] images from binary data In-Reply-To: <19e19e410804290433q7188e358wc752504f42c382ef@mail.gmail.com> References: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> <19e19e410804290433q7188e358wc752504f42c382ef@mail.gmail.com> Message-ID: 2008/4/29 Ryszard Szopa : > I looked at the documentation of both UFFI (cannot say it is really > helpful) and libgd and I actually found the functions I should be > calling. Moreover, I think I have quite a clear mental image of what I > should be doing (ie. something like in create-image-from-file from the > moment it gets an image pointer). My problem (lame as it may be) is > that I don't have a clue on how to pass a CL array (exactly, the > pointer to a lisp array) to the C function, and I didn't find any > examples of code doing such thing. > > Also, why do I have to create a stub function in cl-gd-glue.c? Isn't > it enough if I declared the gdImageCreateFrom*Ptr functions with > def-function? It may be possible to call the functions directly, but I'm not sure - I don't currently have the time to look into this myself, and for my database system, I am using files for blobs and don't have the need to keep raw image data in RAM. About the load-gd-glue issue: Ideally, one would want to be able to dump an image of a Lisp with cl-gd loaded and be able to restart it without having to call load-gd-glue. I have spent some time with this, but I think I am not yet there yet. If there are other things that make a release of cl-gd worthwhile, I would spend another few hours on this in order to make it work. At the moment, it is not pressuring me. >From what I remember, SBCL and CCL try to re-load all those shared libraries that have been loaded at image dump time. Ideally, they would not use any absolute path names for that and instead use LD_LIBRARY_PATH. And, if I further remember right, the problem with cl-gd-glue.so is that it is loaded with an absolute path name or some such. Sorry that this is a little sketchy. -Hans From edi at agharta.de Tue Apr 29 13:12:46 2008 From: edi at agharta.de (Edi Weitz) Date: Tue, 29 Apr 2008 15:12:46 +0200 Subject: [cl-gd-devel] images from binary data In-Reply-To: <19e19e410804290433q7188e358wc752504f42c382ef@mail.gmail.com> (Ryszard Szopa's message of "Tue, 29 Apr 2008 13:33:18 +0200") References: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> <19e19e410804290433q7188e358wc752504f42c382ef@mail.gmail.com> Message-ID: On Tue, 29 Apr 2008 13:33:18 +0200, "Ryszard Szopa" wrote: > My problem (lame as it may be) is that I don't have a clue on how to > pass a CL array (exactly, the pointer to a lisp array) to the C > function, and I didn't find any examples of code doing such thing. Some Lisps (e.g. LispWorks) can pass a pointer to a CL array to a C function, but only in certain cases, namely if the array was allocated statically and if it has a specified (C-compatible) element type. (See the recently released CL-DONGLE library for example code.) But I don't think UFFI can do that. > Also, why do I have to create a stub function in cl-gd-glue.c? Isn't > it enough if I declared the gdImageCreateFrom*Ptr functions with > def-function? I don't think you have to create a stub. The stubs in CL-GD are only needed for functions that deal with files and to replace C macros with C functions. > I understand that a #-lispworks thingie is too much of a kludge for > you? :) For me it's not really a problem, as I'm not using CL-GD... :) But I think such a kludge is not needed. As Hans said, the right way to do it would be to use delayed loading instead of immediate loading and to not hardcode the library paths. As for delayed loading, that /should/ be trivial but IIRC immediate loading is hard-coded into UFFI. As for hardcoded paths - have you ever seen a C/C++ app which uses the hardcoded library paths of the developer machine it saw at build time? Cheers, Edi. From edi at agharta.de Wed Apr 30 08:40:02 2008 From: edi at agharta.de (Edi Weitz) Date: Wed, 30 Apr 2008 10:40:02 +0200 Subject: [cl-gd-devel] images from binary data In-Reply-To: (Edi Weitz's message of "Mon, 28 Apr 2008 15:32:36 +0200") References: <19e19e410804280508x1ac9e29axb96da9630f26271e@mail.gmail.com> Message-ID: On Mon, 28 Apr 2008 15:32:36 +0200, Edi Weitz wrote: > I wonder if it would make sense to use a common-lisp.net repository > instead of my local one so that "interested third parties" could go > wild on the code. There you are: http://trac.common-lisp.net/cl-gd/browser/trunk