Unwanted automatic cropping in Darktable 4.2.1

ak0gs · May 28, 2023, 10:02am

Hello,
I have now spent a considerable amount of time, yet I did find no solution for automatic cropping of raw image in Darktable.

Description: I have raw images in .CR3 with aspect ratio of 3:2 (or at least I believe it is 3:2, as the camera has APS-C sensor). Darktable crops it to what I believe is 4:3. And I cannot find a way of disabling this cropping. When I open the same .CR3 image in image viewer (Nomacs in my case), and save it as whatever (jpg, png…) it saves it uncropped, as I want. Darktable however always crops it.
I’ve made sure the crop module is disabled. Lens correction is also disabled. However, it still crops.

Images follow:

Original image, uncropped (saved as .jpg with nomacs). You can see the end of train on the left + another railroads. Note: Image is compressed.

Image from Darktable (saved as .jpg with Darktable). Here you can see, that the end of the train on the left barely fits, and the railroads on the left are not there. Darktable states it did not crop it. Note: Image is compressed. ** I know the colors are different between programs, this is just an example of the cropping, not color processing.**

One interesting fact: When I import the file in Darktable, the preview is uncropped. However, as soon as I open it in darkroom, it crops the image.

Does anybody know how to force Darktable to not crop it?

Thanks in advance!
Jiri

kmilos · May 28, 2023, 10:33am

I think this is fixed on master, please check it out, or the upcoming version next month.

github.com/darktable-org/darktable

Raw file developers should NOT be restricted by preferences set in the camera

opened 02:05PM - 15 Aug 22 UTC

closed 08:12PM - 08 Mar 23 UTC

aaeneas

no-issue-activity

A recent experience using Darktable (DT) to develop my raw images is what motiva…ted the submission of this issue. This resulted in my posting [this request](https://discuss.pixls.us/t/how-to-learn-image-dimensions-in-darktable/32147) for help. Digital camera's provide users with lots of settings that allow them to exercise some control over how pictures are developed by the camera. In that, for users to have any say in how a jpeg file is developed by the camera they must inform the camera of their preferences. One such setting is called "Aspect Ratio". Darktable (DT) is using this setting when determining what raw data is available to the user for developing a picture. I think, it is pretty well accepted practice that the purpose of using software to develop raw files on a computer, rather than have the camera do it, is to allow the user of the software to have as much control as possible when creating their own image file. Unfortunately, if the "aspect ratio" is set in the camera to something other than the full size of the sensor, Darktable is NOT allowing some data the camera captures from being used when developing a raw file. As a result, there are situations where the only way to get DT to use all of the raw data is to update the metadata portion of the raw files. This is quite contrary to the idea of non-destructive editing. Something that seems especially odd is that this metadata (aspect ratio settings) are part of what is referred to as "Makernotes" which differs for each make of camera. This suggests signicant added difficulty for DT to implement and maintain such capability. My workflow is such that I prefer to use all of the raw data to develop an image and create what I might call a master file. Transformations for various purposes such as printing on different size paper are then done after the fact and in my case this is done with other software rather than DT. I also tend to use multiple programs to develop raw files and produce image files for the purpose of comparing results. I have a new camera that I'm learning how to use. I apparently changed the aspect ratio to 16:9 for reasons I do NOT recall. However, I have my cameras set to only produce raw files and I expected this to be insignificant. However, I developed some raw files without even noticing that DT had applied the 16:9 aspect ratio. However, it became quite apparent when I went to print some of them. There were some pictures that I especially liked and had spent quite a long time developing them. In that, I did NOT want to re-develop the picture. Fortunately, the community responded to my request for help which accomplished this objective. However, there was a lot of effort required by many parties. It would definitely be surprising to me to learn that I'm the first to complain about this aspect of the DT design. Maybe the answer is that other DT users are NOT dumb enough to change the aspect ratio in their camera. This problem does NOT exist with any other software that I've used to develop raw files. One of those is the software supplied by Canon which does use the camera settings including aspect ratio as a default (i.e., starting point) selection. However, it can easily be changed in the tool normally used to make such changes to an image. The DT idea that such data is irrecoverable is completely contrary to the idea of wanting to work with raw files.

kofa · May 28, 2023, 12:20pm

Usually, it’s the other way around: one can get more from the raw than from the JPEG.
The issue could be caused by lens correction, which tries to warp the image to correct its geometry. Try disabling the module, switching to a different target geometry in the module, and/or playing with scale.

ak0gs · May 28, 2023, 4:42pm

Hello,
Oh wow, this seems to be the issue.
I checked, and yes, the camera was set for 4:3 aspect ratio (so even though raw is 3:2 it has the information that it should be 4:3 so Darktable obeys it).
It is definitely odd behavior, so hoping next release will let me decide.

Thanks for help.

ak0gs · May 28, 2023, 5:46pm

And I can confirm that in the latest nightly version, I can decide if image will be cropped, so it is solved in the latest release.

Roger.Wilco · May 29, 2023, 1:21am

I’ve come across similar: Embeded Exif Cropping Info - way to ignore/turn-off? DT4.2.0

If what you have mentioned above - that this is now fixed in the development version. Great to know.