Fliping orientation does not also flip the current crop

[emko]

*Updated
issue with moving crop under orientation was fixed but main issue of crop not taking into account what happens with the orientation module changes is still a issue

To Reproduce
add a crop
add orientation and flip the image
move crop module below orientation

Orientation should default above crop because anytime you want to flip you then have to adjust the crop, but in this case its not above crop. When you move crop below orientation it causes many bugs, you can't crop your image again as the red controls are no longer there, image gets glitchy and sometimes dt will crash.

Screencast
(https://streamable.com/ei16tr)

• darktable version : 3.8.1
• OS : Fedora 35
• Memory : 32gb
• Graphics card : 970
• Graphics driver : Nvidia

• Are the steps above reproducible with a fresh edit (i.e. after discarding history)? yes

[elstoc]

I think the issue here is a desire to use "flip" as a tool for testing composition while cropping so having flip affect the crop means it can't be used that way. Apart from feature duplication, are there any good reasons to avoid adding flip "back" into the crop module? (it used to be in crop & rotate)

Another question for @AlicVB

[AlicVB]

good news : I can reproduce the issue :)

@elstoc : to answer your request, I would say that we should keep the crop module as simple as possible. even with simple code it's not so easy to avoid bugs and strange situations here, so better avoid to reproduce a new "clipping" nightmare !

[elstoc]

Ok. Moving crop below orientation was an attempt to mitigate the original issue, and I'm not sure was advisable. So presumably the fix needs to allow flip to be used in its current pipe position without impacting the crop (so that crop continues to select the same area of the image regardless of the flip)

[AlicVB]

After some more tests and code review, that's quite tricky : in fact the crop zone is defined in % of the image at the crop module entry, so all distortion that happen before the crop module will change the crop area :( If we want to avoid that we have no other choices than to define the crop with the initial image as reference.
imho that would be better, but the question as usual is what will be broken by such a change...

oh and currently moving crop before other distort module produce lot of issues (like the one mentioned here).

So what I would propose :

1. forbid crop to be moved before distort modules (@TurboGit : I've never done that. do you think it's easy to do ? for 4.0 ?)
2. for 4.2 : evaluate a move to initial image reference

What do you think ?

[elstoc]

forbid crop to be moved before distort modules

there is already some code to prevent movements the other way: you can't move orientation above crop but you can move crop below orientation, which seems inconsistent.

[jenshannoschwalm]

Don't we just require a rule for the crop and rotate&perspective modules added to

darktable/src/common/iop_order.c

Line 455 in a18cfc3

GList *dt_ioppr_get_iop_order_rules()

[TurboGit]

1. forbid crop to be moved before distort modules (@TurboGit : I've never done that. do you think it's easy to do ? for 4.0 ?)

I'll assign this to me and will try to do that for 4.0.

[TurboGit]

Don't we just require a rule for the crop and rotate&perspective modules added to

Yes probably. Will do that.

[TurboGit]

See #11643.

[TurboGit]

Reopened as a partial fix only.

[dterrahe]

Possibly this issue could be renamed to better reflect the missing functionality, because the action initially causing problems can no longer be performed?