Repository navigation
Cropped HEIC images fail with âSecurity limit exceededâ after decoder security limit changes #1856
Description
Hi,
I am upgrading libheif from 1.19.7 to 1.23.0 and libde from 1.0.15 to 1.1.1 and faced with a decoding regression for some HEIC files with transformation properties.
This looks related to this issue:
As I understand, for cropped HEIC images, it looks like the new limits may be calculated from the transformed size after clap, while the HEVC decoder still has to decode the full coded frame.
1) C013.heic
heif-dec with libheif 1.23.0:
File contains 2 images
Could not decode image: Memory allocation error: Security limit exceeded:
Image size 1280x720 exceeds the maximum image size 132496
heif-info:
image: 300x300 (id=1002), primary
transformations:
crop: left=490 top=210 right=490 bottom=210
image: 300x300 (id=1005)
transformations:
crop: left=490 top=210 right=490 bottom=210
From heif-info -d, both image items have:
ispe = 1280x720
clap = 300x300
The reported limit matches the crop size plus coding_unit_size:
(300 + 64) * (300 + 64) = 132496
But the decoder still needs to decode the full coded HEVC frame:
1280 * 720 = 921600
2) MIAF007.heic
heif-dec with libheif 1.23.0:
File contains 1 image
Could not decode image: Memory allocation error: Security limit exceeded:
Image size 1280x720 exceeds the maximum image size 298496
heif-info:
image: 360x640 (id=1002), primary
transformations:
crop: left=320 top=180 right=320 bottom=180
angle (ccw): 90
mirror: vertical
From heif-info -d:
ispe = 1280x720
clap = 640x360
irot = 90 degrees
imir = vertical
The reported limit again matches the clap size plus coding_unit_size:
(640 + 64) * (360 + 64) = 298496
But the actual frame is still:
1280 * 720 = 921600
So, the questions are:
Do I understand correctly that the files look valid and this behavior is a regression?
Should the decoder limit be based on the uncropped ispe size instead of the transformed?
Samples:
sl_heic_samples.zip
Activity
riyasy commentedon Jun 30, 2026
I am facing similar issue with cropped avif
Version 1.23.1 (was working in v1.21.2). I upgraded from 1.21.2.
Gerald-Ha commentedon Jul 16, 2026
Hi, I believe this is the same root cause.
I investigated this issue while trying to make Samsung Galaxy S23 Ultra 200MP HEIC images work in Immich.
The failure is caused by the hardcoded security limits in libheif for the ipma, iloc and iref boxes. Samsung 200MP HEIC files typically contain around 576â579 items, while libheif rejects anything above 256.
I created a proof-of-concept patch that increases these limits and verified that the affected images decode correctly in Immich afterwards.
Repository with the patch and documentation:
https://github.com/Gerald-Ha/immich-s23-heic-patch
I'm not suggesting that this exact patch should necessarily be merged as-is, but I hope it helps identify a proper upstream solution.
torusrxxx commentedon Jul 17, 2026
Number of properties grow with number of
gridtiles. Considering a 10-bit 200MP image uses over 1GB RAM just for the decoded frame buffer, I guess lifting the number of properties aggressively isn't that much of a problem.Gerald-Ha commentedon Jul 17, 2026
It's optional. Either switch to JPG or use the patch if you prefer HEIC; to each their own.
dlemstra commentedon Jul 31, 2026
Here is another image reported by an @ImageMagick user that no longer works after that patch: ios-photo.zip
novomesk commentedon Aug 23, 2026
Also AVIF with crop is unable to decode:
https://raw.githubusercontent.com/AOMediaCodec/av1-avif/refs/heads/main/testFiles/Link-U/kimono.mirror-vertical.rotate270.crop.avif
add regression tests for decoding clap-cropped images (#1856)
allow a minimum coded frame size in the tightened decode limit (#1856)
farindk commentedon Aug 31, 2026
Thank you for the report and the example images.
Should be fixed by @programingKing's PR and 35d1187, which adds a lower bound on the image size limit.
The latter is needed for "ios-photo.zip".