Erlang or Elixir wrappers for libvips

I need a wrapper for LibVips. I have found 2 ones

Those are unpopular - 11 and 14 downloads.

Are there other ones, in Erlang or Elixir, that are used by most people and are recommended?

Of the two you found, none are a lipvips wrapper. https://hex.pm/packages/vips 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.

2 Likes

Just recently met someone who was messing around with this in their spare time https://github.com/christianjgreen/elixir-libvips.

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

1 Like

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!

1 Like

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.

2 Likes

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

1 Like

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.

2 Likes

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 … :slight_smile:

1 Like

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 https://github.com/libvips/ruby-vips 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!

2 Likes

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

2 Likes

Hey guys,

I was working with image uploads for the last couple of days, some resizing and thumbnail generation. Imagemagick with mogrify worked well but that was kinda slow so I was looking for a way to switch to libvips. Unfortunately, there are still only a few libvips packages and most of them haven’t been updated in years.

However, there is elxvips | Hex , it uses NIFs, I tried it on my testing machine and so far, it works well, image transformations are 3-4x faster compared to imagemagick. Does anyone have any experience with it in production?

Hi @KiKi,

Have you tried vix? (disclaimer: I’m the author)

vix tries to be complete binding for vips, supporting almost all operations and options. If your use case has complex image manipulation pipelines then you can do that efficiently with vix. afaik other libraries does not support all operations or pipelines. You can think of vix as an elixir binding library, which aims to be something like ruby-vips.

5 Likes

I was thinking of diving back into libvips this weekend and then found your post just now. This looks great work, thanks very much for your efforts (and very nicely crafted too).

1 Like

@akash-akya Wonderful work. You know the best part of the library? The two LiveBooks. I think we are in for some revolution in terms of documentation for elixir libraries.
Thanks for the good work.

1 Like