Canon EOS-1D X Mark III captures stills in HEIF format

Canon just announced EOS-1D X Mark III with the ability to capture stills in HEIF format:

“The development of EOS-1D X Mark III is a clear example of Canon’s commitment to pushing the boundaries of innovative imaging products featuring optically excellent technology. The camera will support an all new, Canon-developed, CMOS sensor and DIGIC processor, that will deliver greater image quality, at even higher ISOs, with the ability to capture stills in 10-bit using the HEIF (High Efficiency Image File) file format. HEIF produces wider dynamic range and greater color representation compared to JPEG. The power of 4K resolution brings stories to life – shoot 4K videos including 4K60p with 10-bit 4:2:2 Canon Log internal recording.”

How is the HEIF support in opensource software atm?
This move by canon could potentially be followed by others and render jpg obsolete in a few years.

I’m no expert on this, but the following may be interesting:

HEIF is a container format, so it is partially up to canon and depends on their specific implementation. If it is anything like CR3, it will be difficult.

The format is truly amazing,

I exported this 38,3kB .heic HEIF image as a jpg with quality set to 100%.
The jpg file ended up being 758,1kB large.

The heic image I used:
https://nokiatech.github.io/heif/content/quality_comp_candidate1/compare_still_1.heic

There still lacks integration features in linux. For example there are no thumbnails in Nautilus for heif images.

The support for HEIF is OK, but not perfect.
Pro:

  • There is libheif that makes it quite easy for application developers to add HEIF support.
    https://github.com/strukturag/libheif/
  • Gimp is able to load and save it.
  • DigiKam has HEIF support.

Contra:

  • libheif is missing some important features like images with an odd height or wight. Support for images saler then 128px
  • exiv2 desn’t support it(The coding has started, I expect it in one of the next releases.)
  • that means no exif support in gimp anf digiKam
  • The compression algorithms H.265/HEVC is full with patents
  • The alternative compression algorithm AV1 is free to use but very new and still not very good supported in software

@KristijanZic

  1. Comparing HEIF with to a JPEG with quality set to 100 is not fair, because that is the worst case scenario foe a JPEG. But still usually a HEIF file is half the sice of a JPEG.
  2. libheif includes a thumbnailer for Gnome/Nautilus
    https://github.com/strukturag/libheif/tree/master/gnome
1 Like

problem for distros could be that the codec used within HEIF is often h265.

Sure, we will continue to see new file formats and containers, but no, JPEG is here to stay.

1 Like

I’m guessing they will, for THIS implementation, choose something that closely matches what Apple uses in a “typical” configuration and not use a nonstandard codec. Doing so for their non-RAW formats would be industry suicide.

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! :wink:

2 Likes

Love the comic relief Christmas cat @patdavid.

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. :frowning:

$ 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?

2 Likes

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? :smiley: )

1 Like

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.

1 Like

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.

1 Like