libvips has two new-from-ram calls:

VipsImage *vips_image_new_from_memory(const void *data, size_t size, 
    int width, int height, int bands, VipsBandFormat format);

You give that a pointer to a C array of pixels (for example, 9 bytes, RGBRGBRGB, could be a 3x1 or 1x3 pixel RGB uint8 image). The width height etc. parameters give the basic layout of the pixel geometry. This just wraps the vips image struct around the pointer, there's no copying, so you need to be careful.

There's also:

VipsImage *vips_image_new_from_buffer(const void *buf, size_t len,
    const char *option_string, ...);

For this one, the memory contains the bytes of an image encoded in some format, like JPEG. You don't give any geometry params, they are encoded in the image header. The actual loader that libvips selects is picked by a sniffer.

Sorry, I keep adding stuff. There's new_from_source as well, of course. That's rather like new_from_buffer, but will attempt to decode progressively as bytes arrive, rather than loading the entire thing into RAM.

Most of the loaders work internally in terms of VipsSource objects and the older buffer load interface is just a thin wrapper over that.

Appreciate the help!

So right now, VImage.newFromBytes (the vips-ffm function) is failing for them. The chain there is:

• vips_blob_new to wrap the Java bytes
• vips_source_new_from_blob to wrap the blob
• Then loading the image like usual:
  • vips_foreign_find_load_source
  • Invoking the load like usual through the operations API

And the result of that, right now, is "VipsForeignLoad: source is not in a known format".

That makes me think that the new_from_memory or new_from_buffer functions are likely to fail when there are any image operations, even if they notionally accept the bytes?

libvips does it like this:

https://github.com/libvips/libvips/blob/master/libvips/iofuncs/image.c#L2200-L2267

So it tries as a source, then via a filename, then via a buffer. This mess is to handle loaders which haven't yet been redone for the newer source load system, or loaders which just can't handle generic data sources (eg. openslide, libraw, imagemagick, etc.).

I think this user might be happiest with an equivalent of new_from_memory_copy(), which would need new vips-ffm API, maybe:

VImage newFromMemory(Arena arena, byte[] bytes, 
    int width, int height, int bands, VipsBandFormat format);

That helps a lot, and it seems like a useful feature - I'll take a look