[plt-scheme] 2htdp/image questions

From: Stephen Bloch (sbloch at adelphi.edu)
Date: Sun Apr 18 08:52:44 EDT 2010

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100418/02336af7/attachment.html>

Posted on the users mailing list.