Crop preset add absolute size

[gitmatt19]

Currently I have a number of crop presets to crop to 4000x4000px, 3000x2000px etc for the Z9 camera, they all work but if I use the same presets on a Z6 or Z8 the crop sizes the presets use is different than what I set up, they are somehow related to image size.

I would like to see a checkbox added to the preset to always crop to the set size in pixels regardless of actual image source size so I can always get 3000x2000px and not have it somehow scaled based on the source image size.

[ralfbrown]

All editing in darktable is done using relative (to the image) coordinates -- if you open the Margins section in the Crop module, you'll see that the sliders are marked in percent. That's what allows styles to be used across different camera models.

If you need a specific pixel size, use the "set size" option while exporting.

[jenshannoschwalm]

If you need a specific pixel size, use the "set size" option while exporting.

... or keep using specific presets or styles for each camera, that would be 5minutes work per camera :-)

[gitmatt19]

The reason for the request is because I do birds in flight which means I crop the photos to correct for position in the frame etc, so margins and export are not things that will work for this. Also I have seen that either darktable updates and/or firmware changes have caused all of the presets I have to change sizes from what they were saved as. Darktable has no way that I see of entering the cropping size manually, only the very hard to get to the right size box.

[wpferguson]

4000px x 4000px is a ratio of 1:1 square. 3000px x 2000px is a ratio of 3:2. I guess what we don't understand is why it has to be an exact pixel count.

If I do a square crop, then export it at 4000x4000 pixels, doesn't that satisfy your requirement?

[gitmatt19]

We typically don't resize photos for wild life, only crop. Every picture varies in cropping. If a bird is flying towards me for a series of photos, the farthest photo may be cropped a lot and less so as it gets closer so doing sizing at export time does not seem like a good option as every photo is different. As for sizes and shapes its just a matter of trying to look more professional since where the photos get posted people see the exif and size and not having something in some human mind friendly boundary make people think you could not make the extra effort to make something look better ie 3000x2000 vs 3005x2002. That size part may not make technical sense but people do really see things like that. Also having a check box that allowed absolute sizing would fix the issue across all cameras and camera modes. FX and DX modes on the Z9 produce different size raw photos and the presets thus dont work the same even on the same camera when in another mode.

[wpferguson]

I now understand you're reasoning. Unfortunately the crop module doesn't work in exact pixel values. It works in percentages and ratios and those are applied to the image. That's why if I chose an aspect ratio of 3:2 and set the long side of my image to 6000 pixels the short side comes out at 4003. To get an exact 6000x4000 image I have to go to freehand mode and "nudge" it a little. Internally it's stored as percentages. If I save a preset that crops to the bottom right quarter of an image, then no matter what size image I load, when I apply the preset it will get cropped to the bottom right quarter. The pixel counts will be different but the same percentage of the image will be present after cropping.

In order to implement pixel exact cropping the module would probably have to be completely rewritten or a new module written.

[dterrahe]

In order to implement pixel exact cropping the module would probably have to be completely rewritten or a new module written

I'm not sure if that's really the case; a new "mode" could probably be introduced taking pixels instead of percentages. This could either be a purely UI issue (so that the module internally still used percentages) but that could mean that any roi changes earlier in the pipe could throw it off (and make the ui numbers not correspond to the real resulting pixel impact). Or it could be a real internal value (a new module version would need to be introduced to support it). This would probably need to be in terms of pixels in the original raw (rather than whatever size the pipe image happens to be) at that point (in order to avoid issues when resizing for export for example). I'm not sure if any module would have access to this information while it is being invoked by the pipe though. Also. saving this as a preset could lead to errors (when you cropped too many pixels in a high res original for the resulting preset to be applicable to a low res image). So corner cases/invalid input would need to be dealt with. And the conversion between pixels and percentages may need to happen multiple times (so could be tricky to get right).

If however someone were to look into this, it also would be worth looking at whether the crop module could be made rotation insensitive. At the moment, if you create an out-of-center crop and then change the orientation (which is an earlier module in the pipe) you end up with a completely different area of the image. If we were to store the crop relative to the original raw however, it should stay "in the same spot".

Of course this also has consequences for any other distorting modules in the pipe and could lead to very interesting/unexpected behavior, but for the simple case in the OP, where very little fancy processing would have been done, it could work. Maybe...

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.