CR3 files have been out for a while with Canon R. More recently the R5 and R6 came out and Raw Therapee 5.8 does not seem to work on the CR3 files they produce - at least when I tried it didn’t seem to work - I got blank white frames.
Am I wrong, and the R5 .CR3 files do work?
Or if not, when do you expect RT will support them?
CR3 is not a generic file format, each camera must be supported separately.
There has not been a new RT release since the R5 came out, so 5.8 doesn’t support it.
I suggest trying a development build.
The ART sub-branch supports CR3, I am not sure about the R5 though.
https://bitbucket.org/agriggio/art/wiki/Home
Update:
—seems EOS R5/cr3 is not supported by the current/latest LibRAW 0.20 - so ART most likely can’t do them yet—
Hi,
yes it does (though some compression schemes do not work). But as @paperdigits suggested, also dev builds of RT have the same support.
ART 1.6 does not seem to support 1DXMk3 CR3s either, and they have been around for a while.
I am unable to open my CR3 files taken with my new R5 body in the RT macOS dev build I use as suggested in the RT macOS Catalina FAQ, which I took from @HIRAM’s key base at kd6kxr/ – Keybase.pub. I use the RawTherapee_OSX_10.9_64_5.8-397-g276ae214f. Do I need a higher dev version if I want to open my R5 raw files? I am unable to compile my own RT or ART on macOS as I posted in two previous posts here and here. Would it be possible to make new macOS version available that supports the R5 raw format on your keybase, @HIRAM?
Yes I think it should be possible; I am looking into making a macports build of the dev branch…
I had a problem with having CR3 files shown in RT 5.8, too. My files are from a Canon EOS R. I found out that the file extension CR3 has not been in the preferences->file browser->Parsed extensions list; I added it and now I can work with CR3 files, still without correct color management, because I do not have a color profile for my camera.
Maybe CR3 extension must be add to the parsed extensions, in general?
Best regards, Andreas
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!!
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.
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.
It is a shame that RT still doesn’t support a major camera release. I hope this can be addressed soon.
I disagree.
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?
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.
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.
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…
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:
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)