First, we must not forget to call `avifImageDestroy()` when we're
finished with the image.
Then we also need to cater to the allocated `dataBuf`. To keep track
of that, we "extend" `avifIO` as `avifIOCtxReader`. To simplify, and
to avoid unnecessary allocations, we use `realloc()`. To better fit
with GD, we also use the GD memory allocation functions instead of the
ones provided by libavif.
There are small typos in:
- examples/copyrotated.c
- src/gd.c
- src/gd.h
- src/gd_avif.c
- src/gd_nnquant.c
- src/gd_tga.c
- src/gd_topal.c
- src/wbmp.c
- tests/avif/compare_avif_to_png.c
Fixes:
- Should read `requires` rather than `reqiures`.
- Should read `of the` rather than `ofthe`.
- Should read `memory` rather than `memmory`.
- Should read `maximum` rather than `maxmum`.
- Should read `intersection` rather than `intertersection`.
- Should read `hypotenuse` rather than `hypothenus`.
- Should read `flexibility` rather than `flexibilty`.
- Should read `always` rather than `alwasy`.
- Should read `also` rather than `alos`.
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.
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.
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.
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.