darktable-org
Increase culling mode zoom limit to facilitate easier culling on modern systems
Is your feature request related to a problem? Please describe. Coming from Capture One, where I've developed an easy way to cull photos by comparing all of them (up to 12 at a time), deselecting the sharpest image, and flagging the rest for deletion, i've struggled to replicate it in Darktable. I can compare images (albeit a bit slower to select) but I cannot pixel peep as easily, seeing as zooming is forcefully disabled over 4 images.
Describe the solution you'd like Increasing the limit for the culling mode zoom.
Alternatives Currently I'm importing my photos through Capture one, then switching back to my linux install, it works, but i'd rather I didn't have to. If there's something I've missed, let me know
Additional context This is how easy it is for me to compare for culling on capture one: https://github.com/user-attachments/assets/944c0bf6-9fa2-4a90-855f-386f18914550
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
You're more than welcome to contribute a fix.
Crazy, cause the issue isn't fixed yet
You may not have noticed, but in the last 60 days we built a release and released it. Now we concentrating on fixing bugs in the release.
As far as marking the issue as stale, that flags the issue so that it's brought to the developers attention again. It actually works well in this case since the issue was submitted when people were trying to get the release finished.
As far as the issue itself...
- I'm sure at this point no one knows how to implement it
- I'm not sure it can be implemented without large changes to the UI
- I'm sure it's not going to be fixed in 60 days.
I'm not knowledgeable enough to implement a fix for this. The attitude in my comment was towards the use of a bot to auto close issues, not towards this issue not getting attention.
the use of a bot to auto close
If we didn't use the bot then people would open an issue and if it didn't get picked up it would just sit there and most likely be forgotten about, other than by the submitter. The bot, at a minimum, resurfaces the issue at least twice. If someone comments, then the issue gets raised again in 60 days.
Our knowledge grows the more we do this and out interests may change, plus we also get new blood. So an issue that didn't interest us, or we didn't have an idea of how to solve, may get picked up the second, third, or fourth time around because we've grown and now we can figure it out.
As far as the issue itself...
* I'm sure at this point no one knows how to implement it * I'm not sure it can be implemented without large changes to the UI * I'm sure it's not going to be fixed in 60 days.
I am curious though, isn't the cap something that can be simply edited? Is the UI not responsive to account for more images?
Let me explain why the bot is useful.
You submit an issue. It may or may not get looked at.
After 60 days of no activity it gets flagged and a new email is generated saying there has been no activity for 60 days, but it gets put before the developers (and anybody that subscribes to the list) again to give them a second chance to look at it. After 300 more days of inactivity it gets flagged again and closed.
I've pulled several at the 300 days and closed, including one last week. I either didn't see them before, or I had no idea how to fix them. The one from last week I offered the OP a solution and he seems good with it. If the bot hadn't closed it, then it would be sitting and the OP wouldn't have a solution.
Right now there are 392 open issues. I don't think anyone is going to go thru all those issues looking for something to fix.
I am curious though, isn't the cap something that can be simply edited?
I don't think that it's that easy. @Solarer?
Is the UI not responsive to account for more images?
Depends on your hardware. I use a script with a timeout of 2 or 3 seconds. Another user told me they increased the timeout to 60 seconds because the script was on their old, slow laptop.
I'm just curious why the cap on zooming was hard capped instead of allowed to go as high as possible based on user hardware.
So that users didn't complain because their machine froze or darktable crashed when they zoomed too far (because they didn't have enough resources). If you don't think that's realistic, look at all the issues about darktable freezing with the blurs module when users set the radius too high, because it's not capped and probably should be.
EDIT: But then if you do cap it, you get issues wondering why it's capped. So, we can't win.
Could add a warning when going over a certain threshold that it's unstable and require users to acknowledge that before increasing it further. Funny enough I was about to comment on one of the blur issues, also on it being capped :D
If we had lots of hardware to test on, then we might be able to figure out "limits". But, we don't so we aim for what should work on most.
Could add a warning
We've tried that in the past. Then we removed the setting because no one thought it applied to them.
I think I know which setting you're referring to, but a non descriptive setting placed away from where the user might encounter its effects is different UX-wise from a prompt when the user hits the cap, which could be the current value of 4. Similar for blur. When the user is presented with the choice in response to an action they're doing, they'll more easily put 2 and 2 together. Ofc ideally the problematic action is also highlighted after, because many people have trained themselves to press "Yes" and not read prompts, but I think a general "<!> Performance might be degraded. Select fewer images to zoom through" could work
The problem is that we don't know where to put the warning. On you machine it will one place, on mine another. Everyone's machine is different with different workloads, different memory, different CPU, different GPU, etc. We could weigh darktable down with a bunch of benchmarking code that runs on startup to see what your machine is capable of and then try and come up with reasonable settings based on that, but I don't think users want to wait a couple of minutes while their system is stress tested each time they start darktable.. And then you have the users like me who don't zoom during culling and don't use the blur's module, so we don't really care. :smile:
I would absolutely love to have more images to zoom, especially because with raw+jpg doubles only 2 images are supported.
Would it be possible to show the warning during the "loading spinner" while calculating the zoom?
So if you have a slow machine and 10 images selected for zooming, it will calculate 1 minute, and during this time there is the explanation popup displayed ("Please wait while calculating... Select fewer images for improved performance") with an option to cancel the operation.
If you have a good machine and 6 images selected, you won't even recognize the message because the loading spinner only shows for half a second
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.
Maybe the limit could 4 for by default and a setting for an arbitrary number be under a "risky settings" menu?
EDIT: I am dumb, you can do that already in $HOME/.config/darktable/darktablerc
