h2non
commented
7 years ago I perfectly understand the rationale shared here, but bimg, and subsequently, imaginary, were always designed to operate at higher level and provide simple API abstractions for common, non-complex, image processing, instead of being a libvips API for Go.
For that purpose, I would suggest you taking a look at this package, which aims to provide Go bindings for libvips:
https://github.com/davidbyttow/govips
That being said, I don't discard evolving the programmatic API in order to provide more versatility, but always without breaking bimg original goal.
umesecke
I recently started playing around with vips using this package and the initial results are quite impressive when compared to imagemagick. But with more advanced tests the current API quickly becomes a limiting factor.
So I'd like to start a discussion about adding some kind of low level API that allows working with vips more directly. The reason for this is that the current API works for one-shot operations like "take this file, do some processing and save the result" which makes sense for a REST service like imaginary.
My use-case requires creating multiple thumbnails of a given image in different sizes. Using imagemagick I load the original file, do some processing like striping some metadata (not all), transform icc profile or adding watermark images and based on this intermediate image I finally create about 10 thumbnails.
With the current API I'd have to repeat the initial processing for each thumbnail which I'd like to avoid. And instead of extending the Options struct further for every use-case I think a low level API for more advanced operations would be nice.