

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

I&#x27;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:&#x2F;&#x2F;6px.io
======
joshwa
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/](http://blitline.com/)

Chute [http://www.getchute.com/](http://www.getchute.com/)

Cloudinary [http://cloudinary.com/](http://cloudinary.com/)

imgix [http://www.imgix.com/](http://www.imgix.com/)

transloadit [http://transloadit.com](http://transloadit.com)

~~~
nparsons08
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?

------
glimcat
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

~~~
nparsons08
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.

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

~~~
dustinwtf
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.

~~~
glimcat
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.

------
minimaxir
Isn't this effectively the Aviary SDK?

[http://developers.aviary.com/](http://developers.aviary.com/)

~~~
nparsons08
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.

