[cl-gd-devel] images from binary data
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/
On Mon, 28 Apr 2008 14:08:47 +0200, "Ryszard Szopa" <ryszard.szopa@gmail.com> 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.
On Mon, Apr 28, 2008 at 2:08 PM, Ryszard Szopa <ryszard.szopa@gmail.com> 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
On Mon, 28 Apr 2008 15:15:05 +0200, "Hans Hübner" <hans@huebner.org> 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.
On Mon, Apr 28, 2008 at 3:32 PM, Edi Weitz <edi@agharta.de> 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
On Mon, 28 Apr 2008 15:32:36 +0200, Edi Weitz <edi@agharta.de> 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
On Mon, Apr 28, 2008 at 3:15 PM, Hans Hübner <hans@huebner.org> wrote:
On Mon, Apr 28, 2008 at 2:08 PM, Ryszard Szopa <ryszard.szopa@gmail.com> 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/
2008/4/29 Ryszard Szopa <ryszard.szopa@gmail.com>:
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?
From what I remember, SBCL and CCL try to re-load all those shared
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. 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
On Tue, 29 Apr 2008 13:33:18 +0200, "Ryszard Szopa" <ryszard.szopa@gmail.com> 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.
participants (3)
-
Edi Weitz -
Hans Hübner -
Ryszard Szopa