2 ms·

> Racking servers, even if they're cylindrical, is actually much easier than building an entire real-time image rendering pipeline from scratch. I think this i

> Racking servers, even if they're cylindrical, is actually much easier than building an entire real-time image rendering pipeline from scratch. I think this is still a penny wise, pound foolish decision. I am sure it is less work to figure out how to buy and rack some trashcans, vs writing an entire image pipeline for 1.0. I get that. I also don't know your full specs. There are tons of FOSS image libraries out there. What % of your workflow do they cover? Are you sure you are estimating taking something like Pillow and adding in missing pieces, vs writing an entire image library from scratch? Things like basic filters and image resizes are a solved linux problem for a long long time. Hardware lock-in always has a price. People that build on AWS exclusive things like lambda do the same thing, to a smaller scale. It seems like you are paying this lock-in price, and will continue to pay it. Perhaps it is the right decision, perhaps not. But I cannot image locking my entire company into the whims of a consumer trendy product line, when there is no fundamental need. I would look really hard at hiring some devs to build out a proper rendering engine...

skuhn 10y ago
Without getting too into the weeds -- we do use OSS and third-party libraries where it makes sense. Our rendering pipeline incorporates things like mozjpeg, Intel IPP, jxrlib and other technologies. We're doing the integration and augmentation work to make this all play nicely together with the right quality and performance. However, there is no off-the-shelf solution that solves the same core problem as the imgix pipeline. Resizing or format conversion, sure. That plus the types of graphical operations that Photoshop supports? Less common. Now do all of that in one pass in 30-50ms, streaming to/from the GPU, with the ability to easily add new workflows and operations? It's our core business, and we own that workflow completely inside of our stack. We built on the foundation of CoreImage and that gave us a leg up -- we can take most of what we've built, replace the foundation and keep going on another platform (such as Linux). The main challenge is that there is no equivalent technology to CoreImage on any other platform. PIL (or Pillow) are adjacent technologies, but I can tell you from experience trying to operate a PIL-backed image thumbnailing service at scale it is not a large scale solution. Better than ImageMagick for sure, but it still has limitations. Even something like RenderMan is not tuned for this kind of workflow -- it's awesome at what it does, but latency and scale are not its central concerns. There are risks to imgix's business, and this is one of them, but I'll be pretty surprised if it sinks us. We have some pretty sharp cookies working on our rendering platform, and while success on that front isn't guaranteed it's entirely within the realm of possibility.

skuhn 10y ago

Without getting too into the weeds -- we do use OSS and third-party libraries where it makes sense. Our rendering pipeline incorporates things like mozjpeg, Intel IPP, jxrlib and other technologies. We're doing the integration and augmentation work to make this all play nicely together with the right quality and performance. However, there is no off-the-shelf solution that solves the same core problem as the imgix pipeline. Resizing or format conversion, sure. That plus the types of graphical operations that Photoshop supports? Less common. Now do all of that in one pass in 30-50ms, streaming to/from the GPU, with the ability to easily add new workflows and operations? It's our core business, and we own that workflow completely inside of our stack. We built on the foundation of CoreImage and that gave us a leg up -- we can take most of what we've built, replace the foundation and keep going on another platform (such as Linux). The main challenge is that there is no equivalent technology to CoreImage on any other platform. PIL (or Pillow) are adjacent technologies, but I can tell you from experience trying to operate a PIL-backed image thumbnailing service at scale it is not a large scale solution. Better than ImageMagick for sure, but it still has limitations. Even something like RenderMan is not tuned for this kind of workflow -- it's awesome at what it does, but latency and scale are not its central concerns. There are risks to imgix's business, and this is one of them, but I'll be pretty surprised if it sinks us. We have some pretty sharp cookies working on our rendering platform, and while success on that front isn't guaranteed it's entirely within the realm of possibility.