While trying to save images in AVIF format, I've encountered a "dead end" regarding resource management and encoding speed. The current implementation of SaveProc in PluginHEIF.cpp not only ignores user flags but uses an SVT-AV1 configuration that is unusable for standard image saving on 32-bit systems.
The current hard-coded configuration:
"bool SaveProc(FreeImageIO* io, FIBITMAP* dib, fi_handle handle, uint32_t /page/, uint32_t flags, void* /data/)"
and
"libHeif.heif_encoder_set_lossy_quality_f(heifEncoder, 75);"
leads to:
-
memory exhaustion: the encoder attempts to allocate massive buffers for video GOP structures (GOP size 321 in logs), leading to SvtMalloc[fatal]: allocate memory failed (at pic_buffer_desc.c:270).
-
resource bloat: logs show over 70 threads and 15,000+ mutexes spawned for a single image, with memory allocation incorrectly reported (e.g., paradoxical "4 million TB" due to 32-bit integer overflows).
-
CPU trashing: up to 45% of usage with the PC fan skyrocketing for a single static frame.
-
the "Still Image" paradox: the encoder explicitly logs: "Only a single picture was passed in. Consider setting avif=1 for improved efficiency", but the current wrapper provides no access to this fundamental flag.
Now, considering that using ImageMagick on the same image results in a successful save in a few seconds with a minimal memory/CPU footprint, my question is: do you plan to migrate PluginHEIF to use libaom (or libavif), much better for pictures, instead of SVT-AV1, which is basically for videos ?
If not, and SVT-AV1 remains the only option, I think it is vital to expose and force avif=1, intra-period=-1, and lookahead=0 to stop the encoder from initializing its video-engine overhead.
Thanks, Luca
Environment:
Library: FreeImageRe (32-bit build)
Encoder: SVT-AV1 v3.1.2 (Visual Studio 2022 build)
OS: Windows 10/11
While trying to save images in AVIF format, I've encountered a "dead end" regarding resource management and encoding speed. The current implementation of SaveProc in PluginHEIF.cpp not only ignores user flags but uses an SVT-AV1 configuration that is unusable for standard image saving on 32-bit systems.
The current hard-coded configuration:
"bool SaveProc(FreeImageIO* io, FIBITMAP* dib, fi_handle handle, uint32_t /page/, uint32_t flags, void* /data/)"
and
"libHeif.heif_encoder_set_lossy_quality_f(heifEncoder, 75);"
leads to:
memory exhaustion: the encoder attempts to allocate massive buffers for video GOP structures (GOP size 321 in logs), leading to SvtMalloc[fatal]: allocate memory failed (at pic_buffer_desc.c:270).
resource bloat: logs show over 70 threads and 15,000+ mutexes spawned for a single image, with memory allocation incorrectly reported (e.g., paradoxical "4 million TB" due to 32-bit integer overflows).
CPU trashing: up to 45% of usage with the PC fan skyrocketing for a single static frame.
the "Still Image" paradox: the encoder explicitly logs: "Only a single picture was passed in. Consider setting avif=1 for improved efficiency", but the current wrapper provides no access to this fundamental flag.
Now, considering that using ImageMagick on the same image results in a successful save in a few seconds with a minimal memory/CPU footprint, my question is: do you plan to migrate PluginHEIF to use libaom (or libavif), much better for pictures, instead of SVT-AV1, which is basically for videos ?
If not, and SVT-AV1 remains the only option, I think it is vital to expose and force avif=1, intra-period=-1, and lookahead=0 to stop the encoder from initializing its video-engine overhead.
Thanks, Luca
Environment:
Library: FreeImageRe (32-bit build)
Encoder: SVT-AV1 v3.1.2 (Visual Studio 2022 build)
OS: Windows 10/11