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

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