I know that there is some kind of licencing involved but saving space and making ourselves future proof, what is the general opinion?
I am no apple fanboy and I don’t see me using a closed-source format (what an idea …)
Apple is not controlling this technology but they are the first to implement it and I would not close my eyes to it just because it is used by apple.
I would request you to view the video with an open mind.
HEIC is not a closed system but it is patent encumbered. (It uses technology from HEVC)
I think we’ll see HEIC, JPEG-XS and efforts from the Alliance for Open Media coming in to product, which one wins will probably depend on which is highest up the list in Photoshop.
Didn’t know I was spending $760 for memory cards and HEIC would bring down my costs to $360. But I still miss ‘thousands’ of dollars.
This would be relevant when someone shoots several millions of photos, but nobody does that.
But even if you shoot that amount you still only need a few memory cards you would save them on a harddrive.
A 4TB harddrive currently costs around 100€. Lets assume those are 4,000,000 Megabytes for simplified calculation. Assuming a JPG filesize is around 4MB you could store one million pictures on that drive.
With HEIC you could save two million photos, saving you 50€.
But in reality you don’t come to these numbers. In my case my photo archive takes 7.2GB disk space, all JPG files. This tiny amount does not even come into consideration when I need to buy a new harddrive.
A JPG to HEIC conversion could reduce that size to 3.6GB. So?
If my harddrive gets full there would be other reasons than a few gigabytes for photos.
It’s true that HEIC has superior technology than JPG. But then there’s this licencing issue. That keeps many developers from implementing HEIC support.
Darktable already has two lossless export formats with PNG and TIFF, you can always convert them to whatever format you want with many different image converters.
Therefore I would rather put programming efforts into features that improve darktable’s photography workflow instead of implementing new export formats.
The next Canon high end camera will write HEIF files as well. we already got preliminary support using libheif working. but shipping that support can be tricky for linux distributions because of the patent fun.
I think this whole thousands of dollars thing is the whole cloud storage push by Adobe and other companies. At home physical storage is cheap. I don’t have many photos yet but I personally have a 1 TB working drive. This is a Evo 860 hooked to a USB c adapter. Then I back them up to a external 3TB spinning USB 3 drive which stays in a fire proof safe. I also keep the photographs on the memory cards. A pain for off loading but it gives me 3 locations.
I got my own cloud storage using Nextcloud on my webserver with 500GB storage. The biggest part is the 175GB RAW archive.
Offline I got all my files (around 800GB) synchronised between two computers in my home.
But I wouldn’t convert my RAW or JPG files to another format, even if it would need less space and conversion would be losless. Would had to convert all new files from my camera and I think would not be worth the effort.
If that 500GB someday will not be enough I’ll just order an upgrade to 1TB.
There are several ‘successors’ of JPG, for example JPEG2000, JPEG-XL, HEIF, WebP or AV1 which compete to be the so-called ‘standard’ (meant as market domination) that replaces JPG.
Currently supporting one of these alternatives would mean supporting this war and taking side for those competitors which formats darktable would support.
If there’s any potential benefit to HEIF, it’s the ability to store higher bit depths (in theory).
In practice, it seems like all HEIF implementations are still only saving 8 bits/color?
A stills format that could trigger HDR mode of a modern HDR display (10 bits/color with PQ transfer curve or HLG) would be amazing - but I’ve seen almost no examples of this implemented anywhere.
I am not an expert but I suppose this HEIC format has “similar” patent problems as the jpeg2000 format .
When jpeg2000 was proposed it looked like a very interesting alternative to the jpeg format but in the end it was never able to really take its place…
Considering there is only one Canon camera reflex which might be able to produce this format I suppose it will take many years before other brands (Nikon, Sony etc) allow the same option on all their cameras.
Perhaps, in the meantine, some new format, non-patented flawed, might arise to take its place
I guess this was the idea behind Panasonic’s HSP format launched w/ S1/S1R, but it would be nicer indeed to have something not vendor specific.
As unideal as the patent situation is for open source people like us, I don’t think the H.265 patent issues with HEIC will be of any significant impediment to its adoption, since nearly every camera that is saving HEIC stills is also capable of H.265 video - they’ve already paid the licensing fee.
H.264/H.265 licensing fees are pretty much insignificant for any camera manufacturer shipping any reasonable amount of volume - $0.10-0.20 USD per unit shipped, which for them is well worth being able to advertise what is considered a critical feature.
But it makes things a massive hassle for us open source types.
There will always be new formats, patents and specs, remixes of them, and the so-called wars among them. In the end, the ones that triumph are the ones that every grandparent and pet will use unknowingly. Ubiquity and good enough is enough for most of the world’s population, and magical for those who are in poverty or lack opportunity in life. JPEG is here is stay for this reason.
Hopefully manufacturers move on from HEIF quickly and look to adopt AVIF. It supports the modern features like superior compression, greater colour bit depth etc, and is actively working to remain royalty free. The video version seems to be getting adoption among the main content providers so that helps.
In that image format debate, you can also have a look at what are the competing formats that are supported by web browsers.
WIth that point of view, jpeg is avaialble everywhere, webp almost everywhere (only safari is missing), avif implementation is in progress at least by chrome and firefox…
And for heic (heif container + hevc codec) ? no support, and the chrome developers even close the bug as won’t fix.
I have the feeling you should bet on another export format
The issue is that current file formats require a value of gamma, or an ICC profile to describe the transfer functions.
It may require ICCmax to correctly describe the curves, so there’s a wait for implementation.
And the extra fun challenge may be that even after properly describing the curves, many displays will have no idea which profiles should trigger HDR modes. (Which is already problematic for video - for example, almost any non-Sony TV will ignore ATC metadata in HLG video if the video is 8 bits/color instead of 10.) At least beyond that, PQ and HLG are standardized enough by SMPTE that videos don’t store the transfer curve itself - they just store a numeric identifier indicating which of the SMPTE standard curves are in use. (e.g. an ATC of 18 in the SEI metadata indicates an HLG video, and the color primaries that are standardized are also enumerated references to the standard instead of fully described.)
SEI being a feature of H.264 and H.265 so not available for still images.
Panasonic have a proprietary HDR image format (based on HLG) so it should be possible to do, if an ICC profile is defined (and time is given for interoperability to be established).
Do you have an example image of Panasonics property files?
Yup, and that’s a big part of the problem.
Interesting. I really wish there were SOME standard for stills content delivery of PQ or HLG images, but it seems like nearly anything that displays stills won’t trigger the HDR modes of any HDR-capable display.