Ask HN: Would you use an API for image processing?
I'm working on an API that will allow developers to offload their image processing to our platform. I feel like I have rewritten image processing code (e.g. crop, filter, rotate, layers, etc.) more times than I can count. As a developer would you use such an API? URL: http://6px.io
4 comments
I just went over this with a colleague to deal with UGC upload.
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
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
There are definitely competitors in the space. Do you think there is room for another assuming that speed, flexibility and pricing are the differentiators? What could make it the best on your opinion?
Maybe. What's the benefit? Who specifically would benefit from using it? (don't say "everyone")
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.
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_userPrimarily developers who are building mobile and client side applications. My thought is to eliminate the need for those to build a backend server for image processing (e.g. ImageMagick) and make it available via an API. The latency is completely removed from the equation if developers pass images directly to 6px for processing.
There are many FOSS libraries for image resampling. Of those, many use iterative processing approaches which let you show the user a "viewable resolution" preview while continuing to generate the final-quality result in the background.
Even 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."
Even 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."
6px does handle large batch processing. The API accepts a JSON document (where a lot of the competitors on the market use the URL to define these things) that allows you to have multiple inputs and multiple outputs.
Does it just handle it, or do you push that value point by marketing that specific use case to customers who are currently having a hard time doing large batch processing with existing solutions?
If you don't market a feature, or if you're marketing it beside 100 other features, it doesn't exist.
If you don't market a feature, or if you're marketing it beside 100 other features, it doesn't exist.
There's also http://www.graphicsmagick.org/ ...
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.)
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.)
Makes sense. I think the real benefit here will be mobile developers and those who want strict client-side applications.
[deleted]
Isn't this effectively the Aviary SDK?
http://developers.aviary.com/
http://developers.aviary.com/
Aviary is a great product, but their primary service is different from what I'm building. They focus on client side applications similar to what Instagram provides (filters) in their mobile app. 6px is a solution for processing images -- one off or in batch. Think Instagam's backend processing infrastructure, available to all developers. If you have an image oriented application, you can offload the processing to 6px and don't have to worry about scaling as your application picks up traffic.