Here's a list of services in this space:
Blitline http://blitline.com/
Chute http://www.getchute.com/
Cloudinary http://cloudinary.com/
imgix http://www.imgix.com/
transloadit http://transloadit.com
The standard is probably using ImageMagick & an appropriate wrapper. Why is using your solution better?
Take into account that you're at least doubling the transfer latency involved, which will frequently dominate the time required to complete an image operation.
end_user->your_user->end_user
end_user->your_user->you->your_user->end_userEven with the resource constraints of the average mobile device, you can often have the operation complete in less time than it would take to transfer the image, particularly under field / non-LAN network conditions.
One simple way around this would be to specialize in more intensive operations, particularly with parallel algorithms that can be done quickly by throwing 50 workers at it. Or alternatively, you could look for situations where the user needs to process a large batch of images asynchronously (then throw 50 workers at it).
There is a lot of room on the market for image processing tools - software, libraries, APIs, whatever. But basic operations which are already well-supported by many drop-in FOSS libaries are usually going to be hard to bring to market.
Add something extra which solves problems unique to the customer's problem domain or workflow. Then you become "the only" instead of "yet another."
If you don't market a feature, or if you're marketing it beside 100 other features, it doesn't exist.
I'm sure there's room, but you really have to ask yourself; room for what? Running anything server is a constant drain on resources, and surely you could strip down and optimize the code from one of these projects to make it run fast enough.
A friend of mine did this back in high school, with blender, not knowing C-family languages at all, 'kingblender'. It runs fast as a bullet. It's a five year old build, but the interface is so streamlined and it loads/runs so fast I still use it myself :P
Reimplementing these functions can be justified... but you really should justify it. For one thing, you automatically lose the metered network market, because they can't afford to be sending things serverside all the time. There goes a bunch of Australian customers.
Outside of the most basic image manipulations, stretch/blur/saturation/Paint.Net-stuff, what features are you thinking of that would run so much better serverside that it's worth building in all that extra network functionality AND the image editing library?
(EDIT: I should clarify; you can embed a stripped down graphicsmagick in your clientside program, it's under MIT license after all. http://www.graphicsmagick.org/Copyright.html Some people complain about limited system resources on mobile platforms... Well, those people, frankly, are full of shit. I've seen Minecraft and Portal clones run on the Nintendo DS Lite. That thing has 4MB RAM and no hardware floats, all software emulated :P The 'Mixed in Key' guys run their audio analysis off their server, and as a result have a 15MB cap and some unhappy customers. On the other hand, they've got an algorithm they're trying to protect. If you're not heavily investing in a custom algorithm, or unique new features, then serverside image editing is just plain silly.)