Uses new Rust 2021
|0.2.3||Nov 23, 2022|
|0.2.2||Sep 23, 2022|
|0.2.1||Aug 6, 2022|
|0.2.0||Jun 26, 2022|
|0.1.0||May 2, 2021|
#3 in #jpeg-image
983 downloads per month
Used in 2 crates (via turbojpeg)
Raw Rust bindings for the
turbojpeg library. If you want to
work with JPEG files in Rust, you should use the high-level bindings from the
We support multiple options for building the native TurboJPEG library and linking to it. There are three aspects that you can control:
- Source: should we build the library ourselves, or should we use a compiled version from your system?
- Linking should we use static or dynamic linking?
- Binding: should we use pregenerated Rust bindings, or should we generate them at build time?
TurboJPEG is written in C, so we must either compile it ourselves, or look up a
compiled library on your system. You can control what we do using
TURBOJPEG_SOURCE environment variable:
TURBOJPEG_SOURCE=vendor(default if the
cmakefeature is enabled): we build TurboJPEG from source using the
cmakecrate and link it to your Rust executable. We use TurboJPEG sources that are bundled with the crate (version 2.1.3). This is the recommended option.
This option requires a C compiler, and if you want to compile the SIMD code that actually makes TurboJPEG fast, you will also need NASM or Yasm. By default, if TurboJPEG does not find NASM, you will receive a compilation error. However, you can disable the default feature
require-simdand TurboJPEG will just skip the SIMD code when NASM is not found (but performance will suffer).
TURBOJPEG_SOURCE=pkg-config(default if the
cmakefeature is disabled and
pkg-configis enabled): we look up the library using
pkg-configfeatures are disabled): we look up the library in
TURBOJPEG_LIB_DIR. If you want to generate the bindings at build time (see below), then you should also set
TURBOJPEG_INCLUDE_DIRto point to the directory with the
We can link the compiled library from the previous step to your Rust executable either statically (the library becomes part of the executable) or dynamically (the library is looked up at runtime). You can control this using environment variables:
TURBOJPEG_STATIC=1configures static linking.
TURBOJPEG_SHARED=1) configures dynamic linking.
If you don't specify any of these variables, the default behavior depends on
explicit, we link
statically by default. However, if you use
pkg-config, we let the
pkg-config crate decide; it typically uses dynamic linking by
To use the C library in Rust, we need some boilerplate "binding" code that
exports C symbols (functions and variables) into Rust. We have two options and
you control the decision with the
TURBOJPEG_BINDING environment variable:
TURBOJPEG_BINDING=pregenerated(default unless the
bindgenfeature is enabled): use a binding code that is shipped with this crate. This should work most of the time and it is the recommended option.
TURBOJPEG_BINDING=bindgen(default if the
bindgenfeature is enabled): generate the binding during build using bindgen. This is normally not necessary, but it might save your day if your TurboJPEG is somehow incompatible with our pregenerated binding code.
This crate supports multiple features:
cmake(default): allows us to build TurboJPEG from source (
require-simd(default): when building TurboJPEG from source, aborts the compilation when NASM is not found and the fast SIMD code would be skipped.
pkg-config(default): allows us to find TurboJPEG using
bindgen: allows us to generate the bindings at build time using
Note that the
turbojpeg crate "reexports" these features.