Does Raw Therapee support Canon R5 CR3 files? If not, then when?

It is a shame that RT still doesn’t support a major camera release. I hope this can be addressed soon.

I disagree.

5 Likes

Please read this thread and others about CR3.

I have a question:

Are you THIS Nathan Myhrvold or do you simply share his name?

If you are not - well, someone who shares your name has a bit of a reputation for being a patent troll and people like him are why some of the exiv2 developers are extremely skittish about ISOBMFF metadata support. (There’s also the side issue of exiv2’s lead maintainer retiring and the whole project being in a bit of transition, but patent litigation fear has been a problem for some of the new maintenance team.)

If you are - then do you realize that some of your past actions have contributed to the atmosphere of fear that has caused delays in infrastructure critical to ISOBMFF support?

1 Like

I am the only Nathan Myhrvold I know of. I don’t think that anybody in the open source software movement has any reason to be afraid of me. My company has never asked open source software developers to pay a royalty, or to cease and desist, or anything of the sort. I am certainly not ashamed of what my company actually does - which is quite different than the hate and fear mongering that some profess.

I could defend myself on those grounds, but this is supposed to a forum for users of Raw Therapee. I am a used of RT. I have a new Canon R5, which is arguably their best camera yet, so yes I think it is a shame that there isn’t better support of the R5.

That deserves a professional reply, not an ad hominem attack.

However, you insinuate that patents are the reason that there is no R5 support in RT, so let’s deal with that.

Are you saying there is a specific Canon patent on the R5 raw format ? If so, then guess what, Canon owns it, not me!

You say it is my actions. So, tell, which action on my part causes large camera companies to file patents? I have news for you - they all do, and they do it for their own competitive reasons, not because of me!

Canon in particular has been making cameras, and filing patents, since 1937. A couple days ago they came out with this news release stating that they have been one of the top US patent holders for a long time.

Seriously, you think that is due to me? No, it is due to competition with Nikon, Sony, and more recently a host of Chinese companies. That’s why all of those companies file patents (including, more recently, Chinese companies.)

Is there really a Canon R5 raw format patent? Unless you find specific patents that cover decoding the format for the R5 then there is no rational reason to use that as a delay.

I rather doubt that there is a Canon patent like that. In part because it is very difficult to patent a file format because, guess what, it’s not novel.

BUT, let’s suppose that there was a Canon patent on the format, and that it was valid (both of which are highly unlikely).

EVEN SO, there is almost certainly no valid claim that Canon could make against somebody reading that format for the purpose of doing raw conversion. That is because patent law reasonably protects the users of the camera. If I am owner of a Canon R5 then Canon would be hard pressed to claim that it was damaged if I chose to use Raw Therapee, a free raw converter, rather than its own FREE raw converter. Where are the damages to Canon? A Canon camera owner is, under US patent law, implicitly granted the right to practice Canon patents to reasonably use the device. That certainly includes using a raw converter.

By extension, there would not be any valid claim against the people writing RT (or software libraries it uses.)

I am not an attorney, but whomever is claiming patents as a reason is (most likely) mistaken due to bad advice. Or alternatively it is a smokescreen / excuse rather than the real reason.

2 Likes

Well what would really help is that canon releases the specs of the fileformat. as reverse engineering all bits of it seems to be quite time intensive and not yet fully done.

as can be seen in the list here https://discuss.pixls.us/search?q=CR3

we even asked owners of affected cameras to mail canon to express the interest to them that the documentation would really help.

1 Like

Aren’t a lot of resources available in these parts to deal with such…

Patent enforcement isn’t exactly a science; more of a stick. About 20 years ago, I was writing model railroad control software. I posted my work for others to use, and I got a cease-and-desist letter from a company selling a similar product. They’d patented certain technologies that they asserted I copied. I reviewed the patents, and determined they’d essentially just patented the use of TCP in model railroad applications. Specious, to say the least. Thing was, I didn’t have the resources to fight it, so I took down my code.

You’re not dealing with well-resourced organizations here, just motley collections of programmers pushing to github. That they don’t understand patents as well as you would like is just an ancillary concern to folks more interested in the thresholds of dual-demosaic and such.

It would appear you might have the insight and means to help with RT’s bit of angst here. Roll up you sleeves and wallow in…

4 Likes

Blockquote
Well what would really help is that canon releases the specs of the fileformat. as reverse engineering all bits of it seems to be quite time intensive and not yet fully done.

OK, that sounds much closer to the real answer.

It is a little surprising to me that it is hard to to reverse engineer, given that (a) raw formats are almost always very simple, (b) it is probably based on the predecessor CR2 format which is understood by RT and lots of other software and (c) there is software like the Adobe DNG converter that opens and converts CR3 files extremely quickly.

Now, to be sure, I don’t personally understand CR2, and it is has been a few years since I used a debugger to step through a program.

But surely there are others out there do understand CR2, and who can operate a debugger.

Obviously it would be better if Canon formally published a spec, but they have doubtless convinced themselves that the secret format is some big strategic advantage for them. Which seems silly to me, but I doubt that a letter writing campaign by camera owners will sway them.

I presume that Adobe wrote their DNG converter from a Canon spec, so they do share it with some people. Or maybe Adobe just reversed engineered the format.

Without taking any stance on patent infringement and such, just for information:

  • there are different cr3 file formats (meaning, the container format is the same, but the data can be compressed in different ways)
  • libraw can decode some of them, and the relevant code was ported (ie. copied, as the license allows it) to RT and ART
  • the metadata handling in RT and ART is not done through libraw but through other libraries
  • neither the internal rtexif lib nor exiv2 support cr3 so RT lacks metadata support for the format
  • exiftool does support the format, and ART takes advantage of it
  • RT might also lack some other info (raw crop, black levels…) to properly render cr3 files from the R5: this info is model-specific so it’s not surprising that cr3 works for some cameras and not for others
  • ART has such info

TL;DR: ART supports the R5 just fine, as far as I know (except for some compressed options for which there is no open source decoder available yet)

1 Like

Thanks, that is a great post, which seems even closer to the truth. From that we learn that:

  1. The CR3 format has largely been reverse engineered already.

  2. Other open source programs already support the R5. The actual image data from the CR3 is available to RT.

  3. The part that RT seems not to have already from libraw is already supported by exiftool or in ART.

  4. So this just seems like the RT dev team has not chosen to put this in - while TL, DT, ART, exiftool have already done it.

So it is not lack of reverse engineering - the essential part has already been done!

It is not the case that the open source developer community can’t crack CR3 because they are cowering in fear of me. That is just made up nonsense.

Nor is there is any Canon patent, or indeed any other patent threat that is causing the delay.

The other open source teams have it figured out.


The post also mentions compression as not figured out yet. That is understandable - reverse engineering a compression algorithm is harder than a file format.

BUT, it’s not clear this needs to be done.

There is a compressed raw format that Canon introduced with the R series, and maybe even the R5. Personally, I don’t use it, nor do I think there is anybody who does at the moment, or ever will frankly.

Compressed RAW is lossy, so I think almost nobody who currently shoots RAW will want it.

If you are OK with lossy, then you already have JPEG.

So it is a weird middle ground. The only reason to use it would be that you don’t care about getting ultimate image quality, and currently shoot JPEG, but you want some RAW latitude with white balance and dynamic range beyond what a JPEG could get.

So my opinion is you don’t need to support Compressed RAW.

It is my understanding that one can sign an NDA to gain access to the details from Canon, but NDAs and open code don’t go together, and nobody is willing to sign the NDA. No idea what libraw did, they haven’t shared that.

There is an exiv2 meeting on Saturday to talk about writing the code to read the metadata.

We absolutely do though:

Like @paperdigits already suggested in the very first reply in this thread, it is only supported in the nightly builds.

And @nathanm, after a hopefully positive outcome for the exiv2 discussion on including CR3 metadata support, we can safely complete the transition to using exiv2 in RT as well. I hope that will become possible within a few months time.

2 Likes

When Exiv2 supports CR3 I can take some ugly CR3-only codepaths out of Filmulator, which skates by on the little bit of metadata that LibRaw provides.

1 Like

It is not that they are cowering in fear of you specifically. However, you contributed to an environment where some open source developers cower in fear of any patent holder.

I personally think the objections of some of the exiv2 maintainers are going overboard, because there’s evidence that the part of the MPEG-4 standard they would be required to implement to support CR3 metadata is NOT actually patented (AOM’s use of the MPEG-4 container format hints at this), but it’s understandable given the behavior of some intellectual property holders in the past why people would be gun-shy of any part of a standards set that is notorious for having patents leveraged against it. It does not help that at least two downstream distribution maintainers indicated that even the possibility of a patent threat would cause them serious issues. All of these combined with the current maintainer transition of exvi2 (Robin announced at least a year ago his intent to retire early this year as lead exiv2 maintainer, leading to an understandable reluctance to override the concerns of his potential replacements) have delayed ISOBMFF metadata support in exiv2.

Also, your assertion that “compressed RAW is lossy” is false. Lossless compression algorithms exist, and that was one of the big changes in CR3. It started using a lossless compression algorithm that appeared to be kinda-sorta similar to HEVC (HEVC does have lossless modes!) but also clearly not actually interoperable. It’s vastly different than the most well known Huffman-based lossless RAW compression methods out there such as DNG’s compression scheme.

Another contributing factor was the way in which the libraw open source project is run - it’s run in a manner similar to how Google runs AOSP, where massive amounts of development are done behind closed doors and it’s very difficult for external contributors to participate, which slowed everything down.

Let me try once more. This is not about you. It’s not about an inability to technically address the problem. it’s about not wanting to tangle with something 1) with which they aren’t fully cognizant of the implications and 2) don’t have the resources to handle if some aspect of their misunderstanding irritates someone holding an asserted right.

AFAIK the major holdup is in the exiv2 cabal; some developers are reticent to entangle themselves in patent foo. That they choose to act in that manner is Their choice, based on Their understanding of how these things work, imperfect as that might be. A constructive approach might be to help them better understand their position with respect to the specific CR3 encumberances so they can consider a forward path…

3 Likes

Please head here for discussion of this test build for Big Sur.

Here is what I take from the last several posts. They appear to be arguing:

  • It doesn’t matter whether the open source developers’ fears of patents are informed, nor even whether they are rational fears. We’re told that “some” developers out there are afraid, the poor dears.

  • It apparently doesn’t matter that Canon patents are part of a longstanding Canon policy. Which is also practiced by every other camera company in the world, and has for years.

  • It doesn’t matter that neither Entropy512, or ggbutcher or some others on the thread knew the actual facts about CR3 and R5 support. Rather than being hung up on patent fears, it turns out that every other open source project already supports it (and apparently RT does too in nightly builds.)

Why spoil a good sob session about patents with the pesky little fact that most of the reverse engineering had already been done?

And, while we’re at it, never mind that a portion of the problem according to several posters, is disagreement between open source groups, some of which seem to be as hierarchical and uncooperative as the departments in the movie Brazil.

Yup, none of those things matters. It’s still Nathan’s fault somehow (according to Entropy512 anyway).

Seriously?

Well, he’s entitled to his opinion, but if it were me I would be really embarrassed making arguments that poorly supported. And, if I accidentally made them, and somebody refuted them, I would really really feel embarrassed repeating them anyway.

But maybe that’s just another flaw of mine.

ggbutcher disagrees, and says it’s not me personally, but still I seem to be the proxy stand in for the nameless dread of patents, by developers who lack the resources to be informed or logical about the issue.

Anyway, I’m glad to hear that the nightly builds of RT have Canon R5 support. Thanks to the RT team, and people in other teams, who made it happen.

Well this thread has gone awry.

And as of today its been decided that ISOBMFF support should arrive with exiv2 in March, so that should open the door to CR3 support.

4 Likes