darktable 3.0.0rc0+82~g4c6df92a0
Describe the bug
When using the color/spot picker you are able to use it outside the image area. This produces (severe) unwanted results.
Depending on the module you try this with it (three examples):
The last two can be recovered by resetting the module.
To Reproduce
Use a 'picker', any picker, and click/select outside the image area.
Expected behavior
I expect nothing to happen. Click/select outside the image area should be ignored. As it is in version 2.6
Platform (please complete the following information):
EDIT: words
I confirm this
same dt-Version
very similar behavior here
I couldn't reproduce the crash/freeze with the exposure module on an image first imported by recent master, however, on a random image from further back in time the freeze happened as soon as I clicked on the picker button, without any further action (image view was showing the default "image-minus-edges" selection)... so there might be more going on with this one.
The situation with the gray value slider in filmic RGB is especially ugly; the resulting zero value is out of normal bounds, and the response of the black and white sliders is to go insane and hide their labels... the labels don't come back after gray is restored to a sane value, or even by reseting the module; the sliders must be double-clicked.
EDIT: this was mostly fixed with #3379
Stale issue message
Update after getting a Stale issue message in my in-box:
This issue is still relevant for the current dt versions. Just re-checked using:
Only one thing has changed since initially posting this issue: I haven't seen any crashes/freezes when testing to see if this is still relevant.
Just in case the initial description wasn't clear enough:
The picker can be used in the grey "border" area around the image (crossing the border itself is _not_ possible).
I asked Aurelien on IRC about the bot closing this issue even though activity has taken place. He said he disabled the bot and I was hoping that he would re-open this issue as well. Guess not.
Can somebody reopen it, this isn't solved and tags have been added.
It seems that just commenting is not enough to prevent auto-close - one has to remove no-issue-activity tag from the issue. Do you have permissions to do it?
IMHO it wasn't the best idea to enable this bot.
one has to remove no-issue-activity tag from the issue. Do you have permissions to do it?
I don't think I do. And if the bot is set up correctly I would think that a normal user shouldn't be able to do this.
IMHO it wasn't the best idea to enable this bot.
I agree. A good culling might be in order and certain issue's could/should be automatically closed but this particular bot needs to be tuned before it is let out of its box. Then again, this is just my 2c.....
one has to remove no-issue-activity tag from the issue. Do you have permissions to do it?
I don't think I do. And if the bot is set up correctly I would think that a normal user shouldn't be able to do this.
I don't think it has anything to do with a bot. Either you can modify labels in the issue or you don't. Do you have a cogwheel icon on the right where labels are?
Nope, no cogwheel. Just, in this case, 5 labels, nothing else.
Checked with 2 different browsers, just in case.
So it's very inconvenient - only developer can stop the issue from being closed.
@aurelienpierre, either disable this bot, or rewrite its logic. Having developer to do some manual action defeats the whole purpose of this automation. BTW, by removing a timeout for closing issue in config you haven't disabled it, it just reverted back to default setting, which is the same as it was before anyway. There is no way to disable auto-closing of the issues, but you can just specify a very large timeout (say a year).
@parafin ok, will do. Sorry about the inconvenience.
For people subscribed to all emails it is very difficult to spot the issues that one has logged and take necessary actions in the barrage of emails by the bot every day.
I've tried to follow code back to where it may cause problems. It seems that it's due to weird area clamping in color_picker_proxy.c but I can't find how it's bound to image area. With little bit of testing it seems that color picker area is bound between click-point and nearest image dimmension and you can't get past it (meaning that you can go from waaaay over corner to just about corner of image. any corner). this can be seen on all 6 screnshots (5th to show i can't get past top image corner and is bound by bottom corner despite me starting waay below bottom corner (like on 4th screenshot). Click without drag is possible on any area outside image (6th screenshot).




dragging from screenshot 4 location to screenshot 3 location shows area bound by image box:

clicking anywhere is possible (area is on the right - that small white dot)

Pinging @TurboGit since color_picker_proxy is mostly his work ;)
@TurboGit: probably to be closed as solved by last #4431 PR
Right, closing. Thanks for the notice.
Yup, solves all problems I've mentioned earlier, so darktable 3.1.0+793~ged4000535 works and one cannot pick area outside of image. There are some issues with zoom + picking near border area but I'd need to formulate proper test case.
Fashionable late to my own party, but: Yes, issue is solved.
Thanks all!
@TurboGit You still have this as todo in projects pipe reordering ...
Are you speaking of this:
https://github.com/darktable-org/darktable/projects/4
I did not create this (Aur茅lien did I suppose) and I just found about it now, that's why I was confused!
Right
Most helpful comment
It seems that just commenting is not enough to prevent auto-close - one has to remove no-issue-activity tag from the issue. Do you have permissions to do it?
IMHO it wasn't the best idea to enable this bot.