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 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).
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, 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.
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.