When the input image (16K * 16K) is too large, the generated heif image cannot be opened. The prompt file is damaged.

[yjszyd0813]

When the input image (16K * 16K) is too large, the generated heif image cannot be opened. The prompt file is damaged. How to solve this problem? How to improve the encoding speed? To test encoding 5K * 5K images into HEIF files, 1.2S is required

[yjszyd0813]

The libheif built through vcpkg is missing secure_limits.h

[bradh]

The libheif built through vcpkg is missing secure_limits.h

This seems like a different issue and probably would be better raised on a new ticket.

[bradh]

When the input image (16K * 16K) is too large, the generated heif image cannot be opened. The prompt file is damaged. How to solve this problem? How to improve the encoding speed? To test encoding 5K * 5K images into HEIF files, 1.2S is required

These look like two different issues (1 = the corrupt file, 2 = encoding speed). Could you consider splitting them up. Also can you edit the issue(s) to provide more details for exact reproduction?

[farindk]

The libheif built through vcpkg is missing secure_limits.h

This seems like a different issue and probably would be better raised on a new ticket.

security_limits.h is no installed header. I do not understand what "is missing" means.

[farindk]

When the input image (16K * 16K) is too large, the generated heif image cannot be opened.

Opened where? The issue is probably that the viewer application tries to load the whole image into a single "texture" and fails to do so because 16K * 16K is about 1 GB uncompressed. For that sizes, the viewer application has to support loading the image in tiles.

[yjszyd0813]

The libheif built through vcpkg is missing secure_limits.h

This seems like a different issue and probably would be better raised on a new ticket.

security_limits.h is no installed header. I do not understand what "is missing" means.

Sorry, I meant that “security_limits.h” is not compiled or built by vcpkg. I was unable to find the relevant parameters in it.

[farindk]

Sorry, I meant that “security_limits.h” is not compiled or built by vcpkg. I was unable to find the relevant parameters in it.

I still don't understand the issue. security_limits.h is just an internal file that contains a couple of constants. That file is used when building the library, but it is not accessible in any way from outside.

[bradh]

Sorry, I meant that “security_limits.h” is not compiled or built by vcpkg. I was unable to find the relevant parameters in it.

https://github.com/strukturag/libheif/blob/master/libheif/security_limits.h

[silverbacknet]

vcpkg is still on 1.17.6 but that's only the most minor difference in the header, and the few patches it has don't touch anything about the file. yjszyd0813's hunch is definitely a red herring.

I haven't looked at the new tiling code much, does it automatically tile images too large for the codec now? Like AV1 maxes out at 4096 × 2304, and beyond that must be tiled at either the codec or HEIF level.

[farindk]

I haven't looked at the new tiling code much, does it automatically tile images too large for the codec now? Like AV1 maxes out at 4096 × 2304, and beyond that must be tiled at either the codec or HEIF level.

There is an API to encode images tile by tile and also decode it in parts. The intention is to support even huge dimensions (think > 1M x 1M). For those dimensions it's not possible anymore to hold an image in memory. Might be that we add an API for automatic tiling for smaller images. That's trivial to add.

[farindk]

There is now an API to control the security limits. To switch them off completely, you can use this:

const heif_security_limits* no_limits = heif_get_disabled_security_limits();
heif_context_set_security_limits(context, no_limits);

There is also a new API to access the image as single tiles. See the documentation.