Hi all,
I'm currently working on a few projects that involve a good deal of
reading and writing images pixel-by-pixel.
Up until this point I've been using cl-gd. However, (after profiling)
I discovered that it is too slow for my purposes. Cl-gd requires a
foreign function call every time I get and set a pixel, and this uses a
great deal of time. I'll be sad to leave it--it's extremely easy to
use.
Anyhow, can anyone suggest a faster image manipulation library? If it
either allows me to write multiple pixels (with different colors) at
once or stores an image representation in the lisp part of code, then
it should work for me.
Simple operations took an incredible amount of time. I had an enormous
increase in speed when I changed color-components to something like the
following:
The issue with gd became apparent when I gained an enormous speed
increase by switching from color-components to the following:
(let ((color (get-pixel x y :image image)))
(list (logand #xFF0000 color)
(logand #x00FF00 color)
(logand #x0000FF color))))
Thanks,
-Stu
On 14 Mar 2006 20:06:17 -0800, "Stu" <·········@gmail.com> wrote:
> I'm currently working on a few projects that involve a good deal of
> reading and writing images pixel-by-pixel.
>
> Up until this point I've been using cl-gd. However, (after
> profiling) I discovered that it is too slow for my purposes. Cl-gd
> requires a foreign function call every time I get and set a pixel,
> and this uses a great deal of time.
Have you tried DO-ROWS, DO-PIXELS-IN-ROW, and friends? That should
make a difference. Actually, these macros were introduced solely
because someone had performance problems.
> Simple operations took an incredible amount of time.
Could you quantify "incredible" in this case? Also, which Lisp
implementation are you using?
You have compiled your code, haven't you?
Cheers,
Edi.
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
I've tried it on SBCL and CMUCL. SBCL compiles by default, I believe.
Here's profiling data from my program:
Consed | Calls | Secs | Sec/Call | Name:
-----------------------------------------------------------
5,831,760 | 22,090 | 6.350 | 0.00029 | MY-GET-PIXEL <--
35,211,552 | 62,208 | 1.560 | 0.00003 | MAGNITUDE
289,544 | 2,209 | 0.660 | 0.00030 | AS-ACTUAL-COLOR <--
8,023,256 | 22,090 | 0.530 | 0.00002 | COLOR-AT
2,866,896 | 2,209 | 0.250 | 0.00011 | CLOSEST-NEARBY <--
1,820,288 | 2,209 | 0.060 | 0.00003 | NEW-COLOR
371,112 | 2,209 | 0.050 | 0.00002 | VECTOR-MEAN
812,912 | 2,209 | 0.050 | 0.00002 | SURROUNDING-PIXELS
1,184,024 | 2,209 | 0.030 | 0.00001 | SURROUNDING-POINTS
-------------------------------------------------------
The indicated functions contain calls to cl-gd, and pretty much only
those calls. Notice, they're much slower that than any other function
in my program, and I need to call them a great deal.
This particular run is on a very basic image and it took 10 seconds. I
need to perform the function on a much larger image, and I need to call
it several times.
I would use DO-ROWS/DO-PIXELS-IN-ROW, however, I need to get pixels in
a non-sequential manner.
I've been trying out cl-png, and it appears to do what I need for this
application much more quickly.
Cl-gd is great, by the way! It's been extremely helpful in other
projects.
All the best,
-Stu
On 15 Mar 2006 14:12:01 -0800, "Stu" <·········@gmail.com> wrote:
> I've tried it on SBCL and CMUCL. SBCL compiles by default, I
> believe.
>
> Here's profiling data from my program:
> Consed | Calls | Secs | Sec/Call | Name:
> -----------------------------------------------------------
> 5,831,760 | 22,090 | 6.350 | 0.00029 | MY-GET-PIXEL <--
> 35,211,552 | 62,208 | 1.560 | 0.00003 | MAGNITUDE
> 289,544 | 2,209 | 0.660 | 0.00030 | AS-ACTUAL-COLOR <--
> 8,023,256 | 22,090 | 0.530 | 0.00002 | COLOR-AT
> 2,866,896 | 2,209 | 0.250 | 0.00011 | CLOSEST-NEARBY <--
> 1,820,288 | 2,209 | 0.060 | 0.00003 | NEW-COLOR
> 371,112 | 2,209 | 0.050 | 0.00002 | VECTOR-MEAN
> 812,912 | 2,209 | 0.050 | 0.00002 | SURROUNDING-PIXELS
> 1,184,024 | 2,209 | 0.030 | 0.00001 | SURROUNDING-POINTS
> -------------------------------------------------------
>
> The indicated functions contain calls to cl-gd, and pretty much only
> those calls. Notice, they're much slower that than any other
> function in my program, and I need to call them a great deal.
>
> This particular run is on a very basic image and it took 10 seconds.
> I need to perform the function on a much larger image, and I need to
> call it several times.
If you have some actual code snippets (small), it might be worthwhile
to check against, say, LispWorks or AllegroCL to see if this is an FFI
overhead that's particularly bad on Python or if it's a general
problem. I tend to think it might be the latter, but who knows...
Cheers,
Edi.
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")