Canon CR3 raw support - your move

Just a note - I offered to sponsor (at least EU based in PL) legal advice concerning this and got reply from law advisor that doing CR3 reader in Exiv2 is totally OK thing to do judging from materials he read, however full legal clearance (that covers EU) would cost probably ~1k EUR or a bit more (at least from my legal advisor).

I see 2 ways which would cost absolutely nothing in legal fees for open source devs but are still very skittish about “hurr durr legal”:

  1. Canon releases NON-NDA specification for CR3 reading and just reading. It’s totally fine for us and gives full clearance to create CR3 readers. This is the OPTIMAL solution.
  2. Canon releases statement granting all open source software to either create or use already created open source reader for CR3 files and takes no responsibility for any open source reader and never guarantees any operability/feasibility etc of open source CR3 reader. That’s equivalent of Canon legally saying “Do your own CR3 reader, we don’t care”. That’s sub optimal because it requires loads of guesswork (that is mainly already done).

Any such statement would officially shut naysayers the hell up and be fine AF for my taste.

If no such document/statement comes from Canon I suggest devs (if possible) to use Robin’s book (or other people’s work as a base) and do PR to Exiv2 after getting a legal advice from legal advisor (check your location, some legal advisors offer discounts for open source devs!) and add legal notice to your PR that you sought legal advice and quote the legal advisor’s response :slight_smile: If I’d have time to do so that’s what I’d do :slight_smile:

I don’t think I can paste a photo of Lizzie here. She’s in the photo on page 2 of the book. Please have a little read at the prolog to chapter 13 in my book. You may be surprised to hear what goes on when you maintain an open-source project. IMaEA

My son is a IT Development Manager and delivered the review “That’s not what Project Management is about.”. However he didn’t explain what it is about. One of my Adobe buddies said: "Your son read that chapter from the view of a project manager or delivery manager. But it was written by an author of software. I wish, both sides would understand each other better. ". I asked “What is a delivery manager” and he didn’t reply either.

So, there we have it. After 12 years and at least 12,000 hours of effort, it’s time for me to finish the book and retire. There have been some fun times along the road. We enjoyed Tuan’s and Alice’s wedding in Vietnam in 2017. Tuan was a GSoC student in 2012. And I hope to give a talk about the book at LGM in Rennes in 2021. If somebody in the community will takes on the maintenance of Exiv2, they can be 100% certain of my support and cooperation.


Was hoping for more but the weather is nice so I will go outside. :cat2:

1 Like

@clanmills From the time we met on LGM London I still have your business card in my wallet. It will stay there forever :+1: for your foss work


Also very very sorry to hear that. This is not what the open source world was meant to be.

Luckily my open source project is less popular and needed…

Sounds attractive when I retire at 70 in 10 years time :grinning:

In the meantime let me buy you a beer in a pub any time soon now - if it is up to me.

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.