Demand for AVIF support on the web is growing, as the word gets out
about this new file format which allows higher-quality encoding at
smaller sizes. Core contributors to major open-source CMSs are
interested in auto-generating AVIF images! They've been simply
waiting for support to appear in libgd.
This PR aims to meet the growing demand, and to help bring smaller,
more beautiful images to more of the web - to sites created by
experienced developers and CMS users alike.
This PR adds support by incorporating libavif in addition to the
existing libheif support. It's generally felt that libavif has
more complete support for the AVIF format. libavif is also used
by the Chromium project and squoosh.app.
In this PR, I've endeavored to incorporate the latest research into
best practices for AVIF encoding - not just for default quantizer
values, but also an algorithm for determining the number of
horizontal tiles, vertical tiles, and threads.
Fixes#557.
With the adoption of AVIF by Firefox and Chromium based browsers (still
in experimental phase), the newer incorporation of HEIF by Canon and Sony
in their cameras and the newer support of both of them in modern software
like ImageMagick, GIMP and Krita, `gd` haven't seen any endorsement for
the formats up until this PR.
Reading and writing is done by `libheif`, with functionality for chroma
subsampling (for now `4:2:0`, `4:2:2` and `4:4:4`), quality (with new
`200` for lossless) and compression (whether `HEVC` or `AV1`) selection.
This was tested with `libheif` version `1.11.0` in my Solus machine.
Also, fixes both #395 and #557.
We've been tracking program deps in the build files, so it ends up
being redundant for a lot of our test/example programs. Clean them
up, and update some of the cmake/automake files as needed.
Since getopt is only needed by various helper programs, we start a new
program utility static library to stuff things into so they don't fill
up the gd library itself.
This comes from NetBSD. Fixes#401.
The cmake build was missing gd_color_match.c which meant the library
didn't export the gdImageColorMatch function. Sync the two lists in
the autotools and cmake files to make this easier to check. Listing
header files in autotools source lists isn't a problem.
We are using GDLIB_REVISION to refer to the gd version string (the "z"
in "x.y.z"), and we are using it to control the libtool revision field.
This leads to problems where the version increases (e.g. "2.1.1") but
the libtool revision doesn't (e.g. "0"). So scripts end up seeing a
revision of "0" in their output instead of "1".
Namespace the libtool version variables with "_LT_" to avoid any more
collisions.
Fixes#140.
The Makefile.am has no changes other than sorting & unwrapping the files
to make it a bit more readable (and dropping duplicate entries).
The CMakeLists.txt gains a few files that were added recently but left
out of the cmake build.
Closes#183.
These are convenience functions which load or save image data to a
file. They are roughly equivalent to opening a file handle with
fopen() and calling gdImageCreateFrom*() or gdImage*() on the FILE
pointer. However, these functions identify the input or output format
from the filename suffix and call the appropriate read or write
function accordingly.
gdSupportsFileType() can be used to test if a specific file format
is supported.
Most scripting interfaces already do something like this but now
there's support for doing it from C as well.
This change also adds test cases for the code and naturaldocs
documentation.
Up to now, the version numbers were defined in configure.ac and put
into gd.h by generating it from gd.h.in, replacing the values of
several C macros. This violates the DRY principle, won't work on a
dumb build system, confuses some dev tools and is just a huge headache
in general.
This change makes gd.h (no longer generated) the home of the version
number and provides a script (config/getver.pl) which can extract the
requested version components from the header file. configure.ac now
gets the version number from gd.h instead of vice versa.
In addition, there are now C functions that return the values of the
version macros. This is for the benefit of non-C code using the
library without access to the header file. It also provides a way to
get the version number of the library currently linked rather than the
header the program was compiled against. (This could change if the
shared library is updated without recompiling the program using it.)
We can build gd w/out png/zlib support, but some of the helper
programs require that functionality. Disable the programs based
on what libs are available.
`configure.ac` and `bootstrap.sh` are moved in the top directory.
`bootstrap.sh` is completed to execute `libtoolize`. The list of files
to clean is reduced. Other files can be cleaned with `make distclean`.
`src/Makefile.am` is fixed for missing `gd_nnquant.c` dependency.
`ACX_PTHREAD` macro is moved to a `m4` directory to make `configure.ac`
easier to read.
--HG--
branch : fix/autotools
rename : src/bootstrap.sh => bootstrap.sh
rename : src/configure.ac => configure.ac
Pierre Joye
Mike Frysinger
Ben Morss
Martin Reboredo
willson-chen
Chris Reuter
Ondřej Surý
Marcin Wojdyr
Vincent Bernat
tabe