Support for Canon CR3 raw files #271
Conversation
|
So, I was able to open a couple of CR3 files from my Canon M50 using darktable on my intel macbook, with a couple of small issues:
great job @cytrinox , it appears to be working very well! |
Please share a patch with me to add the camera entry.
There is already a PR for darktable with M50 coeffs from me: darktable-org/darktable#8927
The darktable PR for ISOBMFF detection was written by myself, too :) darktable-org/darktable#8751 Please let me know what must be fixed or open a PR 😄 |
|
I've got a full Canon R5 sample set today, so I will integrate R5 as well. @LebedevRI I know you want samples at raw.pixls.us. To create a full cameras.xml entry with your dngmeta.rb script, for all ISO levels a sample file is required. So I've requested a sample matrix of:
All files are named with a good name, like Canon_EOS_R_ISO_100_dualpixel_off_nocrop.CR3. |
|
Here is a rawspeed cameras.xml patch for the Canon Kiss M camera. |
|
Rather than create a separate entry for Canon EOS KISS M in cameras.xml, I have added an alias under the M50 entry (since the KISS M is just the Japanese marketing name for the M50 in Japan). This allows the files for the KISS M to be opened, and the id used for the alias allows lensfun to find the appropriate camera profile for lens correction. I created a PR against the canon_cr3 branch in @cytrinox github repo ( cytrinox#1 ), if he accepts that PR onto his canon_cr3 branch then I think the associated commit should be automatically picked up by this PR. |
|
@matt-maguire I've already reworked the cameras.xml for the Kiss M and will push the changes soon. |
|
Base samples are uploaded to RPU for all cameras included in this PR. If more/other samples needed, please post an update on this PR and @johnny-bit and myself organize them. For 90D and 850D, the PR darktable-org/darktable#8962 includes information for adobe_coeff.c. |
|
Thanks for all your hard work on this issue. |
|
Don't hesitate to look for adobe coefficients or black/white levels in our camconst.json file from RawTherapee. It's may help fill in some gaps! |
|
Please do you have cr3 samples with crop (1.6x with EF-S lens) ? It is to improve my cr3 docs and parser . |
I've crop samples for all cameras+modes (that supports crop) listed in this PR. Can you contact me at matrix/irc? |
Which address? Server? Or room? |
#pixls.us or #darktable on freenode @cytrinox |
|
@lclevy - both darktable and pixls.us channels are on freenode irc also the call for samples is present (with links still viable and current sample status) here: AFAIK cytrinox has all the files sent by users. |
|
"CRAW (compressed RAW)" |
|
Added credit for CR3 file structure info from lclevy/canon_cr3, no other code changes are made. |
|
I've added two more commits for fixing ISOSPEEDRATINGS integer overflow and better IAD1 box parsing. The IAD1 box contains 4 rectangles, one for crop, two for black areas and one for active area. During tests a user reported that for the EOS RP model, black levels (from rawspeed calculation) are wrong for photos using larger ISO values (>= 800). For such images, the black areas include some white pixels which results in wrong black levels. After some investigation, I think this is a camera bug, as the IAD1 box says blacklevel areas start at offset 0 (for vertial and horizontal) but in fact, there are white pixels located at this offset.
|
Codecov Report
@@ Coverage Diff @@
## develop #271 +/- ##
===========================================
- Coverage 60.47% 50.50% -9.98%
===========================================
Files 207 214 +7
Lines 12628 15121 +2493
Branches 1761 2259 +498
===========================================
Hits 7637 7637
- Misses 4859 7352 +2493
Partials 132 132
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
Hi, I really appreciate your work for enabling CR3 support on darktable (especially since my old Canon camera is broken and now I switched to an EOS R). Is there still a chance to get CR3 support in the upcoming darktable release or is it already too late? Is ther anything I can help with? BR, Bodo |
|
the 3.6 release is already past the feature freeze. You can rely on experimental builds and tests if you're ok with that. |
|
darktable already opens CR3 files. |
|
BUT afaik not via rawspeed yet.
pt., 24 cze 2022 o 22:59 Paolo Benvenuto ***@***.***>
napisał(a):
… darktable *already* opens CR3 files.
—
Reply to this email directly, view it on GitHub
<#271 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACRRKFIUSQQ5YUPW2G2DTEDVQYOTJANCNFSM44WZTUVA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Pozdrawiam,
Hubert Kowalski
|
I have tried and it is not showing up in the list of supported formats, and throws an error when I force it to open a CR3 file...my system is up to date...am I doing something wrong? |
It depends which distro you are using and how you installed darktable -- by default, CR3 support is disabled in the EXIV2 library, and the person packaging exiv2/darktable for your distribution needs to take explicit steps to enable the CR3 support. |
Oh ok. It seems as though my darktable, even when installed fresh, is still on version 3.0.1. I tried installing the latest version from the .deb file on the website but it says a dependency (libc6) can't be satisfied. I tried installing libc6 and it won't install the latest version for some reason. Why are all these package managers not updated by the devs when new versions come out? I thought that was the whole point of a package manager... |
|
Are you using Ubuntu 20.04 or some equivalent OS? For a fixed version of Ubuntu, new versions of packages are normally only pushed for bugfixes and security updates. If you want newer software, either use a newer version of Ubuntu (22.04 perhaps) or get packages via other means better for bleeding edge, like Flathub, PPAs or building them yourself. |
Hmm OK thanks, I see I am still on 20.04. Why doesn't it update to 22.04 from the update command? How does one update without doing a fresh install? Is this even possible? Edit: I see now it's because Linux Mint is in control of what version of Ubuntu is running...and they haven't yet updated. I guess that explains why people usually get more and more towards the source as they get more familiar with Linux... |
|
Hi all. It looks like this PR has gone a little stale. Is this still being planned for merge? |
|
CR3 support is inside darktable since some version |
I'm aware of that. It uses LibRaw for that. I'm referring to support for CR3 images in RawSpeed, i.e. this PR. |
|
i have in the past rebased this cr3 branch onto newer versions of the develop branch. lately this has become harder than usual, so i had to actually look at the code in doing so. @LebedevRI would you be interested in merging this feature, given some overhaul and cleanup? if so, i could try to spend some time on this. i don't have a cr3 camera myself but i think this is a major feature and i think rawspeed is the most sophisticated and well engineered library available and should be able to load cr3. i was able to open a cr3 with this rebase of the cytrinox/canon_cr3 branch today: https://github.com/hanatos/rawspeed/tree/rebase_cr3 but i would have to say i did a few fairly terrible things to make it work. i would completely understand if you reject to merge this (to a point that i don't think it's ready for an official pull request). but if there is general interest i'll be happy to take suggestions how to improve this. some thoughts for discussion:
|
|
Any possibility of this PR being merged in the near future? I am also using a fork of Rawspeed with this CR3 support merged in. Rawspeed is an amazing and fast raw decoder. I would love to have CR3 baked in by default. Any contributions I can make to see this happen? |
|
For those who are recently asking themselves why this is not moving anywhere: I made this comment above 2 years ago, hinting at some speculative theory as to why the sole maintainer of this repo has not provided a single comment in this 2,5 year old discussion here. I am personally not yet depending on CR3 support and am still running a fork from around 6 years ago, when I left the project. This might change soon. As things are looking right now, I personally have zero hope that Roman will merge this. Maybe there would be interest from a small group of interested parties to focus on a 'community' fork with CR3 support? |
|
To play devil's advocate for a moment, Roman did actually open #121 and moved it to "Code needs porting" in "New Raw Formats" in December last year, so I doubt he's opposed to the idea. I'm also glad to see him putting work into fuzzing, CI and code cleanup. Having said that, I agree that he's being overly taciturn in regard to this PR. We also have a viable alternative for the time being in the form of libraw, which handles CR3 files just fine in my experience. However, I also think that the lack of CR3 support doesn't bode well for the future of rawspeed as a project. With Canon still having a dominant position in the market, I'd bet that CR3 would now be one of the most common raw formats. In this respect, rawspeed is definitely not meeting its goal of "support[ing] the most common DSLR and similar class brands." (https://github.com/darktable-org/rawspeed/blob/develop/README.rst ) darktable will almost certainly continue to use libraw for CR3 support for the foreseeable future, and at some point a developer will probably ask "why are we using two raw decoding libraries when libraw could do it all", followed by good arguments about economies of scale and not reinventing wheels. Rawspeed might be faster and better engineered than libraw, but if it can't do what libraw does, it will lose out. It would not be the first time in history that the more elegant technology lost out to the thing that was "good enough".
Possibly. I worked on the CR3 code in exiv2, so I could be interested. I think that would be a fairly major step though. A lot of ongoing work would be required. |
This is unlikely to happen either, because of LibRaw's lack of roadmap transparency/commitment and (equally problematic) outside developer inclusion - will happily take patches, but only release public betas w/ new camera support once a year (maybe?), and stable releases only every two years or so (which is not great for distribution, as most would prefer to use the stable system package rather than a vendored beta). So, dt is simply stuck w/ both of these imperfect solutions for that foreseeable future unfortunately. FYI, vkdt seems to be leaning towards OP's new rawler library. |
|
Question: what was the reason to add LibRaw next to the existing RawSpeed in the first place? |
It was re-enabled two years ago just because of CR3. Originally (it was added years ago and then disabled for a very long time), I don't know why. |
I see. So do I get this right?
Why did then not someone else step in and merge this PR? If LibRaw's only purpose in dt is to provide CR3 support and this situation is viewed as "unfortunate" why then not simply move ahead with this PR, where multiple people offered to help with open issues/questions, and end up with a working CR3 decoder in RawSpeed? |
I think this was already covered. The darktable and rawspeed repos are not maintained the same way. |
I don't know what you are referring to here, sorry if I missed something.
Thanks for answering. So I understand that I was wrong in at least in one part: even though the rawspeed repo is owned by darktable-org, this does not mean that any of the 27 people in that group other than Roman have the 'physical' ability or 'organizational' role to make changes to that repo? If the dt stakeholders and the rawspeed stakeholder are effectively two "separate" groups with separate interests, I wonder if the dt people would also potentially be interested in a 'community' fork that contains CR3 support? |
Just to the same conclusion you have just reached. Again. 😉 (or 😞) |
|
I have extensive experience working with both Libraw and Rawspeed. For one thing, contrary to some belief, Libraw support for raw files is not a superset of Rawspeed. At least, I have some raw files which Rawspeed can decode but which Libraw cannot. Second, I have published a sort of "compatibility interface" for raw file decoding which provides a common API to decode raw files with Libraw and/or Rawspeed. I wrote it for an iOS app, so it is written in Objective C. That makes it suitable for the Apple universe of projects, which is intentional. Anyway, this project is public and available at https://github.com/mallman/RawDecoder. If you're looking for a C or C++ interface, this is not the place for you. :( Third, I prefer RawSpeed over Libraw for many of the same reasons cited here. And I see many opportunities for improvement and optimization—and I would be happy to contribute code. However, I don't expect this project to accept any outside contribution, so I haven't bothered contributing anything. Additionally, the license is too encumbered. Unless someone can magically fork this into a repo that doesn't use a copyleft license, I will not be a part of the fun. Personally, I would prefer a community driven open source codebase without a copyleft license. That is not Rawspeed. I looked for something like this for a long time, and didn't find anything. I will have a look at vkdt and rawler. I don't think I've seen them before. Thanks for the tip. |
Could you please provide problematic sample files via LibRaw issues on GitHub ( https://github.com/LibRaw/LibRaw/issues ) or via E-mail to [email protected]? Thanks in advance. |
There's also libopenraw, but I guess doesn't fit your licensing requirements either. |
|
If progress has stalled on this, does anyone know if we could build a framework under the Linux Foundation or some kind of foundation like that |
Who is that ‚we‘ that takes the responsibility maintaining that for a whole bunch of platforms? At least no one stepped in and forked a rawspeed-nextgen project. And also no one stepped in to replace libraw within darktable with rawler which is a bit faster in supporting new canon cameras … |
|
I can find this library you speak of but it's all the same problem, we could opt for super camera deluxe library. But if there isn't a clear structure around making sure it's supported and well funded then it will fizzle out eventually even if it's pretty good now. Libraw has lasted as long as it has because it has a well defined funding model, even if that funding model hurts the time it takes to adopt new standards Ideally the community could find a solution for that. |
|
there’s no developer or maintainer named ‘the community’ in the rawspeed project ;) |
|
I added a patch for Canon EOS M6 Mark II at #284 I'm commenting here as that ticket recommends. Can someone with commit access please merge the patch? |
This PR adds support for Canon CR3 raw files.
Canon CR3 files are something new compared to the good old CR2 format. CR2 was based on TIFF. CR3 is based on ISO BMFF.
BMFF organizes data into boxes. A description of all related boxes can be found at https://github.com/lclevy/canon_cr3.
To support CR3, rawspeed needs an ISOBMFF parser to iterate and query boxes. This is implemented in IsoMBoxes.cpp.
ISOBMFF can be extended with custom boxes, so for the custom Canon boxes, a separate parser is required. The most interesting boxes are:
Older cameras has multiple raw quality modes: raw, mraw, sraw with reduced pixel size (=smaller files). Cameras with CR3 support don't shrink the sensor data, instead a wavelet based compression is applied. So pixel dimensions are equal for RAW and CRAW (compact RAW) mode. It makes no sense to define craw as separate mode in cameras.xml as this is directly handled by the decompressor.
But Canon has introduced another mode: 1.6x crop. Because full-frame cameras like R and R5 supports old EF-s lenses, the camera auto-forces a crop-mode with EF-s. For EF and RF lenses, crop-mode can be manually enabled. If crop is enabled, the sensor size, raw pixel data, crop-areas and black-areas are different - compared to full-frame images. This is dynamically handled by the IAD1 information. So crop and black areas are automatically applied and must not be specified in cameras.xml.
To get white balance coeffs is a litte bit tricky. As for CR2 files, Canon stores this information in the CANONCOLORDATA EXIF tag. But this tag is not embedded in CMT1, CMT2, CMT3 or CMT4. Instead, this tag is located in CTMD in track 4. CTMD contains multiple records with a specific type. Record type 8 contains EXIF data and the CANONCOLORDATA tag. The wb_offset hint in cameras.xml points to the wb coeffs inside CANONCOLORDATA. This offsets are taken from exiftool source-code and validated against sample images.
As I have only access to samples for EOS R and EOS M50 yet, these are the first cameras with full support. B/W levels are extracted from large image sets of all ISO values.
So far, I was able to open any CR3 with this code: RAW, CRAW, 1.6-cropped, even dual-pixel images.
I hope this PR helps in adding long awaited CR3 support 😃
Fix for #121 #193 #192