26 ms·

Is this really such a hard problem to solve? Something like littleutils can easily solve this, no? http://littleutils.sourceforge.net/ http://littleutils.sourc

by pavs 13y ago

Is this really such a hard problem to solve? Something like littleutils can easily solve this, no? http://littleutils.sourceforge.net/ http://littleutils.sourceforge.net/ Also what does this has to do with being "graphics card for the entire internet"?

qhoxie 13y ago
I don't think littleutils does much more than optimize images, which is pretty different from: http://www.imgix.com/docs/urlapi http://www.imgix.com/docs/urlapi Resizing or optimizing images, in isolation, is not a hard problem. I've solved subsets of this problem a handful of times before, and I could do it again, but I gladly pay for imgix. The time and headaches saved are easily worth it. The next time I have to rely on ImageMagick will be too soon.
jakejake 13y ago
I thought the same thing. I think this would be hard to do at scale and they offer quite a lot more features than most would need (sepia tone filter). I couldn't personally see paying for re service, but obviously it must be useful to others.
300bps 13y ago
>Is this really such a hard problem to solve? I must be misunderstanding because resizing an image, rotating it or many other basic operations consists of about 5 lines of .NET code and very little processing power. I imagine it's not any more difficult in other frameworks. I couldn't conceive of offloading that to an external service under just about any use case. It seems like they plan to offer video editing via SaaS as well which is more valuable, but I would think the transfer time and bandwidth would kill any speed improvement over a massively parallel SaaS video editor as opposed to using a local open source library.
- benjamincburns 13y ago
  > 5 lines of .NET code Yep. > very little processing power Not really. Those 5 lines are hiding a pretty big chunk of smarts. Simple scale/rotate transformations are an O(n) operation. That's not so bad. However image encoding/decoding is a bit more expensive. JPEG encoding, for instance, utilizes an O(n*log(n)) frequency analysis algorithm called a Discrete Cosine Transform. Good JPEG encoders will also do some expensive analysis to maximize precision while minimizing size during quantization (edit: though most just use a set of standard quantization matrices). And then there's I/O. It seems fast when you're only processing one image at a time, but to do this as a real-time service for a number of high-traffic websites is very nontrivial.
  - astrange 13y ago
    > JPEG encoding, for instance, utilizes an O(n*log(n)) frequency analysis algorithm called a Discrete Cosine Transform. Scuse me? JPEG's frequency transform is a set of fixed linear transforms and is always 8x8, so this step is just O(n) of the area of the image. Also, it's not really "a DCT", just any approximation that will look good when run through the approximation of the opposite transform at the other side. See http://multimedia.cx/eggs/dct-pr/ http://multimedia.cx/eggs/dct-pr/. The compression steps after are the most difficult, since they have poor ILP and can involve division. But JPEG is really simple, it's not a burden these days. One interesting part of it is minimizing the memory use of your application, by using the smallest possible ring buffer for pixels rather than keeping the whole image in memory at once.

by pavs 13y ago

qhoxie 13y ago

I don't think littleutils does much more than optimize images, which is pretty different from: http://www.imgix.com/docs/urlapi http://www.imgix.com/docs/urlapi Resizing or optimizing images, in isolation, is not a hard problem. I've solved subsets of this problem a handful of times before, and I could do it again, but I gladly pay for imgix. The time and headaches saved are easily worth it. The next time I have to rely on ImageMagick will be too soon.

jakejake 13y ago

I thought the same thing. I think this would be hard to do at scale and they offer quite a lot more features than most would need (sepia tone filter). I couldn't personally see paying for re service, but obviously it must be useful to others.

300bps 13y ago

>Is this really such a hard problem to solve? I must be misunderstanding because resizing an image, rotating it or many other basic operations consists of about 5 lines of .NET code and very little processing power. I imagine it's not any more difficult in other frameworks. I couldn't conceive of offloading that to an external service under just about any use case. It seems like they plan to offer video editing via SaaS as well which is more valuable, but I would think the transfer time and bandwidth would kill any speed improvement over a massively parallel SaaS video editor as opposed to using a local open source library.

benjamincburns 13y ago
> 5 lines of .NET code Yep. > very little processing power Not really. Those 5 lines are hiding a pretty big chunk of smarts. Simple scale/rotate transformations are an O(n) operation. That's not so bad. However image encoding/decoding is a bit more expensive. JPEG encoding, for instance, utilizes an O(n*log(n)) frequency analysis algorithm called a Discrete Cosine Transform. Good JPEG encoders will also do some expensive analysis to maximize precision while minimizing size during quantization (edit: though most just use a set of standard quantization matrices). And then there's I/O. It seems fast when you're only processing one image at a time, but to do this as a real-time service for a number of high-traffic websites is very nontrivial.
- astrange 13y ago
  > JPEG encoding, for instance, utilizes an O(n*log(n)) frequency analysis algorithm called a Discrete Cosine Transform. Scuse me? JPEG's frequency transform is a set of fixed linear transforms and is always 8x8, so this step is just O(n) of the area of the image. Also, it's not really "a DCT", just any approximation that will look good when run through the approximation of the opposite transform at the other side. See http://multimedia.cx/eggs/dct-pr/ http://multimedia.cx/eggs/dct-pr/. The compression steps after are the most difficult, since they have poor ILP and can involve division. But JPEG is really simple, it's not a burden these days. One interesting part of it is minimizing the memory use of your application, by using the smallest possible ring buffer for pixels rather than keeping the whole image in memory at once.