8 releases (2 stable)
1.0.1 | Sep 29, 2024 |
---|---|
1.0.0 | Feb 3, 2024 |
0.2.3 | Nov 23, 2022 |
0.2.2 | Sep 23, 2022 |
0.1.0 | May 2, 2021 |
#434 in Images
4,622 downloads per month
Used in 8 crates
(via turbojpeg)
4.5MB
86K
SLoC
turbojpeg-sys
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
turbojpeg
crate.
These bindings are for TurboJPEG version 3.0 and use the new API (prefixed with
tj3
). Note that most package managers for Linux have only TurboJPEG 2.0 or
2.1.
Building
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?
Source
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
(recommended, default if thecmake
feature is enabled): we build TurboJPEG from source using thecmake
crate and link it to your Rust executable. We use TurboJPEG sources that are bundled with the crate (version 3.0.1).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-simd
and TurboJPEG will just skip the SIMD code when NASM is not found (but performance will suffer). -
TURBOJPEG_SOURCE=pkg-config
(default if thecmake
feature is disabled andpkg-config
is enabled): we look up the library usingpkg-config
. -
TURBOJPEG_SOURCE=explicit
(default ifcmake
andpkg-config
features are disabled): we look up the library inTURBOJPEG_LIB_DIR
. If you want to generate the bindings at build time (see below), then you should also setTURBOJPEG_INCLUDE_DIR
to point to the directory with theturbojpeg.h
header.
Linking
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=1
configures static linking.TURBOJPEG_DYNAMIC=1
(orTURBOJPEG_SHARED=1
) configures dynamic linking.
If you don't specify any of these variables, the default behavior depends on
TURBOJPEG_SOURCE
. If TURBOJPEG_SOURCE
is vendor
or 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
default.
Binding
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 thebindgen
feature 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 thebindgen
feature 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.
Features
This crate supports multiple features:
cmake
(default): allows us to build TurboJPEG from source (TURBOJPEG_SOURCE=vendor
).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 usingpkg-config
(TURBOJPEG_SOURCE=pkg-config
).bindgen
: allows us to generate the bindings at build time usingbindgen
.
Note that the turbojpeg
crate "reexports" these features.