I'm impressed at the features and simplicity, but I'm wondering what the real use cases are. If filters were a core part of my business, I'd certainly be doing them in-house instead of relying on a 3rd party service... Especially when it comes to the basic operations (crop, resize, etc) which can simply be done with imagemagick (or rmagick). Even Heroku allows for those operations on temporary files, despite the read-only filesystem.
That said, the "real-time" feature seems like it could make certain use cases much easier. (An alternative to firing up workers and returning an intermediary status to the client.) Also, I suppose apps without much server infrastructure (built on more limited PaaS offerings) could benefit from this API.
I think the service looks quite neat, and the effects well done. However, wouldn't it make sense to apply filters client-side in most cases? (I'm personally always a fan of using their computing power not mine if it can be worked that way!) Plus, the time to upload and retrieve each image seems like it would be relatively high. Finally, the pricing seems rather expensive.
Still, it's a neat idea. I'm just wondering if it will make sense to use this service in many real applications. Anyone have an example usage scenario?
Perhaps the computation becomes cheaper roundtrip past a certain file size as opposed to fully on the client (only speculating). It could be an interesting strategy for filtering full-resolution images when you have 8MP at a time.
This sounds like a really neat service. Just about a year ago a friend and I wanted to do a filtering app for our own use, but didn't seem to find any straight-forward resources to apply filters w/out doing too much development on our own. This is awesome; we may actually considering doing the old app again, thanks to these guys.
Thought One: Your biggest barrier to adoption will be speed as you scale. If your API returns the modified image too slow, developers will quickly abandon you. So you'll need to invest heavily in RAM, processing power, and code/db optimization.
Thought Two: I suggest, if you have the storage to support it, that you take a checksum of all original images and cache the original and modified versions of them. As you scale you will find lots of people submitting the same images (celebrity pics, scenery, etc) and you could save alot of time and bandwidth by doing a checksum client-side, AJAXing it back to your server and, if there is a match, just return your cached version (if the client requests the same filter) or processing the cached version. In either case you eliminate the need for the upload, and you speed up processing server-side.
What I meant was to have two galleries on IMGUR, ORIGINGAL and FILTERED.
The API should be used for applying the filters, but why build all the image hosting and gallery capabilities when IMGUR has solved that problem. Use IMGURs API to push the originals and filtered versions to the right spot.
Pay the $30 for the annual sub and you can have unlimited photos in your account.
I see. I still don't quite get how that addresses zupreme's idea, which had nothing to do with displaying galleries. He was suggesting that instafilter implement a potential performance optimization by caching images as they come in, so the same operations (to the same images) could be more quickly returned from any subsequent calls to the API.
In terms of leveraging IMGUR for hosting and gallery capabilities, yes that would work if all you need is a place to dump original and filtered photos. But my impression was that this API would be used by apps that integrate images into their existing service (whatever it might be). Imagine taking a picture in Instagram, choosing a filter, and being redirected to an IMGUR gallery with the result...
It would make the most sense to store nothing. As far as I can tell, it doesn't return a link to the filtered image or anything, just the binary. RAM would be the limiting factor here I think. The images would need to be decompressed to filter them (unless they're doing something very fancy).
Edit: welp, I totally didn't read the OP of this thread. Still, I think the storage costs outweigh the cost of just applying the filter each time. Also, people like to filter their own images. Nobody I know of shoves existing pictures into Instagram.
If these kind of nonsense filters really are in demand, doing them in a cloud environment for photographs is insane. Javascript makes much more sense. For video, I could understand the need for server side processing power, but uploading an image, operating on it and then returning the image is crazy.
However, I am against the whole filter nonsense in the first place. A photograph should should stand on its photographic merit, and not by its medium (filters simulate different mediums, old film, b&w, polaroid etc)
They aren't all toy filters. Levels, contrast, resize, crop, even black and white are all totally reasonable post-processing while maintaining photographic merit IMO. Of course, if you run crappy photographs through filters, your output will still be crappy photographs.
I think when you refer to "medium" you mean style. Here photography is the medium to deliver a message. I think we can agree that not every message is best presented in the same style. Would you present a photo of a party in the same way you present a photo of a war zone? Different photos need different styles of presentation. There is skill not just to picking the style, and adjusting the style to suit the photo. So it's fair to say that a photograph needs a certain visual style to stand out, and photo filters can strengthen a photograph by enhancing aspects of that photo that adhere to the desired style.
No, not style, I meant medium. These filters are emulating, as do instagrams, different photographic mediums, like color film, b&w film, instant film, etc.
Photo filters do not strengthen a photograph, they detract at best. A good photograph of a party, or a good photograph of a war zone are still good photographs. People don't go to a war zone and pick a filter to emphasize the horror. Understanding what makes a photograph work is a complex interaction between the image and the person looking at it. My point is that you can take a boring photo and add novelty by adding a filter, but that's a cheap sham, it's not a better photograph. Making a photograph b&w for example doesn't bestow it with artistic merit.
As an example, go look up someone like Bruce Davidson, and see try these filters out on any of his photographs, after a few attempts you will start to see that the images worked before you added any fluff.
Style isn't about filters, or about HDR or any of that nonsense, it's about visual intellect, about making a photograph by assembling components in a visual dialog with the viewer.
seriously, i can't believe this thing got upvoted. how do they expect to compete with imagemagick, batch mode gimp, and the like? or even client-side JS libraries like pixastic?
Looks very cool! I would also like to point out Cloudinary as a great service that features image hosting & upload in addition to filters. I think Instafilter.io could maybe get a leg up though if they offer and publicize a growing collection of available filters (perhaps a user-generated "filter store" of sorts).
29 comments
[ 2.8 ms ] story [ 66.4 ms ] threadThat said, the "real-time" feature seems like it could make certain use cases much easier. (An alternative to firing up workers and returning an intermediary status to the client.) Also, I suppose apps without much server infrastructure (built on more limited PaaS offerings) could benefit from this API.
Still, it's a neat idea. I'm just wondering if it will make sense to use this service in many real applications. Anyone have an example usage scenario?
If there is a js lib that makes use of canvas then I am ready to buy a license.
Also do you provide advice on creating custom filters?
also, i really don't understand how they expect to compete with said libraries
The complete list was:
Hangover: Everything's too bright! Where did all the colors go? Argh, my head.
Drugstore: Perhaps you shouldn't have gone for the cheapest possible photo printing
Truffaut: You've always dreamed of appearing in a European art house movie
Blemish: For when only black and white can rescue your picture
Madison: You like to think you're Don Draper, but you're actually Pete Campbell
Jaundice: The relaxing yellow hue that accompanies a severe liver problem
Blue Rinse: You tried to wash your socks and your white shirts together, didn't you?
Cataract: This is how Grandma sees you
Doves Cry: A Prince-ly purple vibe
Williamsburg: Don’t you wish you’d lived there before it was cool to live there?
Thought One: Your biggest barrier to adoption will be speed as you scale. If your API returns the modified image too slow, developers will quickly abandon you. So you'll need to invest heavily in RAM, processing power, and code/db optimization.
Thought Two: I suggest, if you have the storage to support it, that you take a checksum of all original images and cache the original and modified versions of them. As you scale you will find lots of people submitting the same images (celebrity pics, scenery, etc) and you could save alot of time and bandwidth by doing a checksum client-side, AJAXing it back to your server and, if there is a match, just return your cached version (if the client requests the same filter) or processing the cached version. In either case you eliminate the need for the upload, and you speed up processing server-side.
Just my 2 cents.
The API should apply the filters, but let IMGUR do all the storage and gallery-ing.
Wouldn't it make more sense to just use something like S3 to store raw files?
What I meant was to have two galleries on IMGUR, ORIGINGAL and FILTERED.
The API should be used for applying the filters, but why build all the image hosting and gallery capabilities when IMGUR has solved that problem. Use IMGURs API to push the originals and filtered versions to the right spot.
Pay the $30 for the annual sub and you can have unlimited photos in your account.
In terms of leveraging IMGUR for hosting and gallery capabilities, yes that would work if all you need is a place to dump original and filtered photos. But my impression was that this API would be used by apps that integrate images into their existing service (whatever it might be). Imagine taking a picture in Instagram, choosing a filter, and being redirected to an IMGUR gallery with the result...
Edit: welp, I totally didn't read the OP of this thread. Still, I think the storage costs outweigh the cost of just applying the filter each time. Also, people like to filter their own images. Nobody I know of shoves existing pictures into Instagram.
However, I am against the whole filter nonsense in the first place. A photograph should should stand on its photographic merit, and not by its medium (filters simulate different mediums, old film, b&w, polaroid etc)
Photo filters do not strengthen a photograph, they detract at best. A good photograph of a party, or a good photograph of a war zone are still good photographs. People don't go to a war zone and pick a filter to emphasize the horror. Understanding what makes a photograph work is a complex interaction between the image and the person looking at it. My point is that you can take a boring photo and add novelty by adding a filter, but that's a cheap sham, it's not a better photograph. Making a photograph b&w for example doesn't bestow it with artistic merit.
As an example, go look up someone like Bruce Davidson, and see try these filters out on any of his photographs, after a few attempts you will start to see that the images worked before you added any fluff.
Style isn't about filters, or about HDR or any of that nonsense, it's about visual intellect, about making a photograph by assembling components in a visual dialog with the viewer.
Dave