Some AVIF image generators didn't include the PixelInformationProperty (pixi),
even though strictly speaking they should. In v0.9.2, libavif began requiring this.
Let's disable it so we can read those images too.
This informs the compiler that these functions return allocated
memory. That allows it to make some optimization decisions which
can produce better code.
I hadn't realized that gd_error() output a LOG_WARNING. I don't think this error is as significant as the errors that occur when we can't process the user's request at all.
libavif will use this function as a callback.
Using libavif's memory allocators gives libavif a chance to release this memory when it's finished with it.
The configure script has already been requiring freetype-2.1.10+, so
this isn't really dropping old support. Even then, 2.1.3 was released
in 2002, so users have had plenty of time to upgrade.
Don't return AVIF_RESULT_TRUNCATED_DATA, as this is normal for libavif <= 0.8.2. In our tests,
this makes tests pass with libavif 0.8.2.
Plus, we did a few things to stop compiler warnings - and added a newline to error output.
thanks @wantehchang for the collaboration here!
This fixes#677.
Turns out that, in many cases, AVIF's default encoding speed (AVIF_SPEED_DEFAULT)
would be 0, the slowest possible speed.
The team's been working on making speed 6 a great compromise.
We should make this our default as well.
libheif versions that came before 1.9.0 don't support changing the output image chroma.
I did not notice that and it resulted with tests failures across other OSes that don't have
a much newer libheif.
See #678. Supersedes #685.
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.
Ensure that a GIF without any Global or Local color tables is still
decoded by libgd.
GIF89a spec indicates conforming image files need not have
Global or Local color tables at all.
Spec recommends creating custom color map in that situation, and
that at least Black+White as first two entries, to ensure B&W images
are decoded.
Some commonly used single-pixel GIFs found around the web are
undecoded by libgd otherwise. Test case has been included.
References:
https://www.w3.org/Graphics/GIF/spec-gif89a.txthttp://probablyprogramming.com/2009/03/15/the-tiniest-gif-ever
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.
Most code is already using gdPutC instead of Putchar -- only the bmp
module is using Putchar. It's unclear why we have this other form as
they should be equivalent: gdPutC takes an unsigned char (8-bits) and
then calls ctx->putC while Putchar takes a signed int, masks it with
0xff, and then calls ctx->putC.
The history of these funcs goes back to when it's initially imported
as part of the 1.5.0 release, and there doesn't seem to be any notes
as to why.
So change bmp to use gdPutC so we can delete Putchar entirely. The
function isn't exported so no one should even notice. Our tests are
still passing, so hopefully that provide good coverage.
We change the return type of `textLayout()` to `ssize_t`, and signal
failure by returning `-1`, so that laying out an empty string is no
longer handled as failure. We make sure that no overflow occurs,
assuming that all `int` values can be fully represented as `ssize_t`.
Although we have a document describ the avaiable options
are ENABLE_XXX=1/0, there must some one are familar with
ENABLE_XXX=ON/OF. If ENABLE_GD_FORMATS=ON is used, it will
result that GD formats is not enabled actually.
This file contains some accidentally global symbols with generic names.
Give them internal linkage (or remove if unused) to avoid conflicts when
linking another library that happens to use the same generic names.
Apparently, this has not been tested for a long time, and might be a
refactoring relict. Anyhow, we have to pass the context to
`GIFNextPixel` as well.
This issue has been reported by Kleber Tarcísio.
Maryam Ebrahimzadeh
Pierre Joye
Ben Morss
Christoph M. Becker
maryam ebrahimzadeh
Mike Frysinger
Adam Silverstein
willson-chen
Khem Raj
Martin Reboredo
az6667
WilliamHeaven
Mike Frysinger
Remi Collet
Marek Skalický
Benjamin Kramer
Kleber Tarcísio
Fábio Cabral Pacheco