Hello HN! My name is Przemek Matylla and today I am launching Pixaven - modern GPU-powered image processing platform [1]. This product represents almost two years of work and countless hours spent in the datacenter.
Pixaven is an image processing API that runs entirely on Mac Pros (cylindrical, 2nd gen) that we host ourselves in a Tier-3 data center in Frankfurt, Germany. The goal was to build a service that would enable developers to process huge amounts of images at blazing speed with a simple to use API. Since pixels nowadays belong to graphic cards all heavy processing takes place on the GPUs [1].
We wrote our image rendering engine from scratch and can rapidly deploy custom solutions that revolve around pixel manipulation, computer vision and machine learning.
Pixaven API currently supports:
- Resizing and scaling (with multiple modes)
- Cropping (with multiple modes)
- Face detection
- Watermarking
- Masking
- Filtering (such as blurring, colour isolation, duotone, etc.)
- Manual adjustments (such as brightness, contrast, exposure, etc.)
- Automatic enhancements
- External storage to AWS, GCP, Azure, IBM, DO and Rackspace
While Pixaven works like a standard API and can push processed images to object storage of choice, we also offer Storage and Delivery addon and can distribute visual content over a global 65+ Tbps content delivery network.
Developers can integrate the API right away with production-ready integration libraries for Node, Go, PHP, Java, Ruby and Python.
We also implemented some additional features around the Pixaven Account such as 2FA and SSO, team management, access control and detailed activity logs.
We'd love to get some feedback and I'm here to answer any questions
Congrats on launching! The landing page is very impressive (only found a small typo on a testimonial: 'VP Enginnering at Clue')
Here's what I don't quite get: why does the GPU differentiation matter to me as a user of your API? I get that you're faster than doing it myself using something like ImageMagick, but are you faster than the other image processing APIs out there because of this? If so, that's what I think you should be touting. If not, whether the images are being processed by GPUs or trained giraffes is not that important to me as a consumer of the API, but I could be way off-base.
zellyn 1627 days ago [-]
Came here to say this. I would care if it's GPU-based if it were an open-source library. Not caring about how the other end of a paid API does their thing is the whole point of using a paid API.
matylla 1627 days ago [-]
Sure, you could use a solution that simply wraps ImageMagick with a Ruby API and call is a day. The whole point of having a GPU-powered platform is processing speed. On average, it takes us 60ms to perform any stack of image transforming operations. That also benefits our users (who likes slows APIs?).
With Metal Performance Shaders we have absolute control over pixels and direct access to the underlying hardware. For us that means we can rapidly test and deploy new CoreML models and also the ability to quickly respond to any feature-request.
kohanz 1627 days ago [-]
> On average, it takes us 60ms to perform any stack of image transforming operations. That also benefits our users (who likes slows APIs?).
So this was my point in bringing it up: "We're faster than the other APIs out there" is a much more direct benefit to communicate to me as an API user than "We use GPUs, which makes us fast, faster than the competition, who don't use GPUs". The latter version has me making assumptions and eventually getting to a conclusion that matters to me; why not take me there immediately?
The thing is, as a non-expert in this area, I don't even fully understand whether the real performance bottleneck in such an API is the latency of uploading the image and downloading the result, or the computational processing of the image. So if using GPUs cuts the overall request time by 70%, that's great! If it only affects the round-trip time by 5%, then it's not a huge deal to me. As the domain expert, I'm relying on Pixaven's marketing to educate me on this.
matylla 1627 days ago [-]
Now that is a perfectly valid point, thank you for this. I guess we have to simplify the contents of our marketing materials.
eigenvalue 1627 days ago [-]
This sentence "Pixaven API is up to 30x faster than ImageMagick and offers much more image operations than most command-line tools" should instead say "Pixaven API is up to 30x faster than ImageMagick and offers many more image operations than most command-line tools."
matylla 1627 days ago [-]
Fixed and deployed. Thanks for the heads up.
ethpete 1627 days ago [-]
Congrats on the launch! There's a small typo on the landing page where the stats are shown: "avgerage processing speed" -> "average processing speed"
matylla 1627 days ago [-]
Thanks for the heads up and all kind words! Correcting all typos now.
throwaway9298 1627 days ago [-]
You've still missed one :-)
s/Excercise/Exercise
Congrats on launching, great work!
ShamelessC 1627 days ago [-]
Why did you choose Mac Pros?
drcongo 1627 days ago [-]
I'm curious as to what the use cases are for services like this. When we build a site, we know what sizes our images are going to be needed at and we create those at the point of upload and stick them behind a CDN. What kind of sites would need this kind of on-the-fly processing?
chrisweekly 1627 days ago [-]
UCG (User-Generated Content).
Also, even for your embedded 1st-party images, even if you really know every variation you want to deliver (putting you in a small minority), and you already have an asset pipeline you're happy with (a smaller minority), there are still potential use cases (test automation, R&D, prototyping, DX shortcuts...) I can think of off the top of my head.
No affiliation (I haven't even tried Pixaven), just replying to your question per se. :)
Edit: also, some of the listed features (eg face detection and blurring) might not be part of your extant pipeline's capabilities.
matylla 1627 days ago [-]
Yes, exactly that.
Pixaven is a service meant (ideally) for businesses running at scale. If you're a large e-commerce platform with literally millions of new images (and their variants) created per day you would be looking for a solid platform to process this visual content for you.
tckr 1624 days ago [-]
1. I really love to have a dedicated image manipulation API which is not tied to a (headless) CMS.
2. I don't care about speed. Image manipulation can never be instant, and while the operation may be super fast on your end, the image data still needs to travel the wire, and be rendered on the UI. Your performance argument therefore is mute for me.
3. I do care a lot about having smart features like face detection, auto rotation, optimization (e.g. optipng), this should be on your start page.
tckr 1624 days ago [-]
4. I'm unable to find the address of your company on the homepage. This is a no go, especially when dealing with images which are potentially sensitive user content, I need to know exactly who is responsible for operating the service.
redm 1627 days ago [-]
It appears well done, congratulations on the launch. Are you targeting services like Cloudinary?
I'm curious, what's the connection between https://kraken.io/ and this; they seem to be connected, and similar?
I was also taken aback the 3.9bn images processed on your homepage. Then I looked at Kraken's, and its 3.5bn processed, but it launched in 2013? Is it the same image-processing engine, with GPU's?
w-m 1627 days ago [-]
How did you decide on using Mac Pros for batch GPU processing in a data center? After a little deliberation I could come up only with downsides of using these machines, which are quite expensive and have GPUs from 2013.
m0zg 1627 days ago [-]
For image processing them being from 2013 doesn't matter all that much: they're more than sufficient. As to why Mac, let me try to offer a guess: Apple ships Core Image, and they've sunk close to 2 decades of hard work into it by now. This is why there are two dozen "photoshop alternative" image editors on the Mac and a lot fewer (and poorer quality) on Windows.
So the benefit is, you can just use the API and get state of the art quality without spending three person-months tuning and debugging each and every op.
matylla 1627 days ago [-]
Core Image by itself is worth investing in a proper (Apple) hardware. Now that we can write custom Metal kernels and plug them straight into Core Image is even more beneficial. We can come up with any pixel modifications that will be executed within the GPU context. Precompiled kernels anyone? :)
The foundation of any image processing pipeline on MacOS/iOS is Image IO that offers crazy fast codecs for over a dozen different image formats. Even though I had to write extra integrations for WebP and animated GIFs it was really worth the effort. Native HEIC/HEIF support (reading and writing) is also neat.
Apple's CoreML is another piece of software I am using more and more at Pixaven. The ease of testing and deployment of new ML models is just amazing (and yes, I am learning a lot along the way).
m0zg 1627 days ago [-]
What baffles me is why doesn't NVIDIA offer a cross platform CoreImage counterpart. They do have nvjpeg for decoding, they have video codecs built in (so presumably HEIF should be doable also), but there isn't much available, as far as I can tell, if you want very high quality image manipulation with NVIDIA GPUs. I get that they're focused on 3D and deep learning now, but this is even useful for deep learning: I'd love to have hardware image decode and my entire image augmentation pipeline on the GPU and only do IO and perhaps some gnarly loss and metric computations on the CPU. Some of this is doable with NVIDIA DALI, but it doesn't seem to offer enough of a perf advantage to bother with it so far.
What would be great is if they offered similar capabilities to CoreImage (that is, quality-focused, flexible image processing) that I could use everywhere I can use CUDA.
matylla 1627 days ago [-]
I second that. High performance image processing with NVIDIA means writing low level CUDA, something I am not willing to invest my time in (at least for now). Translating all the code and custom kernels I wrote for Core Image would be quite a hassle to put it mildly.
chrischen 1627 days ago [-]
I believe one of the reasons imgix used macs as well was for Quartz and the macos apis.
matylla 1627 days ago [-]
This thread by imgix [1] perfectly explains the reasoning behind using Apple's hardware in a datacenter.
Browsing through this thread, the main argument seems to be that they are most comfortable with the Mac APIs and think it would be harder to rewrite their stack using different technology. They would have to re-apply the new stack onto millions of existing images and make sure the results 100% match the previous version, which is a problem that you don't have launching a new API.
So I'm not quite sure that I understand this reasoning in your case, as the operations performed (scaling, cropping, watermarking, flipping, filtering) are available in just about any image processing pipeline, and not really linked to anything that Quartz or Mac does particularly well.
gracki_placki 1627 days ago [-]
Congrats on the launch! I briefly skimmed through the docs and the product (at least from the outside) looks very polished. I'm curious if you guys are using any other hardware except of Macs?
matylla 1627 days ago [-]
Yes sure, we are also running an array of Supermicro machines for load-balancing, DBs and storage pods. It was a huge upfront investment but now we keep the costs of running Pixaven very low.
todsac 1627 days ago [-]
The two years of work is quite evident. Powerful product and beautiful site! I can't wait to test it out. Congrats on the launch.
Rendered at 22:02:06 GMT+0000 (Coordinated Universal Time) with Vercel.
Pixaven is an image processing API that runs entirely on Mac Pros (cylindrical, 2nd gen) that we host ourselves in a Tier-3 data center in Frankfurt, Germany. The goal was to build a service that would enable developers to process huge amounts of images at blazing speed with a simple to use API. Since pixels nowadays belong to graphic cards all heavy processing takes place on the GPUs [1].
We wrote our image rendering engine from scratch and can rapidly deploy custom solutions that revolve around pixel manipulation, computer vision and machine learning.
Pixaven API currently supports:
- Resizing and scaling (with multiple modes) - Cropping (with multiple modes) - Face detection - Watermarking - Masking - Filtering (such as blurring, colour isolation, duotone, etc.) - Manual adjustments (such as brightness, contrast, exposure, etc.) - Automatic enhancements - External storage to AWS, GCP, Azure, IBM, DO and Rackspace
While Pixaven works like a standard API and can push processed images to object storage of choice, we also offer Storage and Delivery addon and can distribute visual content over a global 65+ Tbps content delivery network.
Developers can integrate the API right away with production-ready integration libraries for Node, Go, PHP, Java, Ruby and Python.
We also implemented some additional features around the Pixaven Account such as 2FA and SSO, team management, access control and detailed activity logs.
We'd love to get some feedback and I'm here to answer any questions
[1]: https://www.pixaven.com/about
Here's what I don't quite get: why does the GPU differentiation matter to me as a user of your API? I get that you're faster than doing it myself using something like ImageMagick, but are you faster than the other image processing APIs out there because of this? If so, that's what I think you should be touting. If not, whether the images are being processed by GPUs or trained giraffes is not that important to me as a consumer of the API, but I could be way off-base.
With Metal Performance Shaders we have absolute control over pixels and direct access to the underlying hardware. For us that means we can rapidly test and deploy new CoreML models and also the ability to quickly respond to any feature-request.
So this was my point in bringing it up: "We're faster than the other APIs out there" is a much more direct benefit to communicate to me as an API user than "We use GPUs, which makes us fast, faster than the competition, who don't use GPUs". The latter version has me making assumptions and eventually getting to a conclusion that matters to me; why not take me there immediately?
The thing is, as a non-expert in this area, I don't even fully understand whether the real performance bottleneck in such an API is the latency of uploading the image and downloading the result, or the computational processing of the image. So if using GPUs cuts the overall request time by 70%, that's great! If it only affects the round-trip time by 5%, then it's not a huge deal to me. As the domain expert, I'm relying on Pixaven's marketing to educate me on this.
Congrats on launching, great work!
Also, even for your embedded 1st-party images, even if you really know every variation you want to deliver (putting you in a small minority), and you already have an asset pipeline you're happy with (a smaller minority), there are still potential use cases (test automation, R&D, prototyping, DX shortcuts...) I can think of off the top of my head.
No affiliation (I haven't even tried Pixaven), just replying to your question per se. :)
Edit: also, some of the listed features (eg face detection and blurring) might not be part of your extant pipeline's capabilities.
Pixaven is a service meant (ideally) for businesses running at scale. If you're a large e-commerce platform with literally millions of new images (and their variants) created per day you would be looking for a solid platform to process this visual content for you.
2. I don't care about speed. Image manipulation can never be instant, and while the operation may be super fast on your end, the image data still needs to travel the wire, and be rendered on the UI. Your performance argument therefore is mute for me.
3. I do care a lot about having smart features like face detection, auto rotation, optimization (e.g. optipng), this should be on your start page.
I'm curious, what's the connection between https://kraken.io/ and this; they seem to be connected, and similar?
I was also taken aback the 3.9bn images processed on your homepage. Then I looked at Kraken's, and its 3.5bn processed, but it launched in 2013? Is it the same image-processing engine, with GPU's?
So the benefit is, you can just use the API and get state of the art quality without spending three person-months tuning and debugging each and every op.
The foundation of any image processing pipeline on MacOS/iOS is Image IO that offers crazy fast codecs for over a dozen different image formats. Even though I had to write extra integrations for WebP and animated GIFs it was really worth the effort. Native HEIC/HEIF support (reading and writing) is also neat.
Apple's CoreML is another piece of software I am using more and more at Pixaven. The ease of testing and deployment of new ML models is just amazing (and yes, I am learning a lot along the way).
What would be great is if they offered similar capabilities to CoreImage (that is, quality-focused, flexible image processing) that I could use everywhere I can use CUDA.
[1]: https://news.ycombinator.com/item?id=9500301
So I'm not quite sure that I understand this reasoning in your case, as the operations performed (scaling, cropping, watermarking, flipping, filtering) are available in just about any image processing pipeline, and not really linked to anything that Quartz or Mac does particularly well.