Limit output resolution/size from darkroom
When processing noisy images (e.g. ISO 6400), I do not export with full pixel count but limit to a reasonable size that hides the noise a bit. The same holds for slightly unsharp images. That way, the maximum usable image size, e.g. maximum print size, is given by the image resolution and limited such that the technical flaws are not visible for the people viewing the picture.Unfortunately, the output size/resolution is determined in lighttable mode and therefore the image itself does not carry this information. When I export an old picture again, I maybe forget that it was a blurry shot and therefore it is sent out at e.g. full resolution. Furthermore, when processing a set of images, one always has to export one by one to account for the blurry/noisy shots. It would therefore be great if one could limit the resolution from within darkroom such that is cannot be overridden by the export module (smaller export would still be possible). A new module “limit output size” would be a reasonable way to implement this feature. Within the module, the output size limit could be selected as either (maybe a dropdown to choose among these)
- absolute pixel numbers (input of two numbers, max. horizontal and vertical pixel count; dependent on the aspect ratio, one of the numbers wins, as in the export module),
- megapixel count (input one number, e.g. 10M, and the closest smaller size that would match the aspect ratio is used), or
- factor of the original size (e.g. “2” for downscaling to half the size; factor 2 would therefore mean quarter of the pixel count; or, instead, the factor of the pixel count to avoid the necessity of sqrt(2) input; or maybe both options).
The darkroom view would of course follow the limitation to have a reasonable preview. The module itself would also show the actual output size limit of the image.
Slightly related: https://redmine.darktable.org/issues/12234
#1 Updated by Christian Mandel about 1 year ago
I thought a bit more about that idea, and came to the conclusion that there is an easy part and a difficult one. The easy part would be to implement a factor of the original size. This could, in the UI, just be a text entry or a slider. A widget that computes and shows the resulting image size would be convenient. The benefit is that this does not interfere with changes in the crop. It would only require one additional entry in the xmp/data base, which is the scaling factor as a float number.
The other two ways to specify the scaling have the issue that they fail for strong crops, where you may even go below the specified output size. Therefore, for the other two options, the UI would have to reflect what it refers to, the original image size or the crop (a check box named “referred to the crop size” which is initially not checked, and an “upscaling allowed” check box.
The first, easy, solution would already help a lot, so the implementation of this feature would not have to go the entire way at a time.