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

[aaeneas]

A recent experience using Darktable (DT) to develop my raw images is what motivated the submission of this issue. This resulted in my posting this request 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.

[jenshannoschwalm]

The point about aspect ratio is just misleading, it's only about the area of data defined as "valid" , allmost all raw files have to do that!

Right now dt thinks, if the user selected a crop - as you did - it should be accepted as valid.

So the only issue I see here is "could /should dt use that as a hint for the crop module instead?" BTW we do that for dng files already.

[aaeneas]

Like I said, the relevant metadata pertaining to my experience was to be found in Makernotes. I think Makernotes differ for each brand of camera and possible even within a brand for different models. My Canon camera also outputs metadata that describes what part of the actual sensor is used as follows:
Sensor Width : 6888
Sensor Height : 4546
Sensor Left Border : 156
Sensor Top Border : 58
Sensor Right Border : 6875
Sensor Bottom Border : 4537

However, an example of the metadata being used by DT in this case is the following:
Aspect Ratio : 3:2
Cropped Image Width : 6720
Cropped Image Height : 4480
Cropped Image Left : 0
Cropped Image Top : 0

The former (i.e., SensorWidth, etc.) fits the idea of defining what is "valid".

There is NO harm comes from using this Aspect Ratio data, which also applies to the camera developed image, as a hint (i.e., for DT that would seem to be a default setting for the Crop Module) which the user can subsequently change.

In my case, where I have the camera set to only produce raw data this is NOT a problem now that I know about it. However, for people who want both jpg & raw from the camera they should be able to instruct the camera (via Aspect Ratio) to produce a cropped image without that affecting the raw data.

[jenshannoschwalm]

Dt does use maker notes only if reported via exiv2. Aspect ratio is calculated from used sensor size as reported.

[paperdigits]

@jenshannoschwalm when I saw this I thought it was a subtle difference with how libraw passes raw data into the pixelpipe vs how rawspeed does. Initially libraw seems to honor the crop set in the metadata, while rawspeed passes the whole image regardless of the in-camera crop metadata. I don't think either is wrong, but I do think they should handle things the same way.

[jenshannoschwalm]

@paperdigits , you are probably fully right here. I have not run into images yet loaded via libraw so I missed that. Don't know how the internal parameter presentation for libraw works and if we /dt can do otherwise.

[kmilos]

Also don't forget that some cameras (e.g. some Panasonics, Sonys etc.) actually do crop to aspect ratio/crop size set at the time of capture and sensor readout, so you don't have access to more. Check e.g. file sizes and pixel counts for the DMC-GF2 at https://raw.pixls.us/#repo

[jenshannoschwalm]

Exactly.

[paperdigits]

For cameras that crop the data, that is acceptable. But, for this particular camera, a canon r-series, it seems like all the data is there. I don't have any of these cameras, but I did as OP to open this ticket in hopes of improvement.

…

On August 18, 2022 1:05:32 AM PDT, "Miloš Komarčević" ***@***.***> wrote: Also don't forget that some cameras (e.g. some Panasonics, Sonys etc.) actually do crop to aspect ratio/crop size set at the time of capture and sensor readout, so you don't have access to more. Check e.g. file sizes and pixel counts for the DMC-GF2 at https://raw.pixls.us/#repo -- Reply to this email directly or view it on GitHub: #12326 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[kmilos]

This is currently handled here:

darktable/src/common/imageio_libraw.c

Lines 294 to 304 in 5e3a078

	// Apply crop parameters
	libraw_raw_inset_crop_t *ric;
	#if LIBRAW_COMPILE_CHECK_VERSION_NOTLESS(0, 21)
	ric = &raw->rawdata.sizes.raw_inset_crops[0];
	#else
	ric = &raw->rawdata.sizes.raw_inset_crop;
	#endif
	img->crop_x = ric->cleft;
	img->crop_y = ric->ctop;
	img->crop_width = raw->rawdata.sizes.raw_width - ric->cwidth - ric->cleft;
	img->crop_height = raw->rawdata.sizes.raw_height - ric->cheight - ric->ctop;

Other options are I presume also in the libraw_image_sizes_t struct - please test across all R-series cameras and report what values to use.

[github-actions]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[aaeneas]

I just installed Darktable Version 4.0.1. I do NOT see any change in behavior when it comes to processing raw files from my Canon EOS R where the aspect ratio set in the camera causes Darktable to prevent access to all of the sensor data. As previously mentioned I did NOT intend to set the camera that way and I have figured out how to revise the metadata in the few files that were affected to gain access to all of the sensor data.

In that, still seems like Darktable should permit access to all of the sensor data but this is NOT a major problem for me.

[github-actions]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.