It is but as a legacy format.
Storage is expensive so jpg will live on in the old websites and todays cameras.
You just need a service like Facebook, Twitter or Instagram to switch to HEIF and that’s it, everybody will follow in their footsteps.
I’m guessing there are edge cases or old browsers that are still keeping them on jpg and gif but as soon as they switch to heic they’ll probably save millions or billions over night.
I’ve seen some reports that careful pixel-peeping may show that the format does not look quite as good as its JPEG counterpart. I’ve heard that shadow detail suffers a bit in HEIF.
I looked at it briefly a year or two ago for my video compression. x265 claimed some tremendous space savings compared to x264, but looking carefully at the details in a few different places things weren’t quite apples-to-apples. (shadow details there would get smeared a bit and lost).
On that note, I’ve actually started looking at this again a bit because I use an iPhone, and the newest iterations can use HEIF for their images (and HEIC/x265 for video). The problem for me personally has been support in linux generally (I usually have to convert to jpg (or pnm) temporarily to view things over a terminal like I tend to do using sixel).
Example of my use-case in my terminal:
I’d love to see some more careful investigations into quality/size tradeoffs though! Who’s up for writing an article! 
The 1DX3’s HEIF files will be 10-bit, so I would expect them to perform well in the shadows.
Are the iPhone files 10-bit?
I just checked and according to exiftool it’s 8-bit HEIC from an iPhone Xr. 
$ exiftool "2019-05-20 1616 0083.heic" | grep Depth
Image Pixel Depth : 8 8 8
I’ve got a raw file I’ll post (maybe in another topic) that we can play with to generate JPEG and HEIC to compare a little.
comparing codecs is really tough as fine tuning codec parameters can be decisive here and an exhaustive search for best apples to apples comparison takes time and knowledge. On top of that is the problem of the visual quality metric that’s being used. PSNR, SSIM YUV or SSIM RGB, VMAF?
IMHO for single images, even an x264-stillimage version would have significant space saving benefits. I’ll take x265 for the same quality, but I am looking very much for what AV1 could bring.
It’s a bit surprising that apple actually puts 8bit images into HEIC. Their colormanaged HDR phonescreens could really benefit from more. What happens if you take an socalled HDR pic? Does that change bitdepth?
Yep, absolutely. I’m not sure what parameters they might use.
I figured some mild pixel-peeping would at least give a general sense of what the result might be doing. Less scientific of an approach, but hopefully can provide a feeling for what it might practically produce (using something like libheif/heif-enc on my box).
Good question! I hadn’t thought to try that yet.
Hmm. Just did one and even as an HDR the image still shows the same bit-depth (8).
Apple is a just enough kind of company, so I am not surprised that they limited it to 8-bit. Someone could probably hack the phone to get 10-bit or more.
From what I have read, and maybe my memory is rusty, 265 is worse than 264 in some aspects[1], but the compression is much better; and so, for a given compression, it performs better than its predecessor. In other words, the devil is in the details.
Edit [1] At least at baseline.
That’s almost disappointing!
Looking forward to creating a 10bit rec2020 PQ’gamma’ HEIF and supplying it to an iPhone and seeing what actually happens.
(Neither do I own an iPhone nor do I know how to encode a RAW into PQ like gamma, but hey, it can’t be that complicated right? 
)
You can get close by:
Save to Rec2020 linear TIFF (darktable can do this easily, I need to dig into how to do it in RT)
Encode that linear TIFF to a 30-second 10-bit H.265 stream with an HLG transfer curve and appropriate HLG metadata.
Doing so looks AMAZING on an HDR-capable display. But encoding stills to 30-second videos (which compress well since the predicted frames all say “no change”) is a really horrible way to deliver stills to an HDR display - but since most HDR TVs don’t support HEIF there’s no other way to display stills on an HDR display and have them trigger HDR mode.
This weekend I’ll try and dig up one of my old example ffmpeg command lines from last year, they’re on my old laptop and I haven’t transferred a lot of documents over.
They could switch to WebP (especially all the Google subsidiaries like YT) and they haven’t done so yet…
That’s the first time I’ve ever seen someone use sixel graphics.
Example of my use-case in my terminal:
Is the lsix that you use is this one?
If yes, then it uses ImageMagick to convert to sixel. ImageMagick supports HEIC:
Theoretical you should be able to view HEIF files with lsix. If not you should write a bugreport.
Yep, that’s the one I’m using (modified slightly for my own personal stuff), but looks like I’m back on version 1.4 from June 2017.
I’ll have to check again with viewing HEIC through sixel and see if it’s working now.
Pat, what terminal do you use? It’s disappointing that so few of them support sixel graphics.
I’m on Windows during the day, so I’m usually in Cygwin using mintty (which has sixel support built in).
It’s actually something I miss on my linux boxes. gnome-terminal/vte doesn’t have it, but I did see a couple of experimental forks that seem to include it (haven’t had a chance to test it yet).
I think kitty and mlterm both have sixel support though.
Oh, no wonder I didn’t recognize it. Mlterm and xterm support sixel, but kitty doesn’t – they decided to develop their own standard for images in the terminal.
Ah, that’s right - I remember now running into this. Thanks!
I’m currently adding HEIF / HEIC support to Rapid Photo Downloader. The 1D X Mark III produces HEIF files when it is in HDR mode. When the camera is in HDR mode, it also affects the CR3 files. The resulting HEIF and CR3 images are described in p. 223 of the EOS-1D X Mark II manual:
HDR PQ Settings
PQ in HDR PQ refers to the gamma curve of the input signal for displaying HDR images. HDR PQ settings enable the camera to produce HDR images conforming to the PQ specification defined in ITU-R BT.2100 and SMPTE ST.2084 (with actual display depending on monitor performance). Shots are captured as HEIF or RAW images.
- HDR stands for High Dynamic Range.
- PQ stands for Perceptual Quantization.
A challenge is handling the preview images embedded in the CR3. We can no longer simply extract a jpg like we can for most other RAW files. According to Phil Harvey, “The embedded preview in these CR3 files are not JPG format. They are instead basically HEIF format without the file header.”
Currently no FOSS tool handles or even recognizes these embedded preview files. I’ve opened an issue on libheif — let’s see what Dirk thinks of it.
I’m not aware of any FOSS tool that is able to extract the preview images from the 1D X Mark III HEIF files, including the latest release of ExifTool 11.88. Hopefully Phil can remedy this.
@patdavid are you happy to share a sample iPhone HEIC image with me for testing? I currently lack one of those, and unless I’m doing something wrong (or it doesn’t belong there), I couldn’t find one on https://raw.pixls.us/
Late to the party but do you know if this is the only workaround to get HDR still content working on HDR compatible displays? That really blows if that’s the only way