Operation.thumbnail/3 returns a result that can't be enumerated twice

[kipcole9]

In reference to this issue on Image.

After calling Vix.Vips.Operation.thumbnail/3 on any path name, the result image cannot be written to a binary more than once. The error has similar symptoms to those expected when opening an image with access: :sequential however there is no developer-visible :access option in this case.

Steps to reproduce

iex> pipeline = Vix.Vips.Operation.thumbnail! "path/to/some/image.png", 90
%Vix.Vips.Image{ref: #Reference<0.4289772953.849477660.199092>}
iex> i1 = Vix.Vips.Image.write_to_binary(pipeline)
{:ok,
<<24, 188, 242, 255, 24, 188, 242, 255, 24, 188, 242, 255, 24, 188, 242, 255,
24, 188, 242, 255, 24, 188, 242, 255, 24, 188, 242, 255, 24, 188, 242, 255,
24, 188, 242, 255, 24, 188, 242, 255, 24, 188, 242, 255, 24, 188, 242, 255,
...>>}
iex> i2 = Vix.Vips.Image.write_to_binary(pipeline)
{:error, "Failed to write extracted region to memory"}

Expected result

The image resulting from Operation.thumbnail/2 should be able to be enumerated more than once. Or an :access parameter should be available.

[akash-akya]

Raised the issue in libvips -- libvips/libvips#4341

[akash-akya]

@kipcole9 based on the answer here libvips/libvips#4342, I am not sure what we can do here apart from adding warnings in the documentation. You have suggestions?

[bbangert]

It's odd that thumbnail pipeline can be re-run with a SVG, I guess that's just a fluke though since the libvips answer indicates they never expect it to be re-run successfully?

Given that, I think having a warning is reasonable. I was also wondering whether maybe the thumbnail operation could special-case a path being passed directly in and return a function instead of a VIPS image, so that it could be re-run with a call.

[akash-akya]

I can imagine it working for SVG, streaming does not makes sense for SVG and likely it will be loading the while image to the memory so it happens to work.

maybe the thumbnail operation could special-case a path being passed directly in and return a function instead of a VIPS image

Agree, that makes sense.
Have variants of thumbnail. If we are returning VIPS image then make sure it behaves as other operations (even if it is bit slow). And have variants which writes directly to buffer/file using the optimized path. Document the difference.

[jcupitt]

Could you add some equivalent of copy-to-memory? People can run that on the output of thumbnail if they need to scan the image more than once.

libvips has the various caching functions (cache, tilecache, linecache), you can also run one of those on the output of thumbnail to allow different types of double scanning.

[akash-akya]

It is already present but undocumented (I added it for supporting mutable image).
I was reluctant to expose functions that opens lot of details, but I guess it is simpler to expose for now. Will do that.
Thanks.