Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cropping: occasional glitch in crop box #16831

Open
ralfbrown opened this issue May 19, 2024 · 8 comments
Open

cropping: occasional glitch in crop box #16831

ralfbrown opened this issue May 19, 2024 · 8 comments
Labels
priority: low core features work as expected, only secondary/optional features don't scope: UI user interface and interactions

Comments

@ralfbrown
Copy link
Collaborator

Describe the bug

When using a keyboard shortcut to adjust rotation while the crop box is displayed on the center image, the displayed box occasionally blips to a different aspect ratio and back to the correct size/position as the image is updated for the new rotation amount.

Steps to reproduce

Ensure that you have keyboard shortcuts bound to the rotation slider in the rotate and perspective module, and a keyboard shortcut to activate cropping. Also ensure that the automatic cropping in r&p is set to "original format".

bracketleft;alt=iop/ashift/rotation;up;*2.5
bracketright;alt=iop/ashift/rotation;down;*2.5
c=iop/crop
  1. Open an image in darkroom
  2. press the keyboard shortcut to activate cropping
  3. ensure that the selected aspect ratio for cropping differs noticeably from the image's aspect ratio (I was using 4:3 crop on 3:2 images)
  4. repeatedly press one of the rotation shortcut keys.

The glitch seems to happen only when cropping starts for the first time on an image, such that all four margin sliders show 0.0% (even though one margin is obviously nonzero). Usually the momentary display is at the image's aspect ratio, but I've also seen things that look like 16:9 (on my 3:2 images).

Expected behavior

the crop box should not be changing shape

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

self compiled

darktable version

recent (May 2024) masters, including 4.7.0+1246~gba9ce8eb15

What OS are you using?

Linux

What is the version of your OS?

Mageia

Describe your system?

AMD Threadripper 3970X (32C64T), 64 GB RAM

Are you using OpenCL GPU in darktable?

No

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

@ralfbrown ralfbrown added priority: low core features work as expected, only secondary/optional features don't scope: UI user interface and interactions labels May 19, 2024
@jenshannoschwalm
Copy link
Collaborator

This should be fixed by latest crop related commits. Can't reproduce here ...

@ralfbrown
Copy link
Collaborator Author

Still present in 4.7.0+1271~gf98eda41f0 (master as of right now). You may need to reset the crop module and then re-select an aspect ratio other than "freehand" or one matching the image's own aspect ratio to see the glitching. Seems to be present mostly when all four margin sliders show 0.0%.

@samwhaleIV
Copy link

This seems to be happening only at specific zoom levels. Do not think this is related to shortcuts or anything of the such. Happens to me on all photos. For example progressing through "fit," 47%, 52%, 57%, 63%, 69%, 76%, to 84%, the crop is accurate. But when I hit 92%, nope. The next level, 100%, and the result is fine.

From my testing, it isn't actually the numerical value of the zoom value that matters - it's just when the zoom level pushes the picture frame past the usable center area. So, your result will depend on how wide your UI/widget panels are. Some people might not encounter this at all Or, like me, I encounter it with every photo because I mostly keep my UI width the same and edit vertical photos.

Is this the issue you are experiencing? Notice the crop box stops reflecting the real crop. Adjusting the UI area while the cropping overlay is active and you are experiencing this "imprecision" issue moves its visual representation - which is definitely not supposed to be happening.

See the bottom right corner of this video for demonstration:
https://github.com/darktable-org/darktable/assets/8743262/52b6a04f-9259-4ae6-b6b9-37bcda7b2d3f

@ralfbrown
Copy link
Collaborator Author

That's not it - I have zoom at "fit to screen" when this happens, so the entire image is displayed. This is not a little imprecision I'm seeing - it's a major change in aspect ratio of the crop box even (especially) when adjusting only rotation. Like from 4:3 to 3:2 or even 16:9....

@samwhaleIV
Copy link

Darktable doesn't support the crop tool and perspective tool being used simultaneously. When you use the rotation adjustment during cropping, you move over to the perspective module. The perspective tool isn't aware of the aspect ratio you've chosen with the crop tool because it's processed before the crop is applied. The rotate and perspective module has cropping too, this might be why you are seeing the wrong aspect ratio. Is this what you're experiencing? Have you used Adobe Lightroom previously, where crop and rotate are shown together? Personally I've always found it rather annoying Darktable does crop and rotate separately, even if semantically the difference doesn't matter (rotation is a global operation).

@jenshannoschwalm
Copy link
Collaborator

Darktable doesn't support the crop tool and perspective tool being used simultaneously. When you use the rotation adjustment during cropping, you move over to the perspective module. The perspective tool isn't aware of the aspect ratio you've chosen with the crop tool because it's processed before the crop is applied. The rotate and perspective module has cropping too, this might be why you are seeing the wrong aspect ratio. Is this what you're experiencing?

This isn't the problem here and also the understanding is not "correct". The issue is about the both the cropping and ashift modules are "fighting" about the roi_in. BTW @ralfbrown i can reproduce, will see if we can do better here. The culprit is - as you likely guessed - the cropping module trying to keep the ratio, there is something wrong.

@samwhaleIV
Copy link

Any related recourse for the issue in the video I've provided above or is this a completely separate issue?

@jenshannoschwalm
Copy link
Collaborator

The wronggoing seems to happen in the crop post_expose, not sure why though.

Also - this seems to be related to ashift not working always correctly, at least with using keyboard shortcuts the calculation of "fit into original format" is not always correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: low core features work as expected, only secondary/optional features don't scope: UI user interface and interactions
Projects
None yet
Development

No branches or pull requests

3 participants