Add a freehand crop option to the "rotate and perspective" module

[ytterx]

Is your feature request related to a problem? Please describe. I recently started using darktable as I wanted to use more free and opensource tools in my workflow. I'm by no means a pro in editing as I'm only doing it a few times a year during an event as a volunteer. We are trying to edit down hundreds of photo's within a 48 hour time frame, this is so we can post online, and be done with a full digital photoalbum when the event ends. This means that every minute editing is not taking more photos and missing parts of the ongoing event. Now, as i´m learning darktable I'm running into something that frustrates me and reduces my editing speed compared to my (very flawed) old way of using Photoshop.

Within Photoshop there is an option when you rotate to also crop at the same time. As long as you do your order of operations correctly this can greatly benefit editing speed as you only need one tool.

For me, a crop or rotate can heavily influence each other in terms of looks of the final image, allowing to do those things together improves flexibility on how the final result will look. This is hard to explain via text, I'll try to see if I can find an example of an image that can be cropped and rotated in different ways to show what I mean.

Describe the solution you'd like I would like to have a ¨freehand¨ option added to the cropping options in the "rotate and perspective" module. This should kind-of restore the option of the old (and now removed?) ¨crop and rotate¨.

Alternatives Unfortunately I cannot think of an alternative way of implementing this.

Additional context This was also suggested in #11035, but that issue was closed as for them the issue was more of an edge case. Reddit and the documentation mention the split was done due to the retouch module, which I'm not using.

[elstoc]

Reddit and the documentation mention the split was done due to the retouch module, which I'm not using.

It was one of the reasons, and of course the fact that you aren't using it doesn't mean others aren't (I certainly use it regularly). The other was that the old crop & rotate was a horrible piece of code trying to do too many things at once, and took way too much maintenance. The danger is that if we add freehand crop to rotate & perspective it starts becoming another spaghetti code nightmare - i.e. the thing we were trying to avoid in the first place. It's already quite big but the underlying algorithm seems pretty stable now as it's not been messed with much. Also, we do try to avoid duplicating identical functionality between modules.

One alternative would be to turn off auto-crop in the rotate & perspective module, then the crop module could be changed so that it can only crop within the visible area. Not sure how practical that is.

Personally, when using keyboard shortcuts to switch between the two modules, I really don't notice losing the combined functionality.

[dericke]

One alternative would be to turn off auto-crop in the rotate & perspective module, then the crop module could be changed so that it can only crop within the visible area. Not sure how practical that is.

I was thinking recently along the same lines. Rather than there being a second, inferior crop function located within the rotate and perspective module, I think it would ultimately be a UI improvement to remove cropping from that module entirely and add a toggle to the crop module that limits it to the visible area. Of course, that's probably much easier said than done...

[elstoc]

The difficulty here is that you introduce a fixed dependency between two modules, which we really try to avoid doing. I was more thinking of leaving the r&p module unchanged (so you can choose to disable auto-cropping or not) and then having an optional flag in the crop module to constrain to the visible area. The crop option could then be "sticky" (retained between edits) as the option in r&p already is.

However, I suspect that the edges are just filled with "black" when r&p crop is disabled, so possibly this "empty" part of the image is not easy to distinguish from "actual black pixels"

[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.