Of the two you found, none are a lipvips wrapper. vips | Hex wraps the command line version. The other is not libvips related. Like you, I’d like to see a NIF-based libvips wrapper but my NIF-fu is weak.

Just recently met someone who was messing around with this in their spare time GitHub - christianjgreen/elixir-libvips: Experimental bindings for libvips · GitHub.

It may at minimum be informative as to how to do what you need if what you need isn’t too broad.

Hey @foggy! Hope you’re doing well dude.

That library is something that I was working on for fun, but as it started to reach a decently stable-ish point. The blocker for me moving forward was ensuring safety for the user as scaling LibVips in a massively concurrent manner can lead to crashes that trickle up to the BEAM.

I’d love to help if you have any questions!

So I started to dig into the native code to see what I was doing wrong, because when it comes to concurrency, it’s usually my fault. In this case the issue was garbage collections was done globally and not on a per BEAM thread basis. I think I might pick this project back up if there’s any interest in it.

Yes, please do! If you get the bones of it right for dirty scheduling and concurrency I’ll happily contribute!

I particularly hopeful that from an API perspective I can pass a pipeline of operations and desirably work on an in-memory version of the image (and of course read and write).

By a “pipeline” do you mean something like the lines of:

"some_file.png"
|> File.open!()
|> Libvips.new()
|> Libvips.smartcrop()
|> Libvips.to_buffer()

Libvips operations in this instance would pass a “ref” back and forth to avoid unnecessarily crossing the NIF bridge with the image data.

Spot on, and sorry for not being clearer. Be able to send multiple transformations to the NIF for execution without passing back and forth - or as you say, keep a ref so that the image isn’t being copied all the time.

This is a topic long on my list since photography is a passion and rebuilding my portfolio site is something I want to do from the ground up. Including the image processing layer (because I want to). I just haven’t done any C programming since Kernighan and Ritchie first came out. So I’m a little out of date …

Hi guys,

A little late to the game here but I’d also love to see some work done around vips in support of Elixir after having used it with Rails projects at the last company I was with.

I had enjoyed its performance and ease of use over imagemagick and rmagick along when using the GitHub - libvips/ruby-vips: Ruby extension for the libvips image processing library. · GitHub project. It would be great to offer this to the community and I’m willing to help out in any way I can (testing, documentation, picking up C along the way and so on).

And pipelining would be awesome to have as Kip has confirmed would be awesome (at least to get to with future versions).

@christianjgreen / @kip

Cheers guys!

Hello everyone! I’ve been quite busy with trying to drink that stupid water stuff, but I’ve been able to put a little bit of thought into this and hope to explain why the final NIF project was never released.

As we all know NIFs have their niche case, but something as high-level as libvips should probably be handled through a port. I severely underestimated the bandwidth of ports and made the insecure trade-off to NIFs in order to focus on performance. I had a nice chat with some folks from AtomVM (specifically @cdegroot) and got some insight on the true performance ports can provide. The port solution, in my opinion, decouples the image manipulation interface and provide a “safer” environment for the BEAM.

I would love some feedback from the community about this! I know some folks already “sandbox” their NIF nodes and/or don’t care about the potential crashes due to their infrastructure, so the final question is - Which interface will rule them all? Maybe a libvips API that can be accessed through both NIFs and ports?

<3