Credits where credit is due, but you are doing an amazing work yourself. Your API design is on point and there is a lot of merit in creating higher level abstractions to turn more complex libraries/API into an accessible package. 
greven
jc00ke
You are 100% right! Thank you to @akash-akya and @cocoa for their immediate Elixir work and to Dr. Cupitt who has done some amazing work!
marschro
Absolutely great library!!! Thanks !!!
Currently Image.Video.with_video/2 is only working with a path.
I have a video as binary, just downloaded from ObjectStorage with ExAws …
Is it best approach, to just write it temporarily to the disk and work on this? Or is there another better approach?
The only Thing I need, is to extract a poster image from the video. I then can get rid of the downloaded video again…
cheers!
Martin
kip
ex_cldr Core Team
Glad you’re finding value in image and vix!
The Image.Video module is a wrapper around Evision.VideoCapture and the functions there work only on a path, a device (like a camera) or an RTSP video stream. Not a raw binary.
You might find that either membrane or xav provide a closer API fit to what you are looking for.
I would like to be able to do more - and do it more easily - than the video capabilities of OpenCV and I plan to look at how to integrate xav at some (undefined) time in the future.
Neophen
Hey i’m having an issue with Trying to use Image.rounded!, when trying to compose it with other images, as it adds another band to images with a transparancy?
** (Image.Error) operation build: composite2: images do not have same numbers of bands
Would this be a good a workaround?
defp rounded_full(image) do
image = Image.rounded!(image)
case Image.bands(image) do
4 ->
image
5 ->
# Image.rounded adds another band we then remove the alpha band
[r, g, b, _a, mask] = Image.split_bands(image)
# Recombine with mask as alpha
{:ok, normalized} = Operation.bandjoin([r, g, b, mask])
normalized
other ->
raise "Unsupported band count: #{other}"
end
end
kip
ex_cldr Core Team
Good call out, definitely a bug. Would you consider opening an issue? I need to add logic to combine the existing alpha and the new alpha mask when an alpha band already exists. Just discarding the existing alpha band isn’t appropriate in many situations.
Neophen
Thank you Kip, I’d have a look myself and do a pr but would not even have an idea of where to start 
kip
ex_cldr Core Team
I’ve published image version 0.64.0.
The primary intent of this release is to stablise the code in readiness for a 1.0 release. Deprecated code has been removed, a standardised color model introduced (via the new library color) and objective classification and detection has been removed to a new image_detection library. Video frame extractions is now using Xav rather than eVision.
As a result, there are quite a few breaking changes - and some new goodies. The breaking changes aren’t dramatic - but they are breaking.
Hopefully this is the last pre-release before 1.0. Feedback on this release will determine that outcome!
Breaking Changes
-
Five long-deprecated functions have been removed:
Image.interpretation/1— useImage.colorspace/1.Image.type/1(wasformat/1) — useImage.band_format/1.Image.convert_to_mask/1— useImage.convert_alpha_to_mask/1.Image.convert_to_mask!/1— useImage.convert_alpha_to_mask!/1.Image.map_pages/2— useImage.map_join_pages/2.
-
Image.Colorhas been removed. Color handling now lives in two new modules and one new dependency: -
Image.ClassificationandImage.Generationhave moved to a new sibling package,:image_detection. -
:bumblebeeis no longer a dependency of:image. It is configured in the new libraryimage_detection. -
Image.Videois now backed by Xav (a thin Elixir wrapper around FFmpeg) instead of:evision/ OpenCV. The public API surface is largely unchanged but the underlying type, options, and a few semantic details have moved:-
The video struct is now
%Image.Video{}(with fields:reader,:source,:fps,:duration_seconds,:frame_count,:width,:height) rather than%Evision.VideoCapture{}. Pattern-match on the new struct module if your code does so. -
Image.Video.open/2’s:backendoption has been removed. FFmpeg picks the demuxer automatically and there is no concept of pluggable backends in Xav. -
Image.Video.known_backends/0,available_backends/0,known_backend?/1,known_backend_values/0, andavailable_backend?/1have been removed for the same reason.Image.Options.Video(the module that owned the backend table) has been deleted. -
Camera input is now opened via a platform-specific device path.
:default_cameraresolves to/dev/video0on Linux,"0"(AVFoundation device 0) on macOS, and"video=0"on Windows. An integer camera index is mapped to the corresponding/dev/videoN(or platform equivalent). For non-default cameras you can also pass an explicit FFmpeg device string. -
Frame-based seeking (
Image.Video.seek/2withframe: n, andImage.Video.image_from_video/2withframe: n) is now implemented as a time-based seek ton / fpsfollowed by zero or morenext_framecalls. For most files this lands on the requested frame; for very inter-frame-compressed files FFmpeg may snap to the nearest preceding keyframe. -
Image.Video.close/1is now a no-op that returns{:ok, %Image.Video{reader: nil}}. Xav garbage-collects the underlying FFmpeg context, so explicit close is no longer necessary. The function is retained for source compatibility; subsequent operations on the closed struct return{:error, %Image.Error{reason: :video_closed}}. -
Image and audio frames are decoded by FFmpeg + libswscale rather than by OpenCV’s videoio backend. Pixel-exact comparisons against fixtures generated by the previous version will not match; the test fixture
test/support/validate/video/video_sample_frame_0.pnghas been regenerated.
-
-
:xavis now an optional dependency. It requires FFmpeg ≥ 6.0 to be installed on the system. Add it to yourmix.exsif you useImage.Video:{:xav, "~> 0.10", optional: true} -
:evisionis no longer needed forImage.Video. It is still required forImage.QRcodeand for theImage.to_evision/2/Image.from_evision/1interop helpers, which are unchanged. The README’s optional-dependency table reflects the new split. -
Image.Erroris now a structured public exception. It carries:reason(atom or{atom, value}tuple),:operation,:path,:value, and a derived:message. Every fallible function in the library now returns{:ok, value}or{:error, %Image.Error{}}— bare-string error tuples have been eliminated. Bang variants raise the same struct. The newImage.Error.wrap/2helper attaches structured context to a raw libvips orFile.*error. Pattern-match on:reasoninstead of scraping:message:case Image.open(path) do {:ok, image} -> ... {:error, %Image.Error{reason: :enoent}} -> not_found_handler() {:error, %Image.Error{} = err} -> raise err end
Enhancements
-
Image.dominant_color/2now accepts a:methodoption of either:histogram(the existing default) or:imagequant. The:imagequantmethod routes throughlibimagequant(viavips_gifsave_buffer) and returns a palette of{r, g, b}tuples ordered by perceptual importance. New:effortand:ditheroptions tune the quantiser. Seeguides/performance.mdfor a comparison of the two methods. -
Colour arguments to drawing, embedding, trimming, gradient, chroma key, comparison, warp-perspective, meme, replace-colour, flatten, and
if_then_elseoperations are now correctly converted to the target image’s colour space. Drawing:redon a Lab image now produces actual Lab red, not the bytes[255, 0, 0]reinterpreted as Lab. -
New
Image.PixelandImage.ICCProfilemodules.Image.Pixel.to_pixel/3is the canonical way to turn any user-friendly colour input into a libvips-ready pixel for a particular image;Image.Pixel.to_srgb/1is the image-independent equivalent for callers (SVG renderers, gradients) that need a fixed sRGB output. -
The
:colorlibrary is now a dependency of:image. It is now the canonical colour science layer for the project. -
Image.Videonow supports HTTP/HTTPS/RTSP/RTMP URLs as video sources for free, since FFmpeg supports them natively. -
Image.xav_configured?/0is the new compile-time predicate that gates theImage.Videomodule (analogous toImage.evision_configured?/0andImage.bumblebee_configured?/0). -
The
Image.Video.frame_to_image/1helper exposes the rawXav.Frame→Vix.Vips.Image.t()conversion (used internally byimage_from_video/2andstream!/2). Useful if you have a frame from elsewhere in the Xav ecosystem and want to bring it intoImage.
11
