Repository navigation
[Bug]: HEIC preview generation fails when identified as JPEG #65411
Description
⚠️ This issue respects the following points: ⚠️
- This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
- This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
- I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
- I agree to follow Nextcloud's Code of Conduct.
- I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.
Bug description
I am experiencing a HEIC preview-generation failure on Nextcloud Server 34.0.4 - The affected files originate directly from an iPhone 15 running the latest firmware as of Oct 26. I can vouch for them - they have not passed through any untrusted computer.
Nextcloud identifies the files as image/heic based on their filename and MIME-type handling, but PHP Imagick's automatic format detection identifies the image content as image/jpeg.
The HEIC preview provider then fails because it forces Imagick to use the HEIC decoder explicitly. Removing that forced decoder prefix allows Imagick to process the affected files successfully and Nextcloud to generate previews.
This appears to be a compatibility defect in the HEIC preview provider: it assumes that files classified as HEIC by Nextcloud must be readable through the forced HEIC decoder, even when Imagick can successfully identify and process the actual image content using automatic format detection.
Not all HEIC files return image/jpeg when Imagick performs automatic format detection. Some files are identified as HEIC and can be processed normally through the HEIC preview provider. The failure appears to affect files for which Imagick identifies the underlying image content as JPEG despite Nextcloud classifying the file as image/heic.
Since these files came directly from the iPhone 15, this suggests that the Nextcloud provider's assumptions about the relationship between the filename, container format and decoded image format may be too restrictive, or possibly too fixated on filename/extention, while Imagick is more relaxed.
Steps to reproduce
- Take a picture with the iPhone 15 using the latest OS version.
- Let it upload to Nextcloud via the standard sync, or upload it via the Files app
- Try to view the image in File or Memories after allowing the automatic processing to run.
Related issues and security context
This report appears closely related to:
-
Nextcloud/NextcloudPi Add a magic wrapper to allow phpunit4 to run the code again #2137 — Bug: HEIC files containing JPEG data cannot generate previews: Bug: HEIC files containing JPEG data cannot generate previews nextcloudpi#2137
This issue describes Nextcloud 34 failing to generate previews when Imagick identifies the content as JPEG despite a
.HEICfilename, with preview generation succeeding after the extension is changed. -
Nextcloud Server Secure heic/heif image preview provider #58393 — Secure heic/heif image preview provider: Secure heic/heif image preview provider #58393
This issue discusses the security concerns surrounding the HEIC/HEIF preview provider and the need for a safer implementation.
-
Nextcloud Server PR fix: Force Imagick to only accept HEIC/HEIF images #59206 — Secure HEIC/HEIF preview provider: fix: Force Imagick to only accept HEIC/HEIF images #59206
This pull request addresses the security concerns by explicitly forcing HEIC decoding. The behaviour reported here suggests that the resulting implementation may reject legitimate files whose image content is not accepted by the forced decoder, even though automatic format detection can process them.
Expected behavior
The files should be viewable seamlessly, the same way an image from an Android device would be.
Nextcloud Server version
34
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.5
Web server
Apache (supported)
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
- Default user-backend (database)
- LDAP/ Active Directory
- SSO - SAML
- Other
Configuration report
## Environment
* Nextcloud Server: 34.0.4
* Operating system: Debian
* PHP Imagick: 3.8.1
* ImageMagick: 7.1.1-43 Q16 x86_64
* Preview provider: `OC\Preview\HEIC`, explicitly enabled
* Application affected: Memories, with preview generation also failing through the Nextcloud preview-generation commandList of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
Observed behaviour
For an affected file, IMG_9231.HEIC, PHP Imagick can successfully identify the image using automatic format detection:
$p = "/Data/NextCloud/data/RichardP/files/Photos/Phone/Photos/2024/12/IMG_9231.HEIC[0]";
$i = new Imagick();
$i->pingImage($p);
echo $i->getImageMimeType() . " "
. $i->getImageWidth() . "x"
. $i->getImageHeight() . PHP_EOL;This reports image/jpeg and the image dimensions.
However, forcing the HEIC decoder fails:
$i->pingImage('heic:' . $p);This produces:
ImagickException: ImageTypeNotSupported
error/heic.c/ReadHEICImage/664
The equivalent test with the heif: prefix also fails.
Nextcloud's occ preview:generate command consequently reports that no provider successfully handled preview generation.
Workaround tested
In lib/private/Preview/HEIC.php, I temporarily modified two lines in getResizedPreview().
Original line:
$bp->pingImage('heic:' . $tmpPath . '[0]');Changed to:
$bp->pingImage($tmpPath . '[0]');Original line:
$bp->readImage('heic:' . $tmpPath . '[0]');Changed to:
$bp->readImage($tmpPath . '[0]');No other changes were required for this test. With these two prefixes removed, preview generation worked for all three affected HEIC files tested, along with two jpg files also off the iPhone 15.
The remaining processing steps, including MIME-type validation, auto-orientation, JPEG output and resizing, were retained.
Activity
[-][Bug]: HEIC preview generation fails identified as JPEG[/-][+][Bug]: HEIC preview generation fails when identified as JPEG[/+]invario commentedon Oct 12, 2026
This sounds to me like it may be because your HEIC files have embedded JPEG data which is intended for apps to use as the preview instead of having to decompress the HEVC compressed image to generate a preview. ImageMagick will only process one set of data in the HEIC container so it appears to be grabbing the JPEG data instead of the actual HEVC data.
ImageMagick/ImageMagick#1391
Perhaps a fix should (instead) be to specify
[0]for the image and continue to forceimage/heic.Edit: Sorry, I wrote that when I was tired. Had another look at it and see it already uses
[0]. Apparently, forcing/overriding it causes instant failure before the[0]even has a chance to be evaluated.I think forcing it with
heicwas done to mitigate some sort of vulnerability though...aftertaf commentedon Oct 26, 2026
I have the same issue.
Heic extension but imagemagick sees as jpeg - result is no preview.
preview generator V 5.15.0 and Nextcloud 35.0.2, on Debian 13.
RichardPillay commentedon Oct 26, 2026
Forcing it to be treated as heic is not an issue, I don't think. It's probably the right thing to do. Heic is just a container, not a format. Jpeg is a format - so it says that the file content can be decoded in a certain manner. Heic, though is a container - meaning "this is a file which contains images and or video. Before you know how to read them, you have to read the metadata" This is where the problem lies, I believe. ImageMagick is doing this properly. But when we have the issue, what is happening is probably that Nextcloud is reading the metadata, seeing that it contains a jpg (which may be just one of many images inside the heic), then telling ImageMagick to process the heic file as a jpg.
invario commentedon Oct 26, 2026
Do you have a sample problematic image you can share? I'd like to look at this a bit more.
RichardPillay commentedon Oct 26, 2026
Try this one. It's not the original file I used in testing the issue, but it doesn't have any people in it. Let me know if it doesn't show the issue. We've had a few versions of nextcloud since the issue was raised. I'll go back to the iPhone (it's someone else's, not mine) and try the test again. I'll post if the problem has since been solved (or even if it's no longer an issue)
IMG_9226.zip
invario commentedon Oct 26, 2026
Also, there's been some change between 34 and 35, notably they moved code from
HEIC.phpinto a separateHEIF.phpand added a methodformatHintthat is used for the image type but in this case, it's still forced toHEIC.I've been reading up on this a bit and here's what Gemini is spitting back at me.
Which is why in my previous reply, I said that I think it's not able to read from the HEVC data contained in
[0]... It fails before even getting to the[0].Thanks for the sample image, I'm going to play around with it!
invario commentedon Oct 26, 2026
I ran your file through
magick identifyas well asexiftoolandffprobe. It's not an HEIC at all by all accounts. It's entirely a JPEG file with an extension of HEIC. This really makes me wonder how that came to pass being that the file came directly from the iPhone 15. An actual HEIC file's first few bytes would look like this:Contrasted to the file you gave me which is a JPEG
RichardPillay commentedon Oct 27, 2026
What I do know about the iPhone is that it's a moving target. Apple is notorious for changing things without notification. But HEIC is merely a container and what is inside could be anything, which in this particular case, is merely a collection of jpg images. The iPhone in later years started taking a series of shots, marking one as the preview, and showing all of them in succession if you hold your finger on the image. This is entirely dependent on what this particular owner's settings are.
invario commentedon Oct 27, 2026
Yes I understand that HEIC is a container. But your file is definitely not an HEIC. It is merely a JPEG with the wrong file extension on it. The first few bytes (the magicbytes https://en.wikipedia.org/wiki/List_of_file_signatures) show you exactly what the file type is.
invario commentedon Oct 27, 2026
ffprobe from an actual HEIC off my samsung GS25+ with motion photo/video embedded
ffprobe from your file:
edit:
https://heic.fyi/samples/thumbnail-embedded.heic
Here is an actual HEIC file (container) with an embedded thumbnail (albeit the thumbnail is in HEVC format).
Output from ffprobe:
Note the multiple streams.
aftertaf commentedon Oct 27, 2026
aftertaf commentedon Oct 27, 2026
2 photos.
1 with 'live' mode and one not.
exported unmodified originals AND saved to phone ( 2 different iOS options).
the zip contains the results of both actions.
trying to attach zip now...😁
aftertaf commentedon Oct 27, 2026
https://norishare.com/sQpS7G7sEda
link to my zip..
invario commentedon Oct 27, 2026
Thanks. I got your samples. Yours are indeed HEIC files, but they contain regular HEVC encoded image data (not JPEG data.)
Additionally, your sample files generated preview files just fine when uploaded into my NC34.
aftertaf commentedon Oct 27, 2026