darktable-org / darktable-org/darktable

Apply the aspect ratio dialed in on the camera as an editable crop

Open
#22,087 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature: new scope: DAM
Dominant language
C
Stars
13.1k
Forks
1.4k
Avg merge
22h 14m
Merged PRs (30d)
198

Description

Apply the aspect ratio dialed in on the camera as an editable crop

This follows on from #19109, which was closed as not planned. In that thread
@kmilos asked for a generic approach covering all brands rather than a
single-model fix, and I think that is reachable. I have a working, tested
implementation for Canon built around a per-vendor hook, and I would like to
check the design is wanted before pushing on it.

The problem

Many cameras let you choose an aspect ratio in the viewfinder. On raw files
the choice is recorded but the surrounding pixels are kept. Lightroom and
Capture One reproduce that framing on open and let you undo it. darktable
shows the full sensor readout, so the framing decision made while shooting
is lost, even though the information is right there in the file.

We already do this for DNG via DefaultUserCrop, where the crop module
picks the box up in reload_defaults(). Nothing equivalent exists for
vendor makernotes.

Proposal: keep the ratio, not the box

@kmilos raised a real obstacle in #19109:

A slight complication is that dt/rawspeed usually also doesn't apply a
"full" raw sensor crop identical to the vendor to begin with...

That is exactly what makes reusing the vendor's box awkward. On an EOS R6
the camera reports its 1:1 crop as 3648x3648 at x=912, relative to its own
5472x3648 output area, while the pipe is handed 5496x3670. Reusing those
numbers means tracking every vendor's idea of the full frame.

So the proposal is to keep only the ratio and let the crop module
center it on whatever area darktable actually produces. That removes the
dependency entirely. It also happens to be the only thing some vendors
record: the GFX100RF data posted in #19109 shows RawImageAspectRatio: 1:1
alongside a RawImageCroppedSize of 11648x8736, which is the native 4:3
area, so there is no vendor box to reuse there in the first place.

A side benefit is that the user gets slightly more image than the camera
would have given them, since darktable's active area is a little larger.

Where the data lives

I checked what exiv2 0.28.8 actually exposes per vendor:

Group Aspect/crop tags
Canon AspectInfo (0x9a) - ratio, width, height, left, top
Fujifilm CropMode (0x104d) - not the aspect dial
Nikon3 CropHiSpeed (0x1b) - DX crop, different feature
Panasonic, Sony, Olympus, Pentax none

So Canon is reachable through exiv2 today and is what I implemented. To
correct the record on one point from #19109: exiv2 does report this for
Canon. For Fuji it does not, and the RAF values quoted in that thread come
from the RAF container rather than the Exif makernote, so a Fuji reader
would need that container parsed (or the values taken from LibRaw) rather
than a new exiv2 key. I do not own a Fuji body and cannot test one.

Shape of the change
  • the ratio is read into the image as camera_ratio_d / camera_ratio_n
  • _check_camera_aspect() is a table of per-vendor reader functions;
    adding a vendor is one function and one line
  • the crop module centers the ratio, follows the image into portrait, and
    enables itself, so the framing is applied but stays editable
  • DefaultUserCrop keeps its current behaviour of only preloading the
    parameters, untouched

I am aware that switching a module on by default is a policy decision
rather than a detail, which is the main thing I would like a steer on.
@jenshannoschwalm noted in #19109 that the DNG path is deliberately
"default being off but being immediately available"; I kept that as is and
scoped the change strictly to camera aspect settings, but I am happy to
make the new path opt-in via a preference instead if that is preferred.

Tested on an EOS R6 across 1:1, 4:3 and 16:9 in both landscape and
portrait, with native 3:2 correctly left alone. PR to follow.


Disclosure: designed, written and tested with AI assistance (Claude Code with Claude Opus 5).
Verified against current master and builds clean with no new warnings.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the proposed _check_camera_aspect() vendor-hook table and the crop module’s reload_defaults() path, then review how exiv2 0.28.8 exposes Canon AspectInfo. Done means reaching agreement on default-on versus opt-in behavior and validating the editable centered crop for Canon 1:1, 4:3, and 16:9 images in landscape and portrait, while leaving native 3:2 unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
computer-graphics, desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.