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

Software RawTherapee
9

I checked this, Andreas, and CR3 is present in the list in the RT build I refer to above. The images also load and show the embedded JPG from the camera as thumbnails, but when I load them to edit the image is white and says ‘Exif data not found’ or something like that in the corner. For now, I convert to DNG first suing Adobe DNG Converter to circumvent that problem.

Looking forward to a new dev build, @HIRAM! Thanks for your efforts, and let me know if I can help testing for future OSX versions of RT. Have been trying out some trial versions of commercial suppliers like Capture Pro recently, and it really makes me appreciate RT and its excellent tools in Lab space so much more!!

10

Still working on the build… just dealing with the XML parts’ arrangement which should be the last item before the thing will launch. Resolved my previous issues with building glib. The root cause happens to be problems or changes with Apple Xcode since 11.3.1, and now into 12.1 the issues are still annoying. The two accepted solutions are to downgrade Xcode or use the macosx-11.1 development kit. For me the downgrade would take more time, so I’ve been building on the Big Sur kit. The first build I generate should run in macos Big Sur 11.1.

1 Like
11

I checked my system, and I run Big Sur 11.1 and Xcode 12.3. Hope that will work the same as 12.1. I don’t experience those random crashes I reported before anymore with the RT 5.8.397 build on this system, btw. Looking forward to test the new build.

12

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

13

I disagree.

5 Likes
14

Please read this thread and others about CR3.

15

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
16

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
17

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.

18

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…

3 Likes
19

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.

20

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
21

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.

22

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.

23

We absolutely do though:

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

image
image1444×1174 361 KB

24

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
25

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
26

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.

27

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
28

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