-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
darkroom display does not update when modules are applied. #18014
Comments
commit fe99016 is good and things work as they should |
tried to bisect but didn't come up with anything that made sense. I'll try before and after for each opencl commit and see if I can find it that way. |
What you describe could be a cache problem due to a wrongly calculated hash. As the opencl pipe does use less cache lines this could be more obvious because bad lines would "live longer". A bisect point would be #17906 for that case. |
My edits usually start with rotate and perspective as I like my images to be straight. Next I adjust exposure. I apply a style before I start with multiple module instances, but most are turned off except for the defaults. I would notice the problem with I adjusted the horizon and nothing moved. It was late and I had 2 other problems going on at the same time, so now I've sorted that out in my head and I think I can chase this problem. |
What debug flags should I run with to see if #17906 is the problem? I built a new environment to test with, but haven't been able to reproduce yet. I tried adding my style to use more cache lines, but still didn't trigger it. It might be a combination of style, and script which makes the changes fast enough that it might outrun the cache? I've thought of another way to test. |
I checked out the commit before and tested 12 images without a problem. I checked out a commit after (one of the translations) and the 3rd image had a problem. I did a rotate and perspective and nothing happened. I applied local contrast, colorbalancergb, d or s, and nothing happened. Then to make sure I did rotate and perspective again (right click and draw) and drew a 45 degree line., Instead of rotating, it zoomed. So, it seems the process is something like this:
It may be the apply final modules, move to new image and apply defaults, then apply style automatically, then try an edit. Too many things in to short a time. |
Some ideas:
|
The lua question is probably better for @dterrahe. I access them by name and instance using dt.gui.action. The top most module is instance 0, then the instance number increases by 1 as you go down the stack. For instance, in the style I included there are 4 Diffuse or Sharpen modules. The local contrast one is instance 0. The AA sharpen is instance 1. The denoise medium is instance 2 and denoise fine is instance 3. I don't think that is a problem though, since it seems to work and the history stack updates with the appropriate entries. I'll try the drag test. |
While I was experimenting (with -d pipe on) I saw the flashing working. I stopped the scrolling, copied a chunk, and started writing this. I just checked and it's still going. Seems to be caught in some kind of endless loop. |
I also forgot one thing in my processing description. When I hit spacebar to load the new image, I generate the thumbtable cache in background for the previous image. |
Here's a run from I'd just finished processing an image and was still in darkroom view. I hit the space bar, processed the next image, then hit the space bar and processed another image. |
These are "instance numbers". Different from the iop order numbers Hanno is referring to. |
How can I help testing this? I've just started with a clean config + DB, and a directory of 74 pristine images. I opened the first one, created a random style with local contrast, DoS, color balance rgb, contrast EQ and denoise (profiled), then assigned it a hotkey and stepped through all images in the darkroom, and applied the style. No problem (on master).
At first I had full-res processing disabled in the darkroom, then I enabled it about half way through. Update: I've now added 100 copies of the raw from https://discuss.pixls.us/t/how-do-i-satisfy-the-oe-warning/47734, which originally triggered my problem, used the same style (large and small resources, full-res enabled or not, even created a snapshot for comparison, zoomed in-out, panned), and I'm unable to reproduce it. I'll try with some masks. |
Describe the bug
While editing an image in darkroom mode the main display quits updating as edits are applied. The histogram does update.
Steps to reproduce
Expected behavior
display should update when edited
Logfile | Screenshot | Screencast
No response
Commit
No response
Where did you obtain darktable from?
downloaded from www.darktable.org
darktable version
git master 12/14
What OS are you using?
Linux
What is the version of your OS?
Ubuntu 22.04
Describe your system?
No response
Are you using OpenCL GPU in darktable?
Yes
If yes, what is the GPU card and driver?
Nvidia latest
Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip
On a hunch I turned off opencl and started editing images. Problem hasn't appeared after 10 images.
The hunch happened when I was looking for a likely commit to start bisecting from when I came across some of the opencl work, so I'm guessing that something in there isn't quite working as expected.
Another note. I'm using a final processing script that applies multiple modules (2 d or s, colorbalancergb, chromatic aberrations) one right after the other. I do check for pixelpipe complete to make sure one is complete before trying the next.
The last heavy editing session I did was 11/30 and I had no problems, so whatever changed was after that.
The text was updated successfully, but these errors were encountered: