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

Drawn mask do not work #4217

Closed
jeanschneider opened this issue Feb 2, 2020 · 17 comments
Closed

Drawn mask do not work #4217

jeanschneider opened this issue Feb 2, 2020 · 17 comments
Assignees
Labels
Milestone

Comments

@jeanschneider
Copy link

@jeanschneider jeanschneider commented Feb 2, 2020

Describe the bug

When adding a drawn mask, the path is not added and the mask remains empty. By inverting the polarity in mask preview mode, the full image becomes yellow (meaning the path is not saved to the mask).

To Reproduce

  1. Go to any module
  2. Click on add drawn mask (or drawn+parametrc, it doesn't work either)
  3. Draw a random mask on the image (pencil or path or anything)
  4. The module has no effect
  5. When clicking on the yellow preview button, the image is black and white with no path added to the mask.

Expected behavior

The module should only take effect where the path has been drawn. When clicking on the button the path appears yellow.

Screenshots

image

The path does not appear yellow even though mask preview is turned on.

When inverting polarity :

image

Platform (please complete the following information):

  • Darktable Version: 3.0.0
  • OS: Manjaro linux + Gnome Desktop
  • OpenCL : No

Additional context

It was been working with previous versions. Both JPEG and RAWs do not work. Same with fresh edit.
Darktable version is the one on the manjaro repo.

Thanks for your great work on this amazing software ! :D

@Nilvus

This comment has been minimized.

Copy link
Contributor

@Nilvus Nilvus commented Feb 2, 2020

Seems quite similar to this one : #4084
So could you test with a fresh new darktablerc file (by saving and dropping yours, you will lost some prefs)

@TurboGit

This comment has been minimized.

Copy link
Member

@TurboGit TurboGit commented Feb 2, 2020

@Nilvus : Do we know why removing the darktablerc file could fix this ???? I know the code pretty well, but I really don't see why doing that would fix the issue ? I see on the first screenshot that the opacity is 0% but this should not behave as if there was not mask at all. Really strange.

@Nilvus

This comment has been minimized.

Copy link
Contributor

@Nilvus Nilvus commented Feb 2, 2020

@TurboGit : I don't know, it's just the solution related on this similar issue. It could of course be not really related to.

@jeanschneider

This comment has been minimized.

Copy link
Author

@jeanschneider jeanschneider commented Feb 2, 2020

I regenerated the darktablerc and indeed that fixed it. Thank you very much ! :)

@TurboGit By default the opacity was 0 but playing with the slider did not change anything.

I still have the copy of the old and broken darktablerc, do you want me to join it ?

@jenshannoschwalm

This comment has been minimized.

Copy link
Contributor

@jenshannoschwalm jenshannoschwalm commented Feb 3, 2020

I still have the copy of the old and broken darktablerc, do you want me to join it ?

yes please.

@elstoc

This comment has been minimized.

Copy link

@elstoc elstoc commented Feb 3, 2020

Think this might be related to the default opacity setting (plugins/darkroom/masks/opacity) in darktablerc (if you look at the top bar on the screenshots it shows opacity at 0% for the drawn mask). For some reason it resets to zero for some users. Updating it to 1 in darktablerc resolves the problem.

@jeanschneider I'm not sure what opacity slider you were changing but did you try ctrl-scroll while hovering over the mask. This changes the opacity of the mask. You may have been changing the opacity of the blend with the slider? I can't tell because you're screenshots aren't in English!

@jeanschneider

This comment has been minimized.

Copy link
Author

@jeanschneider jeanschneider commented Feb 3, 2020

Here it is, I copy pasted the darktablerc to this txt file.
darktablerc.txt

@elstoc Oh yeah I did not see this indication ! That's strange. I changed the opacity with the dedicated slider (in french "opacité du masque" ^^), which is visible on the secreenshots (value is 0.38). I can assure (though it's not visible) that the opacity of the blend was 100%, which makes sense since the whole image is 100% yellow when inverting polarity.

Also should I close the issue ?

@elstoc

This comment has been minimized.

Copy link

@elstoc elstoc commented Feb 3, 2020

Ok. Looking at your darktablrc it appears that the opacity setting is indeed set to zero and that must be what's causing the issue. This has happened to quite a few users following upgrade to darktable 3 (https://discuss.pixls.us/t/strange-behavior-of-drawn-mask/15735).

With regard to the multiple (three?) ways to set opacity I think I've got my head around it...

  1. You can set the opacity of individual shapes using ctrl-scroll while hovering over the shape. This opacity is displayed in the top bar. The issue here is that the opacity of the shape is being set to 0 (by default) by your darktablerc and means that the following two opacity settings have no effect.

  2. A mask may comprise one or more shapes and/or a parametric mask. You can set the opacity of the entire mask using the slider you have indicated (i.e. the one within the 'mask refinement' section).

  3. Finally, the mask (including the shape/mask opacities) is then combined with the module's parameters/functionality to produce an output image, which is then blended with the module input using the selected blend mode. You can also set the opacity of this blend. This is the opacity indicated above the mask settings.

I'd keep the issue open for now. It looks like it has impacted a few users and I seem to recall some who have had it happen more than once. I'd question what the use case is for shapes defaulting to an opacity other than 100% (what's the point of the setting in darktablerc?).

@TurboGit

This comment has been minimized.

Copy link
Member

@TurboGit TurboGit commented Feb 3, 2020

Ok, this is indeed the opacity setting. Fact is it is quite confusing but the screenshot above are just correct. 0% opacity the shape is not doing a selection, so inverting the selection means selecting everything. As I said confusing, I've been highly confused by this myself. I'll set the minimum opacity to 5%. I hope this will solve all issues about opacity we have recently seen!

@elstoc

This comment has been minimized.

Copy link

@elstoc elstoc commented Feb 3, 2020

Is it worth considering defaulting the opacity of new shapes to 100% and ignoring the setting in darktablerc? All of the other saved mask defaults seem to be shape-specific (i.e. preserving the dimensions of each drawn shape - which makes sense) but opacity is not and seems to apply to all new drawn shapes (regardless of whether it's a gradient, circle ellipse etc.).

I've also had my opacity stick at a non-zero value (because of darktablerc setting) which is equally annoying.

TurboGit added a commit to TurboGit/darktable that referenced this issue Feb 3, 2020
This has confused lot of people and having an opacity of 0% means no
effect anyway so better remove the shape.

Fixes darktable-org#4217.
@TurboGit

This comment has been minimized.

Copy link
Member

@TurboGit TurboGit commented Feb 3, 2020

Is it worth considering defaulting the opacity of new shapes to 100% and ignoring the setting in darktablerc?

No, this will be a pain really. When I want to add a shape at 50% I usually do that for many other shapes (this is especially true for the Retouch module).

@TurboGit

This comment has been minimized.

Copy link
Member

@TurboGit TurboGit commented Feb 3, 2020

I've also had my opacity stick at a non-zero value

What do you mean by non-zero here ?

@TurboGit TurboGit self-assigned this Feb 3, 2020
@TurboGit TurboGit added this to the 3.0.1 milestone Feb 3, 2020
@elstoc

This comment has been minimized.

Copy link

@elstoc elstoc commented Feb 3, 2020

I had a situation for a while where every shape I added defaulted to an opacity of 0.8 or thereabouts, so every time I added a new shape I had to push its opacity back up to 1.0 after creation. Once I found out the issue was in darktablerc I went into it and the opacity setting was set to 0.8 so I changed it to 1.0 and problem solved.

If it was working correctly I assume each new shape should have the same opacity as the last-added/edited one- i.e. if I create a shapeand push its opacity to 100%, the next shape I add should be 100% - but it wasn't working like this.

Edit: I take your point on the retouch module and I agree, but does this setting need to persist between editing sessions? Also I said mask where I meant shape and have corrected.

I can reproduce this in current master. Create a mask (with default opacity of 100%), change its opacity to 50%. Create a new mask and it has the same default opacity of 100%.

@TurboGit

This comment has been minimized.

Copy link
Member

@TurboGit TurboGit commented Feb 3, 2020

I take your point on the retouch module and I agree, but does this setting need to persist between editing sessions?

It does persists when changing the opacity during creation. But if you change the opacity of an already drawn shape then this opacity is not remembered. It is only applied to the active shape. If you create a new shape it will get the opacity set at creation time (ctrl-scroll before placing the shape).

Edit: that's the current behavior, I find it good what do you think?

@elstoc

This comment has been minimized.

Copy link

@elstoc elstoc commented Feb 3, 2020

Ah I didn't know that. Perhaps this indicates why users are getting this issue and being confused (certainly why I was confused). Maybe they're accidentally ctrl-scrolling before placing the shape (perhaps meaning to shift-scroll) and changing their default.

See #3740. I think part of this is the non-obvious location of the current mask opacity (in the top bar, which many users, myself included, leave hidden to maximise screen real-estate). Some sort of tooltip next to the mask showing current values might ease the confusion.

@TurboGit

This comment has been minimized.

Copy link
Member

@TurboGit TurboGit commented Feb 3, 2020

Yep! The top bar information should be moved somewhere else where it is always visible. This has been discussed, it will come at some point.

@elstoc

This comment has been minimized.

Copy link

@elstoc elstoc commented Feb 3, 2020

So perhaps the only issue was that maybe the darktable 3 upgrade reset this value to zero somehow and people didn't know how to put it back.

@TurboGit TurboGit closed this in c646d7e Feb 3, 2020
TurboGit added a commit that referenced this issue Feb 3, 2020
This has confused lot of people and having an opacity of 0% means no
effect anyway so better remove the shape.

Fixes #4217.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.