Hello,
I'm trying to use Common Lisp to do some image processing but I don't seem
to find a way to do it. What I'd like to do, is to open some image file
(in tiff or jpg format) and to extract the colour information of some
random pixels.
If been searching through some manuals and I believe there is no native
support to do such things (I might have missed it though :)). I've also
been browsing the web for a while and I found no toolboxes/libraries that
would provide me such functionality.
I'm using a Franz Inc. release in Emacs in Linux.
Does anyone know how to get me started ?
Many thanks in advance !
Joris
Joris Bleys wrote:
> Hello,
>
> I'm trying to use Common Lisp to do some image processing but I don't seem
> to find a way to do it. What I'd like to do, is to open some image file
> (in tiff or jpg format) and to extract the colour information of some
> random pixels.
I've got a jpeg reader/writer that you can find here:
http://members.cox.net/vogt/jpeg.lisp
It at least allows you to open jpeg files and get the color information from
some random pixels.
On Mon, 22 Mar 2004 15:54:04 +0100, Joris Bleys <······@nomasp.vub.ac.be> wrote:
> I'm trying to use Common Lisp to do some image processing but I
> don't seem to find a way to do it. What I'd like to do, is to open
> some image file (in tiff or jpg format) and to extract the colour
> information of some random pixels.
>
> If been searching through some manuals and I believe there is no
> native support to do such things (I might have missed it though
> :)). I've also been browsing the web for a while and I found no
> toolboxes/libraries that would provide me such functionality.
>
> I'm using a Franz Inc. release in Emacs in Linux.
>
> Does anyone know how to get me started ?
I think CL-GD should be able to do that:
<http://www.weitz.de/cl-gd/>
Cheers,
Edi.
Hi,
I have read your request, "Image processing and Lisp", Gimp is made with
Guile and Scheme interface, with lisp macro develop around lisp source mix
with C.
Get source and read image manipolation tecnology CL_GL is good for read
image file but for manipolation is required matrix convolution for sharp,
blur, border check, ecc....
For blob Identification (boundary, orientation, size, stocatic id value,
center, balance center, count object, ecc....) i have read good intro
programming source into book rev 2.0 of wilson ( mit Press) d'not remember
ISBN but this book into rev 3.0 d'not report image processing section.
Regards
Max
"Massimo Spataro" <·····@mail4people.com> writes:
> I have read your request, "Image processing and Lisp", Gimp is made with
> Guile and Scheme interface, with lisp macro develop around lisp source mix
> with C.
I think Gimp uses SIOD rather than Guile, but I don't know for sure.
The Book is:
Lisp Second Edition
Patrick Henry Wilson & Paul Horn
ISDN 0-201-08372-8
Cap. 10 Manipolate Binary Image
Start with this sample Image
(suff-image '((0 1 1 0 1 0 0 0 1 0 1 0 1 0)
(0 1 1 0 1 0 0 0 1 0 1 0 1 0)
(0 1 1 0 1 0 0 0 1 0 1 0 1 0)
(0 1 1 0 1 0 0 0 1 0 1 0 1 0)
(0 1 1 0 1 0 0 0 1 0 1 0 1 0))
and loop into array for manipolate image...
Into Linux system is available converter for generate this binary pattern
lispmtopgm and other converter from and to various format Tiff, pgn, gif,
targa, ecc...
regards
Max
Joris Bleys <······@nomasp.vub.ac.be> writes:
> Hello,
>
> I'm trying to use Common Lisp to do some image processing but I don't seem
> to find a way to do it. What I'd like to do, is to open some image file
> (in tiff or jpg format) and to extract the colour information of some
> random pixels.
>
>
> I'm using a Franz Inc. release in Emacs in Linux.
>
> Does anyone know how to get me started ?
>
> Many thanks in advance !
>
> Joris
Hi Joris,
There are a number of ways to do image I/O, which will almost get you
started with image processing. You can use ffi to load a popular image
library. Franz might have something on there site. There are various bits
of CL around with some image capabilities that you could pull out.
Alternatively, I have some probably portable, fairly general (i.e. handles
16bit data) native CL code for dealing with 'portable anymap' files, (.pgm,
.ppm, etc). Most image software can output these, or at least it is easy
to convert to it. It was a quick afternoon job, but you could use that if
you don't have a better option.
cheers,
Simon
Joris Bleys wrote:
> Hello,
>
> I'm trying to use Common Lisp to do some image processing but I don't seem
> to find a way to do it. What I'd like to do, is to open some image file
> (in tiff or jpg format) and to extract the colour information of some
> random pixels.
>
> If been searching through some manuals and I believe there is no native
> support to do such things (I might have missed it though :)). I've also
> been browsing the web for a while and I found no toolboxes/libraries that
> would provide me such functionality.
>
> I'm using a Franz Inc. release in Emacs in Linux.
>
> Does anyone know how to get me started ?
I have a growing set of UFFI bindings to:
http://www.imagemagick.org/
...as a component of a new, portable, CL gui just now crawling out of
the sea at:
ftp://common-lisp.net/pub/project/cello
Look for PortaCello2.zip/.sig, named to reflect that they exist purely
to be ported. It works on win32 on Allegro and Lispworks, and today I
will be merging in code from a team member who did the port to
AllegroCL+Linux, so it might be OK for you.
The ImageMagick bindings are in a separate cl-magick package and
subdirectory. A small number of entry points to the high-level "wand"
interface have been implemented and tested, the rest are there and
partly ready to go, just need a simple final massaging to work. Ask on
the cello-devel mailing list and I will help with that.
But IM does not come with TIFF support, because of (old?) patent issues.
They have instructions on their page on how to expand IM to cover TIFF,
but I have not tried them.
Support on IM is great. They are coming up on a major new release and
are very responsive, so I wager they would get you going on TIFF if you
had any problems.
Note also that there is a GraphicsMagick fork off the IM base, which
might also be of interest.
kt
>
> Many thanks in advance !
>
> Joris
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> wrote:
> I have a growing set of UFFI bindings to:
>
> http://www.imagemagick.org/
>
> ...as a component of a new, portable, CL gui just now crawling out of
> the sea at:
And once these binding mature they will be split to a separate library?
Cheers,
-- Nikodemus (MORE LIBRARIES)
·········@random-state.net wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>I have a growing set of UFFI bindings to:
>>
>> http://www.imagemagick.org/
>>
>>...as a component of a new, portable, CL gui just now crawling out of
>>the sea at:
>
>
> And once these binding mature they will be split to a separate library?
They happen to be split already. Oh, you mean to a separate
common-lisp.net project? That might be a good idea. It would make it
easier to grab, and that might get those sub-projects refined faster.
This open source fairy can't do everything. So I would be kicking off also:
cl-ffx (kenny's sicko extensions to UFFI. hmm, cl-kuffi?)
cl-opengl
cl-glut (as long as we are going granular)
cl-ftgl
cl-magick
and get ready for....
> -- Nikodemus (MORE LIBRARIES)
cl-supercollider
cl-festiva
cl-etc-etc-etc
My only hesitation is that I make no pretense of taking those bindings
seriously in and of themselves. I am just an apps guy, and I just do
what it takes to get the functionality I need. My sicko UFFI extensions
are tailored to work off globally-edited .Hs, so they are quite weird
but effective. And incomplete. I simply do the bindings I need, or the
ones that fall out of a tree into my lap.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Kenny Tilton <·······@nyc.rr.com> wrote:
> They happen to be split already. Oh, you mean to a separate
> common-lisp.net project? That might be a good idea. It would make it
> easier to grab, and that might get those sub-projects refined faster.
Whether they are a separate project or not really doesn't matter: that they
are separately advertised on Cliki with a working asdf-install link does.
> My only hesitation is that I make no pretense of taking those bindings
> seriously in and of themselves. I am just an apps guy, and I just do
Nothing wrong with that -- but the easier they are to notice & find & install
as separate entities, the likelier it is that someone who actually cares
about them for their own sake will appear to carry the burden. Doesn't mean
that it will happen, but I believe that having Cliki page and asdf-link
gives a real boost to the probability.
Take for example cl-ncurses[1]: I wrote an utterly non-functional sketch
when learning UFFI, but stuck a link to the tarball on Cliki -- then
Marcelo Ramos turned up and adopted the project and made it something
usable.
Cheers,
-- Nikodemus
[1] http://www.common-lisp.net/project/cl-ncurses/
Kenny Tilton <·······@nyc.rr.com> writes:
> I have a growing set of UFFI bindings to:
>
> http://www.imagemagick.org/
ImageMagick is a really good library and tool set. But don't you
think it would be nice to have a pure Lisp translation of that
functionality? I know it's sort of reinventing the wheel. Would
that go over better as a translation?
Surely CL has ways of working with binary data in fixed memory or at
least without doing a lot of consing.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>I have a growing set of UFFI bindings to:
>>
>> http://www.imagemagick.org/
>
>
> ImageMagick is a really good library and tool set. But don't you
> think it would be nice to have a pure Lisp translation of that
> functionality? I know it's sort of reinventing the wheel.
Great! How soon can you have that done? <g> Warning: the source distro
is 27mb. Compressed!
Failing that, and given as you say that IM is a fine system, then there
is relatively little advantage to having that in Lisp. The small
advantage is stuff like getting a Lisp backtrace instead of a segfault
when I screw up, stuff like that. But look at the effort even to
translate! (How's it coming, btw? ,g>) And since it is a mature library,
it's pretty much a given.
And what value can be added? It would suck using a C/C++ library such as
gtk as the standard CL gui. A GUI developer /lives/ inside the framework
they are using. So "The CL GUI" must be a hierarchy of pure Lisp
classes, not wrappers for C structs/C++ classes implementing the GUI.
You heard of the Maginot (sp?) Line? This is the Tilton Line: we have
had enough time to develop the core capabilities. Graphics. Sound.
Statistics. Web servers. Those should now be stable, mature black boxes
we can Just Use, implementation language be damned. We also have a great
language with which to harness those, and lots of great applications to
write and get rich on. You want me to port ImageMagick for the next
year? Nahh.
The one Cello library I would like to see ported to Lisp is the Glut. I
started on that after I had Cello working under Freeglut, then came to
my senses. That can wait. The important thing is to make Cello
/functional/ enough to convince commercial vendors to support it.
I'll be up late if you get done early with that IM port. :)
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Kenny Tilton <·······@nyc.rr.com> writes:
> I'll be up late if you get done early with that IM port. :)
I don't think you will be up _that_ late.
How much of IM is being able to read and write six million file
formats vs doing various image editing stuff which is hopefully done
in a unified internal format?
In terms of benefits, I'm thinking of reduced dependencies on
external packages. My personal thought about UFFI is that it is a
hack to use library code that is not availble in Lisp. That's not
necessarily a bad thing because it does get you functionality fast.
But in the "worse is better" vein, I think it should simply be a
stepping stone to "the right way".
Would it be easier to write a Lisp program that could read the C
source code and create a Lisp file from that? Since that is not the
boring grunt work of a translation, that might be more interesting to
do. Hmmm. What a great way to learn C!
I'm still working on the learning Lisp part. I don't think I'm up to
learning AI.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>I'll be up late if you get done early with that IM port. :)
>
>
> I don't think you will be up _that_ late.
>
> How much of IM is being able to read and write six million file
> formats vs doing various image editing stuff which is hopefully done
> in a unified internal format?
MIFF I think is the latter.
>
> In terms of benefits, I'm thinking of reduced dependencies on
> external packages. My personal thought about UFFI is that it is a
> hack to use library code that is not availble in Lisp. That's not
> necessarily a bad thing because it does get you functionality fast.
> But in the "worse is better" vein, I think it should simply be a
> stepping stone to "the right way".
Gonna port OpenGL as well? I think everything you say makes sense in a
world of unlimited resources for translating stuff to Lisp.
>
> Would it be easier to write a Lisp program that could read the C
> source code and create a Lisp file from that?
Great! Start with the headers and generate UFFI output. :) See "cparse".
Since that is not the
> boring grunt work of a translation, that might be more interesting to
> do. Hmmm. What a great way to learn C!
Indeed. And I wager compiler design, and then Lisp. Any open source C
compilers to be had? Was it Golub who had a book showing a C compiler in
C? Modify that to output Lisp instead of assembler, until it is good
enough to translate itself into Lisp. Then yer done.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Kenny Tilton <·······@nyc.rr.com> writes:
> Was it Golub who had a book showing a C compiler in C?
You must mean:
Holub, Allen I., Compiler Design in C, Prentice Hall, 1990.
It's a good book, but translating the code in it would be a really
painful way to start a compiler in Lisp. Lisp is so much better
suited to compiler work than C, it's silly.
--
-Tim
Check out the new PHP compiler: www.roadsend.com
David Steuber <·············@verizon.net> wrote:
> ImageMagick is a really good library and tool set. But don't you
> think it would be nice to have a pure Lisp translation of that
> functionality? I know it's sort of reinventing the wheel. Would
> that go over better as a translation?
A project with something like this in the sights exists (but is
still pretty much at the ground floor):
http://www.common-lisp.net/project/imago/
Cheers,
-- Nikodemus
Joris Bleys <······@nomasp.vub.ac.be> wrote in message news:<······························@nomasp.vub.ac.be>...
> Hello,
>
> I'm trying to use Common Lisp to do some image processing but I don't seem
> to find a way to do it. What I'd like to do, is to open some image file
> (in tiff or jpg format) and to extract the colour information of some
> random pixels.
>
<plug>
Check out cl-jpeg: http://sourceforge.net/projects/cljl/
</plug>
--
Eugene