Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Firesize – On-the-fly image resizing, no code required (firesize.com)
58 points by vanstee on March 21, 2015 | hide | past | favorite | 41 comments



Nginx can do this with the ngx_http_image_filter_module (included in stock distribution): https://neosmart.net/blog/2014/nginx-wordpress-images-with-n...


The image filter module is really neat, but for people reading it is limited to basic functionality like crop and resize. It supports PNG, GIF and JPEG, but PNGs are usually too large and GIFs are low quality, so you are stuck with JPEGs. Not sure if webp support is on the way or not.


That's really neat and I hadn't seen it before. Thanks for the pointer.


There's one serious problem with using 3rd party Imaging SDKs or utilities to build your service on: You're stuck with their flaws and you can't do much about it.

Disclaimer: I'm co-founder https://IMGX.io

We have written our own image processing SDK, using only encoders which are 3rd party (libpng, libjpeg, libwebp etc), rest is all handwritten, GPU optimized code. The rationale behind it was to be able to tweak/optimize any feature.


Looks great. I see mention of limits, but there is no pricing page. It's hard to adopt a service if I have no idea what it will cost me.

I have used Embed.ly's similar service in the past. There is a sizable free tier (25,000 images) and it works more or less the same. http://embed.ly/display


If you join during the beta, we'll grandfather you in to the free plan (no-limits). I should make that more clear on the homepage though. Thanks.


Awesome! One line about that should do the trick.

Is the only way to "join" via Heroku? Or is there another place I can create an account?


Yep, but only for the MVP. Adding our own signup form is something we're working on.

Send me an email at firesize@helpful.io and I can manually hook you up with an account though.


This was built by our awesome community on Assembly. If you have any feedback or want to get involved and help us continue to build this, check out the project on Assembly: https://assembly.com/firesize


Bit off-topic, but... it feels like there's a trend towards "x as a service" away from "x as open-source software". Is that something other people are seeing, or is it just my imagination?


There's an in-between trend of "X as open-source software but we can host it for you as a service". It seems like a pretty promising way for open source projects to still make money. I think if an open source project can figure out how function as a business, that's a sign it will stick around.


This is actually also an OS project it appears: https://github.com/asm-products/firesize


Firesize uses ImageMagick, which in my experience consumes more memory and is slower than libvips [1] for simple image resizing/optimization.

I built a simple image-resizing server with a query string API using libvips [2]. This is based on sharp [3], a good wrapper of libvips for Node.js.

[1] https://github.com/jcupitt/libvips

[2] https://github.com/nthtran/imgop

[3] https://github.com/lovell/sharp


We wrote the complete image processing oursleves, accelerated on GPUs @ https://IMGX.io (checkout Image URL API).


Definitely seeing it. But if you want open source, check out imagesquish https://github.com/dmcquay/imagesquish


Do you have a utility that lets me port over my named transformations from Cloudinary? Also, is there any way to pull images directly from an S3 bucket rather than from my Heroku instance?


Oh nope, but that would be pretty sweet. I'll throw that in the queue of things to build next.

We just grab whatever image you include in the url, so as long as the images in your S3 bucket are public, Firesize should be able to resize them just like normal.


I like your pricing model much more--I don't like how Cloudinary charges me for storage, because I don't want them to store the images, just transform them.

What I would need to move over to yours are the following features: * Reorienting the picture based on exif data * Picture gravity via face detection * Way to ensure no one else maliciously uses my account (e.g., domain whitelisting/CORS, only pulling from my S3 bucket, something like that) * Renaming the output file image on the fly

Obviously, I'm only one customer, so don't do anything based on just me! But if it's at all helpful, these are one potential user's needs :)


One small issue is that it doesn't correct for gamma. Most browsers don't even do it properly, so it isn't a very important issue at all.

Demo: http://firesize.com/100x100/g_center/http://www.4p8.com/eric...

More info: http://www.4p8.com/eric.brasseur/gamma.html


Is there anything yet to prevent abuse? For example, in the case of Cloudinary, they allow signing of URLs[0] to prevent anyone from just using your account to serve arbitrary images.

[0] http://cloudinary.com/blog/on_the_fly_image_manipulations_se...


Yep, we're actively building both url whitelists per Firesize account and url signing.


>You're images will be quickly delivered to your users

A typo. "You're" should be "Your".


Ah! Thanks iokanuon. If you add a bounty on Assembly, I'll award you some ownership for pointing this out: https://assembly.com/firesize/bounties


Great :), first impressions:

I've seen a few of these before and the things I remember I liked about them was the ability to provide a default image incase you cannot load the image.

Major kudos if you could do a g_face so you could center / crop around faces!

You say you provide a CDN and yet the images are loading slow under HackerNews weight. I guess the type of people who are going to use these aren't super concerned about being hammered!

Lastly the Heroku add-on, does that mean I can run your code on my Heroku instance instead of rely on your site? That would be fantastic!


Oh yeah a default would be nice. Good idea.

The image on the homepage isn't behind a CDN, but when you signup we give you a custom subdomain which is behind a CDN. Although the initial loading and resizing still takes a quick second, before we cache it.

Not exactly. The Heroku addon just means you can easily signup and manage Firesize from the Heroku dashboard. Although the code is AGPL'd so you could totally run your own hosted version of Firesize: https://github.com/asm-products/firesize


Quick bug report, g_none seems to not be working, instead it's just doing the same thing as g_north

http://firesize.com/720x100/g_none/http://i.imgur.com/hHpJsc...

http://firesize.com/720x100/g_north/http://i.imgur.com/hHpJs...


"This app is in region eu, firesize is only available in region us." Thats a shame. But is guess getting manually hooked up would work for this case too?


Oh yeah shoot me an email (firesize@helpful.io). We're working on making it available in other regions as well. Sorry about that.


I built a JavaScript library which automatically applies this optimization to all the images on any site it's placed on (using a MutationObserver): https://github.com/EagerApps/FireSize


Very similar to Cloudinary, though they have more advanced features as well. worth checking out IMO.


Free during beta, but how much will it cost after? Are you going to limit access through the Referrer header? Why do I need a Heroku addon if I can just use a Firesize URL from anywhere automatically? How much does it cost to run a massive service like that?


Hi,

I just recommended you to someone on weekendhacker chat earlier today. Glad to see another assembly launch.


I have an old project that does a similar thing: https://github.com/kristopolous/apophnia ... enjoy


what different things do you offer than cloudimage? http://cloudimage.io/


We are using thumbor self hosted to solve a similar problem. It evens smart crop with opencv features detection, like people faces.


g_center, assuming there are more options, could very well be a select option with the other available options. :)


Is this really a problem painful enough that you need a SaaS?


Depending on what you are building, yes. This can save a developer a good portion of a day between the code, file storage and CDN.


Yep that's exactly why we built it. To be honest it's not overly complex to build yourself, but taking the time to get it right, setting up the CDN, and maintaining background workers can be pretty expensive when you factor in developer hours.


Just so you know, Web of Trust gives firesize.com a "Very Poor" Trustworthiness and Child Safety rating. https://www.mywot.com/en/scorecard/firesize.com?utm_source=a...


Based on one comment in 2009, surely WOT needs a better algorithm for refreshing these ratings as time passes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: