[FR] Improve visibility of handles in drawn mask. about darktable HOT 31 OPEN

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

from darktable.

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.

from darktable.

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

from darktable.

@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:

and see what value gui->dpi gets.

from darktable.

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.

from darktable.

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.

from darktable.

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

from darktable.

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?

from darktable.

#15845 was a macOS specific bugfix.

@difrkaguilar what is your OS?

from darktable.

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

from darktable.

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

from darktable.

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

from darktable.

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.

from darktable.

I changed the scaling factor to 1.30

But now the text is big too.

from darktable.

Do you have screen_dpi_overwrite defined in darktablerc?

$ grep screen_dpi_overwrite ~/.config/darktable/darktablerc

from darktable.

screen_dpi_overwrite=-1.000000

from darktable.

Are you using Wayland? I think that screen is to scale the font, but what happens if you scale the screen display?

from darktable.

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

from darktable.

And what happens when you scale the display?

from darktable.

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

from darktable.

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

from darktable.

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.

from darktable.

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

from darktable.

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.

from darktable.

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).

from darktable.

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.

from darktable.

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.

from darktable.

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

from darktable.

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.

from darktable.

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.

from darktable.

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.

from darktable.