Ask HN: Would you use an API for image processing?

https://news.ycombinator.com/item?id=7155381

by nparsons08 • 12 years ago

9 11 12 years ago

news.ycombinator.com

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

glimcat3• 12 years ago

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.

    end_user->your_user->end_user
    end_user->your_user->you->your_user->end_user

dustinwtf2• 12 years ago

Makes sense. I think the real benefit here will be mobile developers and those who want strict client-side applications.

nparsons083• 12 years ago

Primarily 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.

glimcat3• 12 years ago

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."

Xenmen• 12 years ago

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.)

minimaxir• 12 years ago

Isn't this effectively the Aviary SDK?

http://developers.aviary.com/

nparsons083• 12 years ago

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.

joshwa• 12 years ago

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

nparsons083• 12 years ago

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?

Ask HN: Would you use an API for image processing?

Related Stories