[Haskell-cafe] Re: [Haskell] Image manipulation

[Dan Piponi]

Jerzy,

There is a simple framework for performing filtering operations on
images lazily: http://sigfpe.blogspot.com/2006/12/evaluating-cellular-automata-is.html
(Scroll down to the 2D example in the comments.)

2D digital filters lend themselves nicely to a comonadic framework
though you probably have to drop the comonads for operations other
than convolution type things. And you're right, doing this lazily at
the pixel level is expensive. However, if we replace pixels with
256x256 blocks, say, where the blocks themselves are strict but the
images are lazily made up of blocks, then we have the potential for a
nice and efficient image processing library that inherits its laziness
directly from Haskell.

On 10/30/07, jerzy.karczmarczuk at info.unicaen.fr
<jerzy.karczmarczuk at info.unicaen.fr> wrote:
> Dan Piponi adds to a short exchange:
>
> > jerzy.karczmarczuk:
> >> [iso-8859-1] Bj�rn Wikstr�m writes:
> >>
> >> > Hi! I have lots and lots of images (jpegs) that I would like to manipulate
> >> > and shrink (in size). They are around 5 Mb big, so I thought this would
> >> > be a good Haskell project since it's a lazy evaluating language.
> >> ...
> >> I must say that I don't see much use of laziness here.
>
> > Laziness plays a big role in real world image processing. Typically,
> > in applications like Apple's Shake, you build a dataflow
> > representation of the image processing operations you wish to perform,
> > and the final result is computed lazily so as to reduce the amount of
> > computation. For example, if you blur an image, and then zoom in on
> > the top left corner, then only the top left corner will be loaded up
> > from the original image (assuming your image file format supports
> > tiled access). You still work on tiles or scan-lines, rather than
> > individual pixels, so the laziness has a 'coarse' granularity.
> >
> > But I'm not sure if this is what the original poster was talking about.
>
> I am neither...
> Still, Dan, I think that there is quite a difference between incremental
> processing of signals, and images, etc., and the *lazy evaluation* of
> them. Of course, a stream is consumed as economically as it can, but
> not less. If you filter an image (shrinking, so some low-pass MUST be
> done), a pixel must be loaded with its neighbourhood, which means *some*
> scan lines.
> With a JPEG this means that a 8x8 block should be loaded also with its
> vicinity. But would you suggest that individual pixel processors should
> be lazy? It would be useless, and probably resulting in some penalties.
>
> So, the laziness of Haskell for me here is less than useful.
> Noooow, the lazy *generation* of streams is another story...
> Generating music (low level, i.e. sound patterns) through lazy algorithms
> is quite interesting.
>
> Jerzy Karczmarczuk
>
>
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>