After iOS 11, Apple’s camera defaulted to the HEIC format, which reportedly significantly reduces photo size without compromising quality. You can check this in 设置-相机-格式, where “High Efficiency” refers to HEIC format and “Most Compatible” refers to the original JPEG format. For more details on HEIC, see here.
The issue this raises is that no web browsers currently support displaying HEIC images, making conversion a necessity.
I often drag or copy-paste photos directly from Apple’s Photos app into Craft. However, uploading such images to a personal blog won’t display them unless converted to a universal format like PNG or JPEG. Here, I chose to use the Sharp library for conversion, opting for WebP (since HEIC-to-PNG results in excessively large files).
Converting common formats like JPEG to PNG is straightforward, but HEIC poses challenges because Sharp relies on a platform-native tool called libvips:
Without this tool globally installed locally, processing HEIC images will trigger the following error:
1 | |
It states that HEIC files cannot be processed.
The first step in troubleshooting is checking the official repository’s issues, where I found similar problems:
Following the advice, I installed libvips using homebrew:
This process takes a while, with logs appearing continuously. Wait patiently for completion without errors.
Confidently reinstalling Sharp npm install sharp, I hoped to see this message:
1 | |
This indicates Sharp’s installation script detected the locally installed libvips. However, upon reinstalling Sharp, it still used cached files:
1 | |
After deleting the cached directory rm -rf /Users/x/.npm/_libvips/ mentioned in the logs and retrying, the system version of libvips still wasn’t utilized:
1 | |
I decided to debug the package.
Starting with the logs, I searched for version-checking keywords like Using cached in the node_modules/sharp package, finding relevant code in sharp/install/libvips.js:
1 | |
Further investigation revealed a function determining whether to use the system’s built-in libvips or its own pre-compiled binary (which lacks HEIC support):
1 | |
This was the crux. Debugging showed that the check for isRosetta returned true. If it returned false, the system’s libvips would be used instead:
A peculiar observation during debugging: process.arch output x64, while logging this code showed sysctl.proc_translated: 1:
Yet, executing the same code directly in the console output sysctl.proc_translated: 0:
Here I concluded that it must be a Node version issue causing it to use its own compiled libvips. So I used nvm to switch the default Node version to the arm64 version, then ran npm i sharp again, and the problem was resolved.
Below is the code that might be used in this process:
1 | |
Later, I submitted a PR to the author to modify the isRosetta logic:
However, the author explained that there was a reason for the function’s current implementation. So I suggested that they add a warning during Sharp installation to inform users why the globally installed libvips package wasn’t being used. Eventually, the author accepted my suggestion:
From the author:
I often wish that when facing some key decisions in life, someone could tell me the best course of action so that I would not waste my precious time. Putting myself in others' shoes, I therefore write blogs often, hoping to record in this tiny corner of the vast Internet the once-in-a-lifetime experiences that matter to me, and to help those who seek help.
