Thanks to the RawTherapee developers for this great program. There is just one annoying use case I don’t fully understand the reason for the ‘as is’ state and why I haven’t seen it reported as a bug. What’s the best way to help getting this done as a non-programmer? The functionality is non-intuitive and I haven’t seen it in any other graphics software:
Early on in developing I decide on a crop
Very late in development I try to mirror or rotate the image.
What I expect to happen is mirroring within the cropped picture. On a more technical level: The crop window coordinates should “stick” to the pixels below them, also needing some transformation.
In fact the order seems to be
Perform mirroring on the uncropped image
Crop coordinates are not affected, e. g. the crop that was on the left part of the image now contains pixels from the (mirrored) right part of the image. This typically is some unrelated, boring part of the image I wanted to get rid of.
Not unexpected.
In darktable, modules do not get information from other modules, other than the image itself (which they get from the immediately preceding module). “Crop” comes after “orientation” (where you can flip the image), and it applies the crop to the image it gets. But when you mirror the image, the crop module cannot know that that happened.
As formulated, the suggestion would be a bad one anyway: do you really want a crop to rotate or deform with the image (“rotate and perspective”, “lens correction”), resulting in an extra crop, or black surroundings (as images have to be rectangular in all image formats I know of)
that behaviour results from the default pixelpipe: such transformations are applied before crop by default (lower position of the module on the right panel) even if they’re made after cropping in users workflow.
have a look at darktable 4.6 user manual - the pixelpipe & module order - a basic understanding of the pixelpipe is mandatory to get expected results using darktable
