Funny, I just learned about the dynamic image generation yesterday.

I don't see a problem being forced to use a custom HttpHandler. That also gives you lots of power on things you may want to do with or do to the image before returning it to the client. Then again, maybe you could have done these things anyway in an event for this control/service.

Todd, sure, but a 3rd party control dev can't add handlers smoothly. Registering handlers is a web.config-modification thing. Whidbey brings the ability to modify the configuration file from your code, but that requires the asp.net user to have write perms to web.config, which it might not have. What I've done in the past where a control needs a handler is document the requirement and throw an exception if they don't register the handler, but as we all know, nobody reads documentation, and "exceptions are bugs", so it's ultimately not a smooth experience for anybody.

DynamicImagine was one of those things that falls in the "Why didn't I think about that" category. The actual implementation is fairly simple an I plan on using it myself even if I have to code it myself. BTW, where is the "cut" list published?

The death of DynamicImage gives more life to our ImageDraw :-)
But, as Andy wrote, dynamic image generation for controls dev is hard to implement.

I tend to send image requests via an aspx page and manipulate the image that way. Flexible (as the params are all in the URL) and easity tweakable.

I realise theres un-neccessary overheads but our solutions needs to stream the files in from an external directory anyway so i figure it might aswell resample the image too. How bad is this??!