This suggestion is a little bit more complex that standard on-the-fly resizing. Here is the full suggestion:

Extend getMediaObject.ashx such that, when this feature is enabled, it accepts a set of optional query parameters including width, height, dpi, compression, and relative image path and returns the resized image. For example, in my image tag, a url could be: http://myserver/getMediaObject.ashx?[Current query parameters]&w=200&dpi=72&compression=95. This query would return a 200px wide, 72dpi, 95% quality image.

There are some hefty security & administration implications with this. A malicious user could very effectively DDOS your webserver just by refreshing the url, using 100% of the CPU time as the server tries to resize the image hundreds of times per second. Too much caching would fill up the disk as the server created images for practically every height, width, dpi, and compression ratio. Too little caching could lead to the same DDOS effect of #1, even with non-malicious traffic.

To circumvent (some of) these issues, the extensions should require a whitelist of referrers to be enabled. Prior to linking to my image, I add my domain(s) to the whitelist in the configuration and only then does the server modify and then cache my image. Somebody not on the whitelist who hotlinks the image gets the original image rather than the modified image. While the referrer can be spoofed, it gives a little bit of protection.

To keep the modified images from filling the storage, garbage collection should be done. The administrator sets a number of days (for example 30) in the configuration. If the cached version of the modified image has not been served in over 30 days, the cached image would be deleted. In the case of an infinitely powerful server, setting the number of days to 0 disables caching. This could be run on a timer or manually.

To disable the features, the administrator would leave the whitelist empty. In the case of an administrator that has an infinite amount storage and wants to enable the features for all domains, they would use the wildcard (*).

I hope this makes sense and isn't terribly confusing. I've had plenty of time to think about it - I was undertaking a similar project myself but gave up after some time. I don't know how terribly difficult it would be, but it looks as if you've already got the main components in place in other parts of the project. It looks as if you're already resizing, compressing, and resampling in other places of the GalleryServerPro so a majority of the "heavy lifting" is already implemented.