I’ve tried it in iex and everything works just fine. The file was always successfully created even before, but it crashes right after it. I suspect it’s related to LiveView Upload somehow. Thanks for your help, I’ll try to identify what’s causing it.
Edit: using Image.thumbnail/3 without Image.open() and Image.write() fixed the issue.
I’ve just published Image version 0.43.0. It has some breaking changes (rename functions in nearly all cases). This brings the code a lot close to a 1.0 release. The remaining issue is to complete the re-write of the color handling code over the next couple of months.
Image.erode/2 and Image.dilate/2 now take a radius parameter rather than a pixels parameter. Both functions have been refactored to allow a radius in the range 1..5 with a default of 1. The radius represents the dimension of the matrix used in the Vix.Vips.Operations.range/4 function that underpins dilation and erosion. As such they represent the approximate number of pixels eroded or dilated. In addition, this function now results in a single libvips operation. The previous implementation created n operations (where n was the value of the pixels param) that could result in a slow imaging pipeline and in some cases a segfault of the entire VM due to stack space exhaustion in libvips.
The signature for Image.linear_gradient/{1..3} has changed. The function now takes:
Image.dominant_color/2 now returns an {:ok, rgb_color} tuple rather than a [r, g, b] list. Use Image.dominant_color!/2 if only the color value return is required.
Image.map_pages/2 is deprecated in favour of Image.map_join_pages/2 to better reflect the intent of the function.
Image.linear_gradient/{1..3} now takes an :angle option which determines the angle of the gradient in degrees. Thanks to @severian1778 for considerable patience. Closes #67.
Improve options handling and documentation for Image.radial_gradient/3.
Add Image.radial_gradient!/3 to mirror Image.radial_gradient/3.
Add Image.dominant_color!/2 to mirror Image.dominant_color/2.
Add Image.extract_pages/1 which will extract the pages of a multi-page image into a list of separate images.
I’ve published Image version 0.45.0. Please note this includes a breaking change for how images from text are rendered. For most (maybe all?) current use cases the change may not be visible. Since I didn’t post an announcement for Image 0.44.0 I’m including that changelog here now too.
The implementations of Image.text/2 and Image.simple_text/2 have been simplified to use only the built-in Pango renderer. A bug in font sizing using the Pango renderer has also been fixed. As a result, there may be some small visual differences between text images generated by Image 0.45.0 compared to previous releases.
Image.text/2 now uses only the built-in Pango renderer for all use cases. SVG is not nhow used for any rendering in Image.text/2 or Image.simple_text/2. This gives a more consistent output and less ambiguity. However as a result, a small number of options are no longer available since they cannot be honoured by Pango:
:text_stroke_color
:text_stroke_width
The :autofit option to Image.text/2 is also removed. The autofit capability is now controlled by whether the :width and/or :height options are provided.
Some other options are now treated differently in Image.text/2:
:width and :height are now truly optional. If ommitted, the renderer will calculate the required image size based upon the other options. It is acceptable to specify :width and omit :height in which case the maximum width is fixed and the height is variable.Fix warnings on upcoming Elixir 1.17.
A bug resulting in incorrect font sizing with using the Pango renderer has been fixed. Font sizing is now very similar to the sizing of the previously used SVG renderer.
Image.Blurhash.encode/2 and Image.Blurhash.decode/1 to encode and decode blurhashes. Based upon a fork of rinpatch_blurhash. Thanks to @stiang for the suggestion. Thanks very much to @rinpatch for the implementation.
Is it possible to stream the upload back up to S3 with a different path? The example uses conn, but I’m planning on doing image processing in the background. So it would stream the file from an S3 bucket, resize it, then stream it back. Here’s what I attempted, but this isn’t working:
def resize_image(photo) do
image_path = "processed/#{photo.image}"
S3.download_file(bucket(), photo.image, :memory)
|> ExAws.stream!()
|> Image.open!()
|> Image.resize!(1280)
|> Image.stream!(suffix: ".jpg")
|> S3.upload(bucket(), image_path)
|> ExAws.request()
end
Yes, that’s possible. I’m only on mobile now for the next few hours so pardon the brevity. There is a test which does exactly that - stream from AWS and then back to AWS. I’d suggest take a look at that if you can - and I’ll revert here again when I’m properly back online.
Edit: the test is here: image/test/stream_image_test.exs at main · elixir-image/image · GitHub
Ok, so that’s basically exactly what I was already doing. I’ve tried the code line by line, and the error happens with ExAws.request(). Does this indicate to you what I’ve done wrong?
** (Vix.Vips.Image.Error) Failed to write to target
(vix 0.27.0) lib/vix/vips/image.ex:568: anonymous fn/1 in Vix.Vips.Image.write_to_stream/2
(elixir 1.16.2) lib/stream.ex:1626: Stream.do_resource/5
(elixir 1.16.2) lib/stream.ex:1828: Enumerable.Stream.do_each/4
(elixir 1.16.2) lib/task/supervised.ex:339: Task.Supervised.stream_reduce/7
(elixir 1.16.2) lib/enum.ex:4396: Enum.map/2
(ex_aws_s3 2.5.3) lib/ex_aws/s3/upload.ex:141: ExAws.Operation.ExAws.S3.Upload.perform/2
iex:14: (file)
The S3 download works, and I have S3 upload working elsewhere, so I can confirm ExAws is configured correctly..
// Edit
So I think the problem is I was using .resize!() with a number of pixels, and not with a scale.
Using .thumbnail!() instead works.
Ah, indeed - Image.resize/2 takes an argument that is a factor. So you were resizing the image to be 1_280 times larger than the original. Which would be extremely large - but I still don’t think it should fail. I’ll reproduce using Vix functions only and open an issue there so we can get @akash-akya’s opinion.
Image.thumbnail/2 is definitely the correct function for resizing images. I know the naming can cause some confusion. I am reflecting the underlying libvips function names. Perhaps thats not the right strategy in this case?
The other thing to note is that AWS (native AWS) requires a minimum chunk size for a stream which is 5MB. Therefore I would recommend adding the :buffer_size option to Image.stream/2. For example:
@s3_buffer_size 5 * 1024 * 1024
...
|> Image.stream!(suffix: ".jpg", buffer_size: @s3_buffer_size)
...
Sounds good. And yeah, an image 1280x would be quite large.
The naming convention wasn’t very intuitive for me, I thought thumbnail was oddly specific, and assumed what it did without looking at the docs. I wanted to resize the image, so that’s the function I tried. Next time I will RTFM first 
I’ve published Image 0.48.0 today. It’s only a small update that adds :model_options, :featurizer_options and :batch_size as configuration options to the built in convenience image classifier.
The result is that Image can enable a wider range of HuggingFace models to be used quickly.
In collaboration with @willc0de4food, here’s an example using the Falconsai/nsfw_image_detection model:
iex> image = Image.open!("./test/support/images/jose.png")
%Vix.Vips.Image{ref: #Reference<0.185418317.1571422244.223902>}
iex> Image.Classification.classify(image)
%{
predictions: [
%{label: "normal", score: 0.9998503923416138},
%{label: "nsfw", score: 1.495583273936063e-4}
]
}
I suspect NSFW image detection is quite useful in a lot of applications so I hope the config options are helpful.
The example above is configured in runtime.exs as follows:
config :image, :classifier,
model: {:hf, "Falconsai/nsfw_image_detection"},
featurizer: {:hf, "Falconsai/nsfw_image_detection"},
featurizer_options: [module: Bumblebee.Vision.VitFeaturizer],
name: Image.Classification.Server,
autostart: true
Image wraps an optional Bumblebee/Nx server to make it easy to onboard image classification capabilities without having to immediately learn how to set up the Bumblebee/Nx infrastructure efficiently.
It’s not intended to be a complete solution for more complex production requirements which should use Bumblebee/Axon/Nx directly. The documentation has been updated to make that clearer.