Tentative fix for issue #19135: Mask points misaligned when zoomed in while cropping to fixed ratio

[masterpiga]

@jenshannoschwalm @TurboGit

With Claude's help I might have a fix #19135. I tested in on a couple of images and it works for me:

Screen.Recording.2026-03-17.at.07.21.21.mp4

Find below Claude's analysis, which seems reasonable to me but certainly @jenshannoschwalm will know better.

Root Cause

crop.c's distort_transform and distort_backtransform computed the crop offset using floating-point arithmetic:

const float crop_left = piece->buf_in.width * d->cx;  // float: e.g. 600.6

But modify_roi_out — which defines the actual pipeline crop offset — uses integer truncation:

roi_out->x = MAX(0, (int)(roi_in->width * d->cx));  // int: e.g. 600

This discrepancy (fract(buf_in.width * cx)) means the distort functions report a slightly different crop position than what the pipeline actually processes. The mismatch is always sub-pixel in full-res coordinates, but becomes visible at higher zoom levels because the coordinate system is effectively magnified.

A second, larger problem affects fixed-ratio crops on export pipelines: modify_roi_out adds an alignment correction (dw/2, dh/2) to ensure exact codec-required dimensions — but the distort functions completely ignored this, causing the mask to be applied at the wrong position during export.

Fix (src/iop/crop.c)

Applied the same pattern already used by clipping.c (which has this exact problem documented in comments):

Use factor = 100 for preview pipes to reduce the integer rounding error from up to 1 pixel to < 0.01 pixels
Call modify_roi_out directly with the scaled buf_in to compute the crop offset — this ensures the distort functions use the exact same offset as the pipeline, including alignment corrections for fixed-ratio export crops
The fix makes both distort_transform and distort_backtransform consistent with modify_roi_out in all pipeline types.

[jenshannoschwalm]

Yes, @dterrahe already had hinted at this. After enlarging preview pipe dimensions this is far less irritating but yes ...

[TurboGit]

Note also that the issue is also present without any crop, so it is more general.

[masterpiga]

What about now? I Tested with a 6022x4024 image and cannot reproduce the bug.

Bug 2: mipmap integer-truncation vs Cairo float coordinate mismatch (the general issue)

File: (src/develop/masks.h)

dt_masks_get_image_size returned preview->backbuf_width (integer, e.g., 1003 for a 6022px image at iscale=6), but the Cairo darkroom canvas uses full.pipe->processed_width / iscale = 1003.67 (float). Every mask node — across all mask types, with or without crop — was placed in a slightly wrong coordinate space. At 1600% zoom this 0.067% scale error becomes ~50–60 screen pixels of misalignment.

This explains why 6000×4000 works (6000/6 = 1000.0, exact) and 6022×4024 doesn't (6022/6 = 1003.67, truncated to 1003).

Fix: changed dt_masks_get_image_size to return full.pipe->processed_width / iscale (float) and full.pipe->iwidth / iscale (float), matching exactly the Cairo coordinate system, with a fallback to the old integer values if full.pipe hasn't been processed yet.

Screen.Recording.2026-03-17.at.13.32.36.mp4

@jenshannoschwalm @TurboGit

[jenshannoschwalm]

Well this is the track, basically a mismatch between dimension/offset calculation. Not absolutely sure from memory if mask coordinates are related to "original dimension" so rawprepare displacers have to be respected. Don't remember my findings when investigating this the last time.

[masterpiga]

@jenshannoschwalm @TurboGit

I think the fix is the right one. This is the same image without the fix (master head), you can clearly see that the node snaps when the pointer is away from it:

Screen.Recording.2026-03-17.at.15.18.49.mp4

To clarify, this is with or without crop, it's the general fix that you were talking about.

[jenshannoschwalm]

What happens if you keep the mask you just created , do some stronger displacement in rawprepare, add a lens or remove it, do a crop, close dt and try again selecting nodes :-)

[masterpiga]

It works @jenshannoschwalm , I can't break it :)

Screen.Recording.2026-03-17.at.15.57.21.mp4

[TurboGit]

That's a very good improvement, but I'm sorry for bringing bad news about "not breaking it" in this :) This is very dependent on the size of the image.

Take my TIFF (6022 x 4024):

https://drive.google.com/file/d/1X1AIuoKPCVidhhEd6D8QEgq_Ut6TJdJN/view?usp=sharing

And look at the demo:

• Zoom 1600
• Create a simple path mask 3 points, one on the last black dot
• See that when creating there is an offset
• Fly over the dots, all perfect and this was not the case so here the PR is working as expected
• Now, try dragging the point over the black dot, see that as soon as you start to drag there is an offset between the point and the mouse pointer.

Capture.video.du.2026-03-17.17-09-35.mp4

[masterpiga]

That's a very good improvement, but I'm sorry for bringing bad news about "not breaking it" in this :) This is very dependent on the size of the image.

🤣 Damn it, you broke it! Let me try again, armed with your tiff :)

[masterpiga]

Ok, I did further progress and the drag misalignment is resolved.

There is only one issue that persists, which may or may not be related.

If I enable crop AND high quality processing is disabled, the mask jumps by a few pixels. The whole mask is repositioned. The alignment between nodes and cursor is retained, including during drag:

Screen.Recording.2026-03-17.at.20.02.58.mp4

This is not a regression, it happens also at master head. Is this a known issue? @jenshannoschwalm @TurboGit

[TurboGit]

This is not a regression, it happens also at master head. Is this a known issue?

Not known by me, enabling/disabling crop indeed shift the mask on current master too. Looks like another crop issue then?

[masterpiga]

I pushed the fix for the dragging issue. Would you like to break this too? 😅

Maybe the crop issue can be resolved independently.

[TurboGit]

I pushed the fix for the dragging issue. Would you like to break this too? 😅

I'll be more than happy to try... Let me have diner first, I need energy for this :)

[TurboGit]

Cannot break it... and this is a huge improvement! So what about merging this and handling the crop issue in another PR?

[masterpiga]

I think it makes sense to decouple the two issues 👍

[TurboGit]

Thanks!

A really nice job!

[masterpiga]

Happy to help, this bug was annoying me greatly!

Tomorrow I can look into the crop issue, feel free to assign it to me.