[plt-scheme] 2htdp/image questions

As it turns out, That is a bad idea for performance reasons (computing
the bitmap is far more expensive than any of the other things that get
done to images) but image equality has to do that (in the fallback
slow path), so it would not be too hard to add a get-pixel function
that first computed the image and the returned the pixel.

Note that the current design of the image api works hard to avoid
working with bitmaps not only because it is inefficient, but also
because you cannot have a high quality rotate or scale functions
(things will get pixelated).

If you are really serious about this, then, I think that you probably
want to design your own api.

Also perhaps worth noting, such loops are probably easily
parallelizable, in most cases. I'm not sure if futures are up to the
task or not, tho.

Robby

On Sun, Apr 18, 2010 at 7:52 AM, Stephen Bloch <sbloch at adelphi.edu> wrote:
> I was at a CS education conference over the weekend, and saw a number of
> people showing off the things their students can do to images in the first
> week or two of class in Python.  For the most part, these operations boil
> down to (not real Python syntax)
> for i = 1 to image.height
> for j = 1 to image.width
> image.pixel[i,j] = some modification of image.pixel[i,j]
> Of course, as everyone on this list knows, the loops are a distraction from
> what's really going on: we don't actually care in what order the pixels are
> processed, as long as they all get processed and the results put together.
> So to be able to beat the Pythonistas at this game, a Schemer would need
> ; map-image : (color -> color) image -> image
> or better yet
> ; map-image : (x y color -> color) image -> image
> which allows you to easily write, for example, a color gradient transform.
> Of course, that only builds images the same size and shape as the original
> image, and each pixel of the result can only depend on the corresponding
> pixel of the original (you can't write smoothing, edge detection, shadowing,
> etc.)  So one would also want the more general function
> ; build-image : width height (x y -> color) -> image
> But if I want my students to be able to use this before they've seen local
> or lambda, I would want them to be able to specify "side parameters" (which
> are curried in before calling the above version):
> ; build-image : width height (x y . others -> color) . others -> image
> I think I can figure out how to do most of this, although I'm sure it would
> be done quicker and better if some of the PLT image gurus out there wanted
> to help :-)
> But here's the part I'm having trouble with.  In most applications of
> build-image, some or all of the "others" will be images, and the
> user-provided function will want to call
> ; get-pixel : x y image -> color
> on them.  In order to "get-pixel", you need to render the 2htdp/images to
> bitmaps, and it makes sense to do that only once before doing presumably
> hundreds or thousands of get-pixel calls.  Which I could do easily if I knew
> that get-pixel would ONLY be called on a bitmap, but the natural,
> beginner-friendly API would have it callable on _any_ 2htdp/image.
> The solution that springs to my mind (alternative suggestions cheerfully
> welcomed!) is for image% to have a bitmap field, initially empty, which is
> cached the first time the image is rendered.  This could be a good idea for
> other performance reasons too, but as far as I can tell it isn't currently
> being done.  (It could also be a memory hog; one might want to mark these
> caches as "expendable" for garbage-collection purposes.)
>
> How much of this is a good idea?  How much is completely off base?
>
> Stephen Bloch
> sbloch at adelphi.edu
>
>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>