rav1e VS image

Sure. You'll see it very often in codec implementations. From rav1e, a fast AV1 encoder mostly written in Rust: https://github.com/xiph/rav1e/tree/master/src/x86

Large portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains.

Or the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...

Again, if anything AOM would be the one restricting licenses to AV1 (if they chose to) except AOM has stated and also published AV1 in a way to allow license free access to development (which allows people to make forks of the official build like it's open source) and usage. (1)(2) I don't see why they would suddenly change this.

You can speed up the sampling process with --vmaf n_subsample=5, which in my experience works more accurately than either 2 or 4, possibly due to this bug/feature present in multiple encoders. You might also need to manually set the number of threads used for VMAF calculation with --vmaf n_threads=16, but YMMV.

That remember me of https://github.com/xiph/rav1e which is an AV1 encoder

I put in the request for ffmpeg passthrough mastering-display data a few years ago and haven't heard of any support yet.

It's getting there.. Initial steps for FFmepg: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8444 rav1e: https://github.com/xiph/rav1e/pull/3000

It's entirely possible to re-use bits of other HW encoders for the first pass (motion estimation, etc).

With the help of the image crate, loading an image from disk is fairly straightforward.

FTR there is a WebP decoder implementation in safe Rust in the image crate: https://github.com/image-rs/image

It used to be quite incomplete for a long time, but work last year has implemented many webp features. Chromium now has a policy of allowing the use of Rust dependencies, so maybe Chromium could start adopting it?

Hello! So I have a local app that I am currently running on desktop (windows). I'm using egui for the UI, and the program basically opens a folder, gets all the images in the folder, and then uses the image-rs library to resize and create a grid of images / some other operations.

png is the de-facto standard Rust crate for reading and writing PNG images, used e.g. by the image crate.

There's also a CLI to convert between formats. It uses the crate image.

exr is a is a 100% Rust and 100% safe code library for reading and writing OpenEXR images. It is used by the popular image crate to read and write OpenEXR.

We're currently looking for contributors to add support for zune-jpeg to the image crate. The image maintainers are open to it, but don't have the capacity to do it themselves. You can find more details here.

It would be helpful to contribute to the general change towards an untyped buffer with runtime representations for color space information and fallible conversions. (https://github.com/image-rs/image/pull/1718). It's currently stalling on having too few eyeballs to judge the impact and need for that complexity.

It uses https://github.com/1Password/arboard and https://github.com/image-rs/image under the hood. I haven't tested deeply but I assume it should handle many formats out of the box.