Darktable: Spot removal is incorrect if used with cropping

[BigSerpent]

If the source of spot removal appears outside cropping area, dt excludes it from the source of data. At preview stage of the crop and rotate module when the frame is visible but not applied everything looks good. But after cropping is applied, the sources outside cropping area are considered as non-existent.

[leclercj]

It will work if you invert the order of 'spot removal' and 'crop and rotate' operations.
In you case you need 'spot removal' before 'crop and rotate'
Use 'move up' on 'crop and rotate', or 'move down' on 'spot removal'

[Nilvus]

retouch module is better and more powerful module than spot removal (retouch has functions of spot removal and even more). You could also use this retouch module instead. For me, spot removal should be deprecated... I actually don't understand why this module is not deprecated.

[leclercj]

The same applies with 'retouch'. For this use case, you need to move it before 'crop and rotate'. This is not the default order.

[BigSerpent]

Is the current default operation order correct that it requires to reorder in such a trivial case?

[blitzgneisserin]

Is the current default operation order correct that it requires to reorder in such a trivial case?

apparently it isn't

I like the spot removal tool. It's simple, in many cases you don't need more. This is not very serious but it should be fixed eventually

[leclercj]

adding @aurelienpierre for this default iop order discussion

[c-h-r-i-s-t-i-a-n]

Yeah, Crop&Rotate should really be moved up in the pixlpipe.
Similar problem with the GD (gradual density) filter. Say you have a photo with the horizont in the middle and use the GD filter to darken the top half. Now crop so that the horizont is on 1/3 vertically.
Result: GD-filter is no longer alligned correctly.

[TurboGit]

I suppose this is a ROI computation which is wrong somewhere. The module should request more than just the current crop... Not sure if this is possible though.

[mchhil]

Yesterday I had issues with retouch and crop. Crop ended up having the retouched removed elements inside it, it was as if it wasnt seeing the retouch. I changed the order to work around it for now.

[leclercj]

One benefit to have crop early in the pipe is to improve the performance, stopping computing pixels out of the crop as soon as possible

I suppose this is a ROI computation which is wrong somewhere. The module should request more than just the current crop... Not sure if this is possible though.

In order to allow a module to 'request more than the current crop', we need as prerequisite the previous operations to process more that the current crop. This is equivalent to move the crop operation later in the pipe, isn't it?
I share the view that we should reconsider the default position of crop&rotate (and ashift)

[TurboGit]

I agree, we probably want to move back spot and retouch before the crop & ashift module.

@aurelienpierre : how does that sound?

We may want to try this for 3.0 final as the current order will break old edits !

[parafin]

How does it break old edits exactly? Or do you mean post-2.6 git master edits?

[aurelienpierre]

The rationale for retouch and spot removal being after crop & rotate and ashift modules is it will give you more latitude to find sampling areas for correction. If your image has a strong perspective deformation, you will need to correct areas by sampling textures very close to the destination, because texture will be more and more distorted as you move away. That can be very limiting, especially considering the retouch module doesn't allow you to rotate and rescale the samples.

The issues described here have to do with actual implementation, so it might be better to try to fix the modify_roi_in() and modify_roi_out() functions.

[TurboGit]

@parafin: if the spot removal source area is outside the cropped area then the tool will do nothing. It does not really break the old edits as the old edits will keep the old order, so I was wrong.

But on new edit it can be surprising. You use spot removal. You crop the image and if the source is not outside the spot removal does nothing.

[TurboGit]

@aurelienpierre : I don't think we can fix that actually. When in spot removal the crop already happens and so you cannot enlarge ROI. At least I did not find a solution...

[aurelienpierre]

When in spot removal the crop already happens and so you cannot enlarge ROI. At least I did not find a solution...

Enlarging the ROI is done pipe-wise by reading every IOP's modify_roi_in if I understand correctly. Let me check.

[parafin]

Yeah, ROI computation aren't really about getting data outside of the current crop, but for zooming in darkroom. I'm not sure if those functions can or should be abused for this use-case. I guess this is one of these times when iop re-order makes sense - different order is required for different situations. But I agree that for defaults it's better for crop to be after spot removal.

[kanyck]

Shouldn't Spot removal go before Transformation in the pixelpipe? I noticed that when I use the perspective correction, spot removal messes things up because it takes incorrect (modified by the Transformation module) coordinates. Moving it before Transformation fixes this.

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[rafalkrupinski]

Dear @github-actions, the problem still occurs in 3.0.2, don't close the issue just yet.

[Nilvus]

Dear @github-actions, the problem still occurs in 3.0.2, don't close the issue just yet.

Don't worry, it's a bot and this will not be closed until a year.