Canon CR3 raw support - your move

I’m sorry to hear there’s so much difficulty with implementing CR3 into Darktable. Frankly, I would have expected Canon to be more supportive given that holding off could dampen sales. I shoot Canon and might migrate toward mirrorless at some point, and incompatibility with Darktable might lead me to a different company.

Any rate, I did follow the OP advice and reached out to Canon, who sent me the following response:

Thank you for contacting Canon product support. I understand you are inquiring if Canon will provide the CR3 format specifications to the developers of the Darktable application. My name is Jacob and I’d be happy to address your inquiry today.

Unfortunately, Canon does not provide the CR3 format specifications to application developers. Developers, like Adobe, will update their software after studying and reviewing the CR3 file format. You would need to reach out to the developers of Darktable for further assistance. I do apologize for the inconvenience.

Please let us know if we can be of any further assistance.

Have a great day.

Thank you for choosing Canon.


Technical Support Representative

This may be helpful or not, but I’m just offering this as a data point from a DT user and it would seem the question is moot at this point, anyway

Thank you to all the developers for all of your work. Your effort is greatly appreciated even if it may not seem that way at times.

Dave G.

If that’s true, it sounds like they have no problems with reverse-engineering of the raws… otherwise they’d have sued the pants off Adobe and other software companies.

On the other hand, that’s no guarantee that they won’t.

1 Like

I’m not sure the response of a technical support representative counts as a legally binding, but this is a very clear indication that reverse-engineering is definitely allowed.

I certainly wouldn’t take this a their legal position, it strikes me a very passive position to take. It’s really a disservice to Canon’s customers as well as the company itself.

The response is descriptive rather than prescriptive or normative. It is definitely not legal language and is as generic and polite as can be. There is nothing to read into.

For fun, I will break it down a bit, at least the part that may say something.

Unfortunately, Canon does not provide the CR3 format specifications to application developers.

Doesn’t mean that it won’t for other purposes or make exceptions; i.e. data chunks of their flagship cameras.

Developers, like Adobe, will update their software after studying and reviewing the CR3 file format.

That is their business to do so. Doesn’t mean that reverse engineering is permissible and that legal action won’t be pursued.

You would need to reach out to the developers of Darktable for further assistance. I do apologize for the inconvenience.

Look somewhere else but they aren’t responsible for your and any devs’ actions.

With the usual IANAL disclaimer, but I have to wonder: has the author of dcraw (and/or libraw, or rawspeed) ever been threatened by any camera company? Why would CR3 be different than the other formats?


[quote=“CarVac, post:62, topic:14192”]
If that’s true, it sounds like they have no problems with reverse-engineering of the raws… otherwise they’d have sued the pants off Adobe and… [/quote]

And I’d have to wonder why they would. Does Canon have an interest in excluding its latest camera lines using the DIGIC 8 processor from any photo editor… except for its own DPP software that’s offered for free to Canon customers?

Very true.

Was the CR2 format not subject to these restrictions?

@afre You’re right about the wording of the message. They are ‘empty’ words in a sense.

Yes? Reverse engineering software is often explicitly prohibited in terms of use. Canon can choose to protect their intellectual property for whatever reason they want. Even after years and years when something seemingly has no commercial value anymore, a company can claim their rights and send cease and desist letters your way.
I don’t know how things are if reverse engineering is not explicitly forbidden in the purchase agreement you make when buying a Canon camera that makes CR3 files.

That assumes reverse engineering is necessary. I don’t know, but the thread above indicates that it’s not.

I think the concern is more around the patents relating to the HEIF format and the CRX compression that are being used in CR3 files, rather than “reverse engineering” per se. In my view, if I have to pay a patent holder a fee to be able to open files taken by a camera I already paid for, then maybe that camera is not the right choice for me.


Some use DNGs as their format and so are more transparent.

Reverse engineering is what each and every camera’s raw format requires by FOSS developers, CR3 is not new in that regard. I know of no court decisions or law that has encumbered that sort of endeavor.

Copyrights are about the specific written word and its rights of use by others. For a camera manufacturer to copyright every raw file that the camera issues would be bad for business, as no sane professional photographer would buy and use one. APIs have a bit of an ambiguous situation after the Oracle/Google thing regardin the Java APIs; in that regard, doing reverse engineering of something you don’t know might be better than encumbering your freedom by agreeing to stipulations of use for an API.

Patents are another matter, but in that case the invention is publicly disclosed. Image formats have been encumbered thusly, and this may be a problem with the recently encumbered encodings as the video (oh, and gif) crowd has endured. Regarding the raw format itself, I would hope that there’d be no patent examiner that would pass a patent for an array of 16-bit unsigned integer numbers representing ADC measurements, but well, I could be wrong there :smiley: But, if HEIF is encumbered by one or more patents, if it isn’t decoded there shouldn’t be a problem…

Disclaimer: I have been involved in patent application and dispute, and peripherally involved in an alleged copyright dispute, so I know just enough to be quite dangerous…


I don’t believe I have reversed engineered anything.

I obtained the JP2000 Specification w15177 which is available from here. Text of ISO/IEC 14496-12 5th edition | MPEG

The standard is a tough 246 page read. It defines how information is encoded in the file. Exiv2 is interested in Exif, ICC, XMP, IPTC data and this is in the ‘meta’ box (which is a tree of other boxes). It’s all well defined. The encoding of the “raw” metadata is specified by the metadata standard (Exif is a Tiff, XMP is XML, ICC is Profile, and IPTC is binary structure. The JPEG2000 standard defines many boxes that I don’t understand and thank goodness don’t need to understand because a box contains a length field, so code can seek past boxes it does not understand.

The standard also provides a box ‘mdat’ (media data) which should be considered the end-of-file. However it’s usually about 99% of file and undocumented in the standard (other that to say it exists). It’s a huge blob of binary data, and I assume, that’s where Apple store their HEIF H.264 encoded data. Canon presumably use their proprietary compression magic to store their pixels.

The ISO Standard disclaims itself from legal responsibility with this statement. “Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.”.

In my book I have provided code to read the metadata from those files and documented how the code works. I will add the disclaimer from the ISO Standard to my book.

I don’t believe reading Exif, ICC, XMP and IPTC metadata from a JPEG2000 encoded file is illegal. The people who have opposed my code being added to Exiv2 did not explain or justify their objection. However, in my respect for them, I have not added my code to Exiv2.

I’m looking forward to finishing the book by the end of 2020. My wife is looking forward to sharing more of my time. If LGM happens in Rennes, I will offer to give a talk about the book and to conduct an afternoon workshop on the mysteries of metadata.

Many people in the open source community are friendly, helpful and nice. I hope to meet you at LGM.

I will retire after the book is finished. When I retired from Adobe in 2014, I considered doing a PhD. Instead, I’ve put about 7 years of solid effort into Exiv2. The book is my thesis. The presentation at LGM/Rennes will be my defence. It’ll be a pity if LGM doesn’t happen in 2021.

The future of Exiv2 and open-source metadata support is a matter for the community. I’ve done my best. If anybody takes on maintenance of Exiv2, or writes a new metadata library, I will support, encourage and cooperate. Looking forward to seeing everybody in Rennes.


Yes, I feel like this conversation has gone in a loop.

The question we need answered is, “what will it take for the current maintainer of exiv2 to merge in support for the new stuff discussed here?”

Whether it is patent infringement or not, what code infringes on intellectual property or not, and what everyone believes is secondary to getting the code in exiv2. D4N on github hasn’t explained his position, which I’d guess would be the next stepping stone: engaging in constructive dialog with the current exiv2 team, sans @clanmills, who has already done as much as humanly possible.


I was thinking more of the rawspeed/libraw endeavors…

Technically you left out 0: Canon just open-sources a reference implementation of the file decoder.

…What can I say? I’m an optimist. It’s absolutely what they should do, and almost certainly what they will never do. Despite the fact that enabling more users to read their files will inevitably sell more of their fantastically expensive cameras, and there is zero downside for them.

(Unless of course they have shady back-room commitments to companies like Adobe, where they’ve promised not to do that. Possible. Unlikely, I hope, but possible.)

I think this is very likely. Probably Adobe and other commercial software pay to have access to technical specification. In this case, Canon CAN’T disclose specs to people (open source developers) who don’t pay…

ARRGH. I didn’t even think of it that way. You’re right, there doesn’t even have to be any sort of explicit deal to keep the information sequestered. Merely an implied commitment because, if they are indeed charging companies for access to the details of their formats, those companies would reasonably expect the thing they’re paying would not be freely available, or what the hell were they paying for?

F----ING capitalism. :angry:

These twits need to take a page from companies like Nvidia. Their graphics hardware designs are so patent-armored, at this point it’s basically impossible to design any sort of computer circuit for processing numbers, lest you potentially run afoul of their flying-monkey army of patent lawyers.

The APIs, tools, and documentation needed to make use of that hardware? Not only are they NOT secretive when it comes to anything and everything you could possibly need in order to write software for their cards, they’re practically falling over themselves to give it all away to as many developers as humanly possible.

Because they know damn well that every download of their development tools could become another killer game or app that’ll sell thousands of units of their hardware simply by existing, and all of those free sales will barely have cost them a nickel.

More developers writing software for your hardware ==> more people wanting to use your hardware ==> more sales of your hardware. It’s hardly rocket science, nor does this rely on some subtle or complex market factor that takes a microeconomics course to grasp. It’s a straight frickin’ line.

Note that the problem here isn’t pay-to-play, but rather the Nondisclosure Agreement that one needs to sign before getting access to the specs. If you write code based on their spec and the code is open, then it is likely that you’ve disclosed information you agreed not to disclose, hence why nobody has done that.

1 Like