# C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

© 2006-2015 Andrew Cooke (site) / post authors (content).

## Functional Images Summary

From: "andrew cooke" <andrew@...>

Date: Fri, 20 Jan 2006 08:32:16 -0300 (CLST)

---------------------------- Original Message ----------------------------
Subject: Functional Images [Was: [plt-scheme] newbie - plotting points]
From:    "andrew cooke" <andrew@...
Date:    Fri, January 20, 2006 08:17
To:      "scheme" <plt-scheme@...
--------------------------------------------------------------------------

If you're interested in a more functional paradigm for images you might
look at Pan - http://conal.net/pan/

The idea is to represent images as functions.

Pan uses C code in places for speed - it's implemented as a language
embedded in Hakell that's somehow compiled via C (I can't remember the
details any more but there are papers at http://conal.net/pan/papers.htm)

I wrote a pure Haskell version because I wasn't that concerned about speed
and was frustrated with the limitations of the embeddded language.  It's
called Pancito and is available here -
http://www.acooke.org/jara/pancito/index.html  Someone once put some
effort into speeding it up (using unboxed types, mutable arrays), but they
never gave me the code, unfortunately.

You can get an idea of the code from the literate source, which is also
the manual - http://www.acooke.org/jara/pancito/Pancito2.pdf

Some images of mine are here (not all use Pancito) -
http://www.acooke.org/pancito/intnleng/index.html

The style of image you get with this approach is very different to DBN.
DBN places much more emphasis on lines / boxes (things with hard edges);
with functional images it's very difficult to get a line, much easier to
vary things smoothly across the surface of the image.

For example this image - http://www.acooke.org/pancito/intnleng/paper.html
- is defined using a function that shades a surface either side of a "fold
line"; the function is also a function of position/angle (of the fold).
So the final image is defined by currying that function with random fold
points and then composing those curried functions to get a final transform
for the whole surface.  Computing that image at 6000x6000 took several
days on a 2MHz desktop a few years ago.

The lines in an image like this -
http://www.acooke.org/pancito/intnleng/migraine.html - come from the
underlying plane that is transformed.  So that image is the result of
applying many functions to a plane that originally contained a single
(hard-edged) circle.

Since I'm already in an orgy of self links, here are the details of what I
ended up doing in scheme thanks to the help from people here (not pretty!
- just exploring numeric values)
http://www.acooke.org/cgi/photo.py?start=fib-fractal
http://www.acooke.org/cgi/photo.py?start=fib-curves

Andrew