Close Menu

    Darktable now supports Canon’s CR3 in v3.8.0, which is available now

    By 17 Comments10 Mins Read Third Party Software
    darktable - Darktable now supports Canon's CR3 in v3.8.0, which is available now

    Darktable, the open-source RAW processing software now supports the Canon EOS R5, Canon EOS R6 and more cameras that use the .CR3 RAW format.

    You can download Darktable 3.8.0 now for Windows, MacOS and Linux.

    The Big Ones

    • The keyboard shortcut system has been entirely reworked and extended to allow you to control darktable with other devices, for example, MIDI devices and game controllers. Standard keyboard/mouse shortcuts can now make use of mouse movements (horizontal, vertical, diagonal) as well as multiple button/key presses and short or long presses/clicks.

      Please note that any shortcuts you have previously created are not transferred to the new functionality and will need to be redefined in darktable 3.8.

    • New diffuse or sharpen module, allowing you to simulate or to revert diffusion processes to reconstruct images from lens blur, hazing, sensor low-pass filter, or noise. It can also be used to simulate watercolor smudges, increase local contrast, simulate blooming, or apply surface blur. Special rules can be defined to specifically diffuse across or along edges, as well as to avoid sharpening or blurring them.
    • New scene-referred blurs module, to synthesize motion and lens blurs in a parametric and physically-accurate way. This module allows you to define the motion path or the lens diaphragm and then generates the corresponding blur.
    • Perspective correction module has been renamed to rotate and perspective and now allows you to manually define correction settings by drawing lines or rectangles on the image (replicating keystone correction functionality from the deprecated crop and rotate module)
    • Added support for multiple images in the print view. The page can be filled with multiple areas, each of which can be moved around and placed on the page with the ability to snap to a grid for precision.
    • A new LMMSE demosaic algorithm has been introduced. This algorithm is particularly suited to high ISO and/or noisy images.
    • The composition guides from the crop module are now available globally and no longer require the crop module to be activated.
    • The Canon raw CR3 format is now supported (see list of supported cameras in the section below). This support is provided by LibRaw and requires at least exiv2 version 0.27.4 with BMFF support activated.
    • The color checker profiling tool, introduced in darktable 3.4 as part of the color calibration module, is now normalized patch-wise in exposure to discard the effect of uneven lighting and fall-off when shooting color checkers hand-held and on-location. This robustly decreases the residual average dE after calibration and noticeably helps to recover natural dark blues while preventing yellow shifts in highlights.

    Other New Features And Changes

    • The denoise (profiled) module now uses wavelets mode by default and its default settings in Y0U0V0 mode have been improved.
    • Flip buttons have been added to the orientation module (functionality moved from crop and rotate).
    • Background jobs handling has been removed from preferences.
    • Much of the SSE-specific code has been removed, since compiler-generated code is usually faster.
    • The darktable-generate-cache script now displays filenames and image IDs.
    • File name matches in the collections module are now faster.
    • Mask handling is faster.
    • Processing module order can now be automatically applied based on image properties.
    • Folder status is properly refreshed when a mount is changed.
    • An area color picker is selectable by using a Right-Click in addition to the existing Ctrl+click action.
    • Substitution variables have been added for image dimensions as follows: $(SENSOR_HEIGHT) and $(SENSOR_WIDTH) for the absolute pixel dimensions of the sensor; $(MAX_HEIGHT) and $(MAX_WIDTH) for the raw image size; and $(EXPORT_HEIGHT) and $(EXPORT_WIDTH) for the post-cropping final image size.
    • More work on code speed-up in many different routines ensuring better vectorization and/or OpenMP definition. Notably, the split-toning, haze removal and soften modules have been improved.
    • The “beginner” module group preset now takes the chosen workflow (display or scene referred) into account.
    • The quick access panel now takes the chosen workflow (display or scene referred) into account.
    • New sorting options based on capture, import, modification, last export and last print times.
    • Tooltip for raster mask now includes source module information.
    • The following modules have been deprecated:
      • Crop and rotate – the features of this module are now shared between the crop, orientation, and rotate and perspective modules.

        Note that the new crop module is now placed after the retouch module to ensure that the full image can be used as a source area.

    • A new option has been added to allow you to choose when to start writing changes to the XMP sidecar files. Choose to: (a) never write XMP; (b) write XMP as soon as the image is imported; or (c) write XMP only after the user has edited the image in the darkroom view.
    • Timezone entry has been improved in the geotagging module.
    • A new preference has been added to choose the number of recent collections to display.
    • Rating support has been added to the collections module making it possible to create presets, for example, to select the best images of 2021.
    • PNG files are now supported in the watermark module.
    • The values in the global color picker module are now selectable and can be copied to the clipboard.
    • HSV has been added as an option in the global color picker module.
    • The color scheme of the timeline is improved.
    • The scopes module (previously named histogram) can now be moved to the left panel.
    • Improved color rendering for waveform and parade scopes.
    • A new vertical waveform scope option has been added.
    • Live samples can now be displayed in the vectorscope.
    • An RYB option has been added to the vectorscope.
    • The lut3d module has been moved after filmic in the pixelpipe.
    • Minor usability improvements have been made to the tone equalizer, ensuring that the cursor is shown on focus and the module is activated on scroll.
    • The automatic mask tuning has been improved in the tone equalizer module.
    • New “magic wand” icons are now used for the auto-tune actions in the tone equalizer module.
    • Tiling has been enabled in the color balance rgb, diffuse and filmic rgb modules to allow very large images to be processed.
    • When scanning for updated XMP files, the synchronization window has been improved to offer more choices as to how the database/XMP files should be updated.
    • Added read support for HEIF/HEIC file format.
    • Added support for ARM64/Apple M1 as a build target.
    • Added a preference to invert the behavior of mouse scroll up/down on drawn mask attributes. At the same time, and for consistency, the scroll-up action has been set to increase all mask attributes by default.
    • Added timestamp in camera import dialog for consistency with the other import dialog.
    • The current module order is now shown in the module order module header to save space in the GUI.
    • The “module order” entry is now moved to the end of the copy/paste dialog for better usability, as this option is rarely used.
    • The split toning module now displays the hue in degrees for consistency with other modules.
    • Rejected images in the lighttable view are now dimmed for clarity.
    • The last selected Piwigo album is now remembered in the export module.
    • For advanced users and developers, OpenCL build options are now exposed in darktablerc.
    • The collections module now offers some new presets based on image time to complement the existing presets based on the import time.
    • Add a borderless requirement indicator in the print module when the user’s selected margins are below the hardware margins.
    • Add an option to show all modules in the history within the active module group regardeless of whether or not they are currently enabled.
    • Add a search box in preset preferences and shortcuts.
    • Improved curve handling in filmic. Curve should be easier to control, as some side-effects of some parameters on others have been eliminated.
    • Add thumbnail preview support for DNG files in import dialog.
    • The darktable 3.8.0 documentation now includes four (French, German, Ukranian, Brazilian Portuguese) translated languages (the first time complete, translated documentation has been made available on the release date), fully integrated into darktable’s help link system. Translated versions of the epub and pdf manuals are also available.

    Bug Fixes

    • Multiple memory leaks have been fixed.
    • Fixed green equilibration in RCD CPU code path.
    • Select the best illuminant for DNG images.
    • When trying to enter a view that cannot be used (like the tethering view where no camera is attached), make sure to reset the combobox back to the previous view.
    • Fix calibration optimizations for delta E in the color calibration module.
    • Fix focus peaking, which was in some cases displaying some random wrong pixels on the borders.
    • Fix refresh when pasting the whole or part of history.
    • Fix possible uninitialized-data access in RCD demosaic.
    • Update metadata fields when applying a preset.
    • Fix creation of liquify interpolated path to be closer to what the user would expect.
    • Multiple Windows PATH-specific issues have been fixed. Also, UNC path-names are now supported.
    • Make sure RAW+Jpeg files keep the same filename during copy & import.
    • Add some consistency to the drawn shape opacity increase/decrease, which was working in the opposite way to the other mask controls.
    • Invert liquify strength vector rotation for consistency.
    • Make metadata and tagging consistent regarding the current selection.
    • Fix some rounding errors in masks with sharp corners, which were creating discontinuities in the mask area.
    • Fix the image loader flag, which was not properly set at import time.
    • Fix possible wrong setting in Color Calibration when switching from Jpeg to RAW files.
    • Fix a rare but possible wrong White Balance just after importing a picture or while resetting the development history.

    Lua

    • Moved from Lua 5.3 to Lua 5.4.
    • Lua API is now 8.0.0.
    • Added darktable.print_toast() and darktable.print_hinter() functions to print toast and hinter messages respectively.
    • Added is_altered() field to dt_lua_image data type to determine if an image has been altered since being imported.
    • Added generate_cache() function to the dt_lua_image data type so that a mipmap cache image can be generated without having to run darktable-generate-cache.
    • Added function darktable.gui.libs.snapshots.clear_snapshots() to delete any snapshots.
    • Added event darkroom-image-loaded that is triggered when an image is loaded into darkroom view. The image is returned.
    • Added event darkroom-image-history-changed that is triggered when an image history is changed in darkroom view. The image is returned.

    Notes

    • The 3.8.x series of darktable releases will be the last that supports macOS 10.7 and building with Xcode 11.

      The next major release will require at least macOS 10.14 to run and Xcode 12 to build.

    • The modules deprecated in 3.4 have now been removed from the deprecated module group. The modules affected are: Zone System, Invert, Channel Mixer, Global Tonemap, Relight, Tonemap, Vibrance and Basic Adjustments.

    Changed Dependencies

    • Move from Lua 5.3 to 5.4.

    RawSpeed changes

    Camera support, compared to 3.6

    Base Support

    • Canon EOS R
    • Canon EOS RP
    • Canon EOS R5
    • Canon EOS R6
    • Canon EOS 250D
    • Canon EOS 850D
    • Canon EOS 90D
    • Canon EOS 1D X Mark III
    • Canon EOS M6 Mark II
    • Canon EOS M50
    • Canon EOS M50 Mark II
    • Canon EOS M200
    • Canon PowerShot G5 X Mark II
    • Canon PowerShot G7 X Mark III
    • Fujifilm GFX50S II (compressed)
    • Leica C (Typ 112) (3:2)
    • Leica Digilux 3 (4:3)
    • Leica M10 (dng)
    • Ricoh GR II
    • Sony DSC-HX95
    • Sony ILCE-7M4
    • Sony ZV-E10

    White Balance Presets

    • Canon EOS R (with fine-tuning)
    • Canon EOS RP (with fine-tuning)
    • Canon EOS R5 (with fine-tuning)
    • Canon EOS R6
    • Canon EOS M50 (with fine-tuning)
    • Ricoh GR II

    Noise Profiles

    • Canon EOS R
    • Canon EOS RP
    • Canon EOS R5
    • Canon EOS R6
    • Fujifilm X100V
    • Leica D-Lux 7
    • Leica M10
    • Leica SL (Typ 601)
    • Panasonic DC-S5
    • Panasonic DC-FZ91
    • Panasonic DC-FZ92
    • Panasonic DC-FZ93
    • Panasonic DC-TZ90
    • Panasonic DC-TZ91
    • Panasonic DC-ZS70
    Some of our articles may include affiliate links. If you purchase through these links, we may earn an affiliate commission at no extra cost to you.

    Go to discussion...

    Share.

    Related Posts

    17 comments

    3. I feel like a year and a half to support two of the most popular camera bodies in the world isn't really good enough, wonder what took them so long
      From what I’ve seen over the past year: mostly human drama.
    4. So it took until now to support ANY camera with CR3 files, which came up with the EOS M50 in June 2018? That was 42 months ago.

      I wish though that modern cameras would still offer a CR2 option. It is annoying that CR3 files are only supported by subscription versions of Lightroom.
    5. I feel like a year and a half to support two of the most popular camera bodies in the world isn't really good enough, wonder what took them so long
      The developers are not paid, and don't get support from Canon to decode its raw format, so you pass off as spoiled.
    6. So it took until now to support ANY camera with CR3 files, which came up with the EOS M50 in June 2018? That was 42 months ago.

      I wish though that modern cameras would still offer a CR2 option. It is annoying that CR3 files are only supported by subscription versions of Lightroom.
      DXO supports CR3 for quite a while.

      Its bothersome, but you can use DPP, which is free, to convert CR3 to 16 bit TIFF.
    7. I feel like a year and a half to support two of the most popular camera bodies in the world isn't really good enough, wonder what took them so long
      The developers who aren't paid were worried that they would be sued by Canon in the US if they put in CR3 support. Canon has one of the largest patent portfolios in the world and an army of lawyers to defend them. Software patents which were invented out of thin air by the out of control US courts not Congress are only recognized by I believe 3 countries. The US, India and maybe one other. But they F things up for every one in the world.
    8. So it took until now to support ANY camera with CR3 files, which came up with the EOS M50 in June 2018? That was 42 months ago.

      I wish though that modern cameras would still offer a CR2 option. It is annoying that CR3 files are only supported by subscription versions of Lightroom.
      A non-subscription version of LR is by definition obsolete and unsupported, so you are optimistic in expecting support for a new formant. At this point, PS, LR, PS elements, DXO Photolab, ON1, Luminar, Capture One, Paint Shop and now Darktable all support cr3 files. Seems like enough choices.
    9. A non-subscription version of LR is by definition obsolete and unsupported, so you are optimistic in expecting support for a new formant. At this point, PS, LR, PS elements, DXO Photolab, ON1, Luminar, Capture One, Paint Shop and now Darktable all support cr3 files. Seems like enough choices.
      Of course software companies are interested in new formats that give them the chance to sell new software, but camera companies should at least try to find a RAW format that will not have to change all the time. The information how to interpret that data and especially how to demosaic the image should be baked into the file, so that even old software can support it. It is also quite annoying that each software needs support for every new camera separately to apply new profiles. There should be a standard to import new profiles after you download them from the webseite of the manufacturer.
    10. Does Darktable not simply rely on LibRAW for its file support like a ton of commercial and non-commercial projects do? I know they had support for CR3 about 6 months after the M50, and that's how it appeared in Luminar which relies on the library.
    11. Darktable relies on rawspeed for many raw file formats, and an attempt was made to use that. There was a patch for that which made it work, but the maintainer didn't or hasn't merged it. In the end the maintainers of darktable went with libraw for CR3. I use darktable for all of my edits and I'm happy to not have to convert my files to DNG before editing.
    12. Of course software companies are interested in new formats that give them the chance to sell new software
      Darktable is opensource written by volunteers.
      but camera companies should at least try to find a RAW format that will not have to change all the time.
      AFAIK, the CR2 format was introduced with the Canon EOS 1Ds in 2002 (a year after Windows XP was released), and the CR3 format was introduced with the EOS R in 2018. Is any part of your computer, or any software installed on it, 16 years old? Do you complain on those changing all the time?

      The information how to interpret that data and especially how to demosaic the image should be baked into the file, so that even old software can support it.
      I have >10,000 CR2 files on my hard drive, and I bet some forum members here have at least ten times as much. Keeping thousands upon thousands of copies of this information is wasteful. You can always download the latest version of DPP, and use it to convert the raw file to some other format your old software accepts, e.g. TIFF.
    13. Of course software companies are interested in new formats that give them the chance to sell new software, but camera companies should at least try to find a RAW format that will not have to change all the time. The information how to interpret that data and especially how to demosaic the image should be baked into the file, so that even old software can support it. It is also quite annoying that each software needs support for every new camera separately to apply new profiles. There should be a standard to import new profiles after you download them from the website of the manufacturer.
      You are completely missing the whole issue of intellectual property. Camera RAW files involve either lossy or lossless compression and those compression algorithms (particularly the lossless ones) are big competitive advantage. For starters, compare the size of a CR3 file to TIFF file of the same image or more importantly to a Sony uncompressed raw file (hint, the Sony files are HUGE). In order for an editing software company to support the new camera raw formats, they have to be able to decompress the files and that almost certainly involves contracts, NDAs, etc. In some cases, it may well also involve license fees.
    14. You are completely missing the whole issue of intellectual property. Camera RAW files involve either lossy or lossless compression and those compression algorithms (particularly the lossless ones) are big competitive advantage. For starters, compare the size of a CR3 file to TIFF file of the same image or more importantly to a Sony uncompressed raw file (hint, the Sony files are HUGE). In order for an editing software company to support the new camera raw formats, they have to be able to decompress the files and that almost certainly involves contracts, NDAs, etc. In some cases, it may well also involve license fees.
      oI don't disagree with what you wrote. But in this case CR3 was reverse engineered by the open source community pretty quickly.

      github.com

      GitHub - lclevy/canon_cr3: Describing the Canon CR3 fileformat from Canon M50 / EOS R / SX70 HS / EOS RP...

      Describing the Canon CR3 fileformat from Canon M50 / EOS R / SX70 HS / EOS RP... - GitHub - lclevy/canon_cr3: Describing the Canon CR3 fileformat from Canon M50 / EOS R / SX70 HS / EOS RP...
      github.com github.com

      That made writing a free open source decoder possible and legal for free sans NDA every where except for the US and India. The truth is if you look at the format there really isn't a lot of net new involved. It is mostly a lot of existing stuff that has been repackaged. The biggest proprietary thing is the pixel shift part.
    15. oI don't disagree with what you wrote. But in this case CR3 was reverse engineered by the open source community pretty quickly.

      github.com

      GitHub - lclevy/canon_cr3: Describing the Canon CR3 fileformat from Canon M50 / EOS R / SX70 HS / EOS RP...

      Describing the Canon CR3 fileformat from Canon M50 / EOS R / SX70 HS / EOS RP... - GitHub - lclevy/canon_cr3: Describing the Canon CR3 fileformat from Canon M50 / EOS R / SX70 HS / EOS RP...
      github.com github.com

      That made writing a free open source decoder possible and legal for free sans NDA every where except for the US and India. The truth is if you look at the format there really isn't a lot of net new involved. It is mostly a lot of existing stuff that has been repackaged. The biggest proprietary thing is the pixel shift part.
      Figuring out how it was done doesn't get you out of the patent/copyright jungle. Some of that stuff (like HEIF) is protected pretty much worldwide. Even Canon has to license HEIF. You can tell this is the case because when you load DPP, it goes through a procedure to enable the HEIF feature that only happens with protected and licensed stuff. This is the case with most contemporary CODECs for video and audio as well. The power struggle that went on during the development and deployment of MPEG was epic. I was in the middle of the fray and remember it well. The singular reason for the release of the Microsoft video and audio codes was to force the devaluation of the MPEG stuff so it would be widely affordable, and the power play worked. MS owned a big enough percentage of the IP that they were able to force the rest of the players to sell cheap. Still image CODECS have not had the drama of the video stuff, but there is still value there that companies try to extract. Many of those patents extend far wider than the US and India.
    16. Setting aside the discussion of why it took so long, I'm grateful for darktable and to all it's volunteer developers. It's an awesome piece of software backed by solid algorithms grounded in physics, color science, etc. I haven't used Adobe Lightroom or other commercial products so I cannot compare, but if you haven't given darktable a try, consider doing so. There is definitely a learning curve but it's worth it.
    17. Figuring out how it was done doesn't get you out of the patent/copyright jungle.
      Copyright in code is the same as it is in text. If it isn't extremely similar the it isn't copying. Just because what it does is similar is not the same as it's code being the same. Clean room implementations of code are done all the time and are accepted even in the US. That just leaves us with the pesky patents.

      Some one posted the big list of video patents a few months ago trying to make the case that software patents were enforceable all over the world because there were patents related to video codecs all over the world. I took a dive on the patents that applied to the country I live in and every single one of them applied to using the codec is conjunction with a specific hardware device often players if one form or another,. Not one of them was a software patent.

    Leave a comment

    Please log in to your forum account to comment