Serving many on-the-fly generated images with Django
All this works fine when the tiles are statically served. Now I added
  the option to generate those tiles on the fly -- different images are
  merged, color corrected, …. This works, but is some heavy load for the
  web server as one image takes about 0.1s to be generated.

You need a load balancer, with image requests being sent to a front-end server (e.g. NginX) that will multiplex (and cache!) as many requests as needed, provided you supply enough backend servers to do the heavy lifting.
This looks like a classic case for Amazon distributed computing: you could store the tiles in S3 storage (or maybe NFS over EBS). All the image manipulation servers get the data from a single image repository.
At the beginning, you can have both the Web application and one instance of the image manipulation server on the same machine. But basically your processes are three:

Web serving that calculates image URLs (you'll need some way to encode the manipulation as parameters in the URLs, otherwise you'll have to use cookies and session storage, which is ickier)
image server that receives the "image formula" and provides the JPEG tile
file server that allows access to the large images or single original tiles

I have worked at several such architectures, wherein our image layers were stored in a single image file (e.g. five zoom levels, each fifteen channels from FIR to UV, for a total of 75 "images" up to 100K pixels on a side, and the client could request 'Zoom level 2, red channel plus double of difference between UV-1 channel and green, tiles from X=157, Y=195 to X=167,Y=205').
Similar to a tiling server for spatial image data, I want to view many on-the-fly generated images in my Django based web application (merge images, color change, etc.). Since one client can easily request many (>100) images in a short time, it is easy to bring the web server (Apache + mod_wsgi) down.
Hence, I am looking for alternative ways. Since we already use Celery, it might be a good idea to do this image processing asynchronously and push the generated data to the client. To get started with that I switched the WSGI server to be gevent with Apache used as a proxy. However, I haven't managed to get the push thing working yet and I am not quite sure if this is the right direction anyway. Based on that I have three questions:

Do you think this (Celery, gevent, Socket.IO) is a sensible way to allow many clients to use the application without bringing the web server down? Do you see alternatives?
If I hand over the image processing to Celery and let it push the image data to the browser when it is done, the connection won't go through Apache, will it?
If some kind of pushing to the client is used, would it be better to use one connection or one for each image (and close it when done)?

Background:
The Django application I am working on allows a user to display very large images. This is done by tiling the large images before and show only the currently relevant tiles in a grid to the user. From what I understand this is the standard way to serve data in the field of mapping and spatial image data (e.g. OpenStreetMap). But unlike mapping data, we also have many slices in Z a user can scroll through (biological images).
All this works fine when the tiles are statically served. Now I added the option to generate those tiles on the fly -- different images are merged, color corrected, …. This works, but is some heavy load for the web server as one image takes about 0.1s to be generated. Currently we use Apache with mod_wsgi (WSGIRestrictedEmbedded On) and it is easy to bring the server down. Just browsing through the image stack will lead to a hanging web server. I already tried to adjust MaxClients, etc. and turned KeepAlive off. I also tried different thread/processes combinations for mod_wsgi. However, nothing helped enough to allow usage for more than one user. Therefore, I thought a Comet/WebSocket way could help here.