[FR] Improve visibility of handles in drawn mask.

[difrkaguilar]

Is your feature request related to a problem? Please describe.

In many of my photo edits I make a lot of use of draw masks, even several masks on a single image. Something that happens to me is that I'm over 50 years old and my eyesight is exhausted, thanks to the use of prescription glasses I can continue with my work. In my case, having a 32" 4K monitor with 3840 x 2160 resolution, I often find it difficult to select the handlers in the draw masks in the image I am working on.

Describe the solution you'd like

These handles are not always active, only when the mouse passes or hovers over them, so I think it wouldn't be a bad thing if, when hovering over them to make modifications, they were a little larger than they currently are.

BTW I have created a layout specifically for the gradient mask with two additional handles, the start and finish compression, this is just an idea, because when using the scroll + Shift the compression changes the values in jumps, to be more precise go to the masks manager module menu and move the compression slider then holding down the Ctrl while using the mouse scroll. It is more intuitive if you enter these two handlers because visually and more quickly you can place the compression at the point where you want. It would also have the same level of interactivity as the other handlers.

I also put two additional handlers to modify the curvature without the need to use the mouse scroll or without having to go to the masks managers module. These two handlers would work only by placing the cursor over one of them and dragging until the desired curvature is achieved.

Alternatives

One solution would be to introduce a new option in the configuration window in darkroom/modules with the possibility to choose the size of the handler. (I particularly would not like this option as you developers yourselves are not in favor of cluttering the configuration window with options).

But I prefer another solution, a possibility would be to put in the global guide overlay settings popup the option to increase the size of the handles, as it is done now with the contrast option. This option would allow users to adjust the size of the handles to their liking.

Additional context

Draw masks without displaying the masks in yellow. The rotate mask handler is almost imperceptible.

Draw masks displaying the masks in yellow. The rotate mask handler is still almost imperceptible.

Draw masks displaying the handlers bigger than the actual size (this proposal shows the additional handlers for set the compression and curvature)

Popup menu with the option handlers size option

[ralfbrown]

You are talking about drawn masks - parametric masks do not have any on-image controls since they compute their effect strength based on the values of each individual pixel.

[difrkaguilar]

You are talking about drawn masks - parametric masks do not have any on-image controls since they compute their effect strength based on the values of each individual pixel.

Corrected the error. Thanks.

[TurboGit]

Draw masks without displaying the masks in yellow. The rotate mask handler is almost imperceptible.

That's why you can change the color of the drawn masks (all overlays in fact). Use Ctrl+O to change the color. But you probably know that and is only a workaround for the visibility issue. Looking at your screenshot it seems that the handler are not properly scaled for HDPI display.

[zisoft]

We had the same problem recently on macOS, where the OS always reports 72 DPI. It was fixed with #15845

[TurboGit]

It was fixed with #15845

So should be fixed since 4.6.0, seems like there is still an issue as reported here.

@difrkaguilar : Side question, is the size issue on all kind of masks?

[zisoft]

15845 was a macOS specific bugfix.

@difrkaguilar what is your OS?

[difrkaguilar]

is the size issue on all kind of masks?

Every draw mask have the same issue.

what is your OS?

OS: Fedora workstation release 37 (Thirty Seven) x86_64

[TurboGit]

@difrkaguilar : That's a screenshot of a fit view of darkroom, right?

[difrkaguilar]

This is the screenshot of the screen and the fit view of darkroom. Screen resolution 3840 x 2160 (16:9) scale 100%

[TurboGit]

And here is what I have on my HD screen 2560 x 1440 scale 100%:

Clearly more visible. What I also see on your screenshot is that the mouse cursor is very small. This is controlled outside of dt and clearly not what I have on my side.

[difrkaguilar]

I changed the scaling factor to 1.30

But now the text is big too.

[TurboGit]

Do you have screen_dpi_overwrite defined in darktablerc?

$ grep screen_dpi_overwrite ~/.config/darktable/darktablerc

[difrkaguilar]

screen_dpi_overwrite=-1.000000

[TurboGit]

Ok, so all good on this side. As I don't have a 4k monitor it is hard to debug this on my side.

[difrkaguilar]

Are you using Wayland?

X11 no Wayland.

OS: Fedora Linux release 37 (Thirty Seven) Workstation Edition x86_64 Host: Z390 AORUS MASTER Kernel: 6.2.7-200.fc37.x86_64 Uptime: 1 min Packages: 3122 (rpm), 32 (flatpak) Shell: zsh 5.9 Resolution: 3840x2160 Windowwing System: X11 DE: GNOME 43.9 WM: Mutter WM Theme: WhiteSur-Dark Theme: WhiteSur-Dark [GTK2/3] Icons: Mkos-Big-Sur [GTK2/3] Terminal: alacritty CPU: Intel i7-9700K (8) @ 4.900GHz GPU: NVIDIA GeForce GTX 1070 GPU: NVIDIA GeForce GTX 1080 Ti Memory: 2489MiB / 32012MiB

[difrkaguilar]

And what happens when you scale the display?

The handlers increase their size a bit, but the whole system increase the windows and everything become a mess.

This is an screenshot of the desktop. I scaled the display to 200% but have to set the Scaling Factor to 0.8 for the fonts. Anyway this is not an option for me, I use Blender and other apps and need screen space.

This is an screenshot of Blender at 3840 x 2160

[difrkaguilar]

Gnome only lets you pick 200%. I'm in fedora KDE and I pick fractional (125%).

That's good to know. But I use Gnome. I think I'm not the only darktable user with this problem. The vertex (vectors) or handles in some applications I think can be adjusted to different scales, not depending on the system, window manager or scale factor but by the applications if it's possible.

[TurboGit]

What if you set screen_dpi_overwrite to 72 in darktablerc? (you need to do that without dt running).

[difrkaguilar]

What if you set screen_dpi_overwrite to 72 in darktablerc?

I'll try this ASAP when return to home. Then I'll see and comment about it. Thanks.

[zisoft]

What if you set screen_dpi_overwrite to 72 in darktablerc?

The screen dpi is used to calculate the gui->dpi_factor by dividing the screen dpi by 96. 72 is the value macOS reports for the screen dpi, causing all GUI elements being shrinked by a factor of 0.75 (72/96) (fixed by #15845)

So setting screen_dpi_overwrite to a value > 96 should do the trick, but this will enlarge all elements of the GUI, including the fonts.

The macOS fix only changes the gui->dpi_factor which is used for control handles. gui->dpi is left as it is (72).

[difrkaguilar]

Set screen_dpi_overwrite to 72 or 96 in darktablerc doesn't fix the issue. So I'll continue working with handlers as they are now.

[difrkaguilar]

Excuse my lack of knowledge about programming, a series of functions that for some seem simple, I know that it is far from being so. I don't know the amount of code that is behind the visualization to draw these masks, but it must be quite complex.

It must be recognized that darktable's gradient mask drawing system is even more powerful than the possibilities of gradients that graphic design programs have, for example Inkscape, where it is not possible to make a bend to the gradient, but darktable's gradient masks allow it.

Reading a post similar to this one about the possibility of improving the drawing of gradient masks #14728 I make a proposal from my point of view of how the drawing of gradient masks could work in a more effective way than the one used right now.

The handlers that I describe here can further enhance the use of these gradient masks, giving more control to the user when positioning these masks in a finer way.

The handlers at the start and end of the masks can allow to change the compression of the mask by dragging and dropping the mouse. Likewise, the handlers located in the central line could allow to bend the line until the desired position is achieved.

This mask could be used in reverse, also as discussed in #14728 put two position handles at both ends of the center line, these handles at the ends can make the position of the gradient mask more accurate to be able to move indistinctly.

This is just an idea. Anyway I make this feature request in case there is any developer interested in implementing it or making other modifications.

Screenshot of the gradient draw mask.

Screenshot of the gradient draw mask in reverse position.

[Mark-64]

DT 4.6.1 on Windows 11, 4k display Scaling of mask handles looks correct to me.

[difrkaguilar]

darktable 4.7.0~git651.e458f34f-11391.1

Then the issue must be on my side, I don't know why. This is an screenshot at 3840 x 2160

[zisoft]

@difrkaguilar Do you have the possibility to compile and debug dt yourself?

If so, can you set a breakpoint in src/gui/gtk.c at line 1434:

https://github.com/darktable-org/darktable/blob/e458f34f45138f19c379fcd8945abcdc7068f65b/src/gui/gtk.c#L1422-L1443

and see what value gui->dpi gets.

[difrkaguilar]

Do you have the possibility to compile and debug dt yourself?

I don't have to much skills but I'll try to do my best.

[difrkaguilar]

Do you have the possibility to compile and debug dt yourself?

Ups... I tried but I don't have the skills to do those changes. So I'll have to continue working with draw masks as they are now. My fault. Thanks anyway to all for your attention and comments.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.