Hi, New user here.
An as also asked on the RawTherapee section, Is there any foreseen update to support High Efficiency RAW file reads for Nikon Z series?
As that âHigh Efficiency RAWâ seems to be a proprietary format, I wouldnât hold my breath waiting for open source support⌠(InfoPIX even mentions patentsâŚ)
2 Likes
1 Like
I am generally reluctant to use any compressed RAW file format as many softwares, especially FOSS are unable or slow to support this. Memory cards are pretty cheap now so the benefits of compression are probably not worth it in my humble view. A DNG convertor for the files would be a solution for existing images, but personally in the future I would recommend trying normal RAW files.
3 Likes
Depends on what you do. For wildlife Iâm using craw as the buffer clears up much faster.
1 Like
âHigh Efficiency RAWâ is a patented format. Therefore, no FOSS raw processor will support it.
However, you can use the Adobe DNG converter to convert these RAW files to DNG format, which can then be handled by a FOSS RAW processor.
Nonsense. H264 is a patented format, yet it is widely supported. H265 is a patented format, yet it is widely supported. Apple ProRes is a patented format, yet it is widely supported. Indeed, I suspect if you look hard enough youâll find patents which cover many of the existing compressed raw formats from most manufacturers.
The difference between many of these formats and the TicoRAW format (which is who Nikon licensed the technology from) are (i) it is not an open standard; (ii) it is non-trivial; and (iii) there is no source-available reference implementation. Thus, it represents a more significant reverse engineering effort than prior formats.
Usually support for these things comes through clean-room reverse engineering where someone disassembles a freely available converter and uses this to write documentation for the format. Someone else then uses this documentation to put together an open source decoder.
The big accelerator here will be if a build of one of these applications happens to be shipped with debug symbols. Amazingly this happens a lot more often than one would expect. This makes the reverse engineering process a lot easier. Similarly, if one can find a GPU-decode enabled application floating around these are often a lot easier to reverse engineer.
Will it happen? Probably, although it may take a few years. If it is any constellation Iâll note that Apple does not currently support these compressed RAW files on their operating systems.
Regards, Freddie.
For the video codecs you mention there are provisions for non-commercial use.
And the compressed raw formats are not all that well supported (not just Nikonâs).
You can say that itâs non-sense that patents should stop FOSS from implementing the technologies, but I donât suppose youâd pay for the possibly resulting court cases? And it doesnât really matter if a patent is valid as far as FOSS is concerned, small dev teams just cannot afford the legal fees, so cannot take the risk (and why should they?)
Also keep in mind that reverse engineering protects you from claims of copyright infringement (if done properly), not from claims of breach of patents.
I am not an expert on legal matters but reading, displaying or decoding a file format should not infringe on copyrights. The only breach will be if you do any kind of writing on it or have financial gains from it. This is also in part why .xmp or other type of dependent file types existed in part so that any post-processing manipulation can exist without touching the original file data. Patents are entitled to the use of writing/coding such data format, not reading it.
On the other hand, copyright and patent infringement can only be litigable IF (Big IF) the software was distributed for profit, thus, open-source software (Unless has some paid branches or sections) should not be in any type of infringement for just reading a file type. So, I agree with Freddieâs point of view.
Do you have any citations on the non-commercial use aspect? For some codecs there are provisions for royalty-free distribution (say if youâre a video streaming service which makes content freely available) but encoding and decoding always requires a license.
I say itâs nonsense because those who preach concern about patents are almost always internally inconsistent in their outlook. Firstly, source code can not infringe patents, only products can. This is how ffmpeg is able to have support for 100âs of highly patented AV formats. Thus, as a developer of an open source project you have relatively little to worry about. Only those who distribute binaries need to be concerned (and when that concern is warranted such as when Fraunhofer was aggressively enforcing its right to MP3 encoding there are well established solutions such as those adopted by Audacity in the late 2000âs).
With this let me ask you a question. Do you have ffmpeg on your computer? If so, have you paid the relevant licensing fees or have documentation asserting that whoever you got the binary from has paid these fees?
As for the (other) compressed RAW formats not being well supported, I consider that claim highly dubious. Nikon has had lossy compressed RAW for years (in lower end cameras that was historically your only option). Sony has also had lossy compressed RAW for many years (with lossless compression being much newer). All of these formats are extremely well supported. Canon CR3 files have compression and, in 2025 at least, are quite well supported. (Interestingly, a lot of what we know about this format comes from reading Canonâs patents.) Fuji have compressed RAW files with the lossy compression being widespread and well supported.
For me this is not a problem. I have zero interest if theyâre patented or not. But for those who purport to be concerned it presents an interesting conundrum. How confident are you that the open source decoders of these formats do not infringe on any patents? Where/how do you justify the risk?
Regards, Freddie.
Freddie, I agree almost entirely with all your posts except that I need to clarify when you say âsource code can not infringe patentsâ. It can indeed if its demonstrated that was âExactlyâ copied or stolen in part or in hole from the original patent. How I know this? Because I patented my own application source code and it was granted. 
Would this fit the bill?
I think the precise legal situation isnât all that important, when developers feel thereâs a risk of a law suit. I donât think many can afford a patent infringement law suit (I know I couldnâtâŚ).
Decoding is different from encoding. The latter might be prohibited in some legislation. Decoding into an open format is a different thing. In some legislations patented stuff needs to be published. Thereâs no universal concept of patented secretsâŚ
So the real issue is the effort someone has to spend.
No, it doesnât fit the bill. OpenH264 is fully licensed; Cisco paid. From the article
[And] pay all royalties for its use to MPEG LA themselves for any software projects that use Ciscoâs precompiled binaries (thus making Ciscoâs OpenH264 binaries free to use);
In other words so long as you use Ciscoâs binaries youâre in good standing. But, compile it yourself or use another software decoder and youâre back to the usual quagmire. Indeed, the fact OpenH264 exists at all fully supports my contention that H264 is highly patented (even for software decode which some formats have an exception for).
Regards, Freddie.
Please do note that the HE Raw format is lossy so unless you really really need the extra frames per second or need to save storage space (???) youâre better served by the standard, lossless compressed NEF.
FWIW, see this and this. However, thereâs no way of knowing yet if this was through licensing or reverse engineering, and whether this will make it to e.g. LibRaw in a couple of years.
at least for canons cr3 just the encoding is patented - and same seems to be the case for Nikons high efficiency raw (even the patent holder isnât Nikon ). The patents doesnât describe the file format itself but the way encode the sensor reading into that format.
So as long as a third party doesnât create ânativeâ canon or Nikon raw files thereâs not that big risk for lawsuits just because of decoding it âŚ
I have never understood why the camera manufacturers like Nikon donât want to support the decoding of their RAW files by software designers including FOSS in order to sell their cameras and ensure the best editing of their images. I personally would not want to buy a camera that could not be decoded and processed in the editing software of my choosing.
1 Like
How many buyers of their cameras (even the top models) actually use the raw files?
And how many of those use programs like Lightroom or photoshop, where the software vendor is willing to pay and sign NDAs for access to the necessary specifications?
FOSS users are still a minority as far as camera producers are concernedâŚ
(If I wanted to be very cynical I could even postulate that itâs in the camera makers interest to hide as many details as they can, to be paid by software makers, who then let the users payâŚ)
1 Like