darktable-org / darktable-org/darktable
Apply the aspect ratio dialed in on the camera as an editable crop
Nobody has claimed this yet.
- 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 DefaultUserCropkeeps 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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