Support advanced file write options of Vix

[dersmon]

Hey!

This may be a feature request for Image or just something for the documentation, as I am not 100% sure where you delineate between Image and Vix.

I work quite a bit with IIIF servers for high resolution images, that is why I have been looking into how to save pyramid images (for example JPEG 2000 or tif) natively in Elixir (instead of running System.shell/1 with an ImageMagick command).

As far as I can discern this seems to work for my purposes:

"high_res_raw.tif"
|> File.read!()
|> Image.from_binary!()
|> Vix.Vips.Operation.tiffsave("test.ptif", pyramid: true)

If you would consider this the way to do it, I could add a small addendum to Image.write/3 or anywhere else you deem appropriate. Or did I miss some potential pitfall/issues?

Thank you for your work on Image so far.

Cheers

[kipcole9]

Thanks for the suggestion. I've added support for the :pyramid option for TFF files in the main branch. Would you consider giving that a spin before I publish? I've not added any tests yet so I need to do that too if you see acceptable results.

BTW, since libvips implements a streaming image pipeline it is much more performance and memory efficient if you let it do the heavy lifting. There are very few cases where Image.from_binary/1 is the best option - that's very memory intensive and you say you are working with large images.

I would suggest:

"high_res_raw.tif"
|> Image.open(access: :sequential)
|> Image.write("test.tif", pyramid: true)

The access: :sequential option adds some further optimisations if the image pipeline you need only ever needs to process the image in the forward direction. Use access: :random (which is the default) if not.

I have not added .ptiff as an auto-detected TIFF variant since that doesn't seem strictly necessary. But I'm open that discussion.

Let me know?

[dersmon]

Nice! Works like a charm.

Concerning the .ptiff or .ptif suffix I have no strong feelings.
In my case I am replacing a legacy system where they used that suffix, but not sure how common it is. Maybe instead (not knowing how complex that would be) you could introduce an option that explicitly sets the format, ignoring the suffix given by the file name? That way you could focus on the "main" suffixes for the auto-detect feature while providing a escape hatch for anybody who wants to do weird stuff.

Not sure why I chose the File.read/1 and Image.from_binary/1 combo in the example above, in the application I used your open. Thanks for clarifying in the docs.

[kipcole9]

I'll experiment with a :type option to Image.write/3 to specify the image type. My concern is to not create ambiguity when creating the file. For example, if the call was Image.write(image, "test.jpg", type: :tiff), is it ok to house a tiff file in a file with a .jpg suffix?

Any thoughts on handling that?

[dersmon]

I think the question of it being ok is on the individual's conscience. It certainly looks kinda silly. ;)

Maybe calling it something like :type_override or :autodetect_override could help to make it more explicit that the option takes precedence and can produce these kind of discrepancies if you do not properly create or check your paths. But on the other hand, with the proper documentation this might also be overkill and sticking to :type suffices.