There are two modes append and overwrite…
Yes, when used in lighttable, but in darkroom mode Ctrl-V is always overwrite ( I think)
No I think not but I could be wrong…It is actually one of the things that I thought about requesting was to have the option to select the mode… But I think it follows what you set in lightroom…
EDIT confirmed at least on my version and all those I have used in the past…
If you are selecting original before you paste then you will essentially get a replace with append… but you can see the in append even in darkroom view. The pasted items will be appended after teh current position that you have in the history stack… so you can do both with append…
You are correct, I just tested it too.
I normally keep the lighttable setting on Overwrite, so I had never noticed it before
Well I added in my edit… above… append goes from where you are in the stack so if you select original before you paste you will get replace and if you move to some point in the stack your paste will follow that…so you can fully control it…
I’ve seen these messages with the recent windows build - see How cheap a GPU will still speed up darktable? - #53 by hannoschwalm but I’d basically concluded that it was a result of using the wrong OpenCL tuning for my system, as it only does it with certain settings. I’m using D&S too BTW.
Looks to me as if the issue is related to the mask defined within the colorbalance RBG module …
Linux, darktable 4.1.0+1201~g839b7f063 from this morning, NVidia 1060/6GB with v525 drivers.
I also get the errrors:
335.576071 [dt_opencl_enqueue_kernel_2d_with_local] kernel 24 on device 0: CL_INVALID_KERNEL_ARGS
335.576324 [opencl_blendop] couldn't enqueue kernel! CL_INVALID_KERNEL_ARGS
335.576328 [opencl_pixelpipe] [preview] could not run module `diffuse' on gpu. falling back to cpu path
335.771041 [dev_pixelpipe] took 0.270 secs (2.253 CPU) [preview] processed `diffuse or sharpen 1' on CPU, blended on CPU
335.773958 [dt_opencl_enqueue_kernel_2d_with_local] kernel 24 on device 0: CL_INVALID_KERNEL_ARGS
335.774216 [opencl_blendop] couldn't enqueue kernel! CL_INVALID_KERNEL_ARGS
335.774221 [opencl_pixelpipe] [preview] could not run module `colorbalancergb' on gpu. falling back to cpu path
Interestingly, color balance rgb shows no mask used, but I still get the error:
The error goes away if I switch from the application mode from drawn mask to off or uniformly.
However, even then, a problem remains: if I go to mask manager, remove the shapes from the groups, I cannot delete them. cleanup unused shapes does nothing:
brush #1 is the original shape used in the image; _circle #1 _ is one I added to color balance rgb. As you can see, neither is active. If I duplicate them, I can clean up the duplicates, but the original ones remain:
I think 123sg Steven points to the right issue and the thread by hannoschwalm explains things clearly - the exact module complaining about running out of resources is just a symptom.
If I turn off opencl tuning then performance returns to its previous speedy level
Kofa, I’ve had that problem with deleting masks for several months, however, its only been a nuisance rather than a showstopper.
Yes indeed - but no criticism of dev team is intended. Stuff happens, and I am eternally grateful that it gets fixed so promptly!
couldn't enqueue kernel! CL_INVALID_KERNEL_ARGS
That’s a different error, I think.
While the debug options are turned on, here is another group of errors that are showing up on images where I have simply applied my standard style:
[dt_ioppr_check_duplicate_iop_order] modules denoiseprofile (9) and denoiseprofile (9) have the same iop_order
[dt_ioppr_check_duplicate_iop_order] modules exposure (22) and exposure (22) have the same iop_order
[dt_ioppr_check_duplicate_iop_order] modules channelmixerrgb (31) and channelmixerrgb (31) have the same iop_order
[dt_ioppr_check_duplicate_iop_order] modules diffuse (32) and diffuse AA Filter(32) have the same iop_order
[dt_ioppr_check_duplicate_iop_order] modules colorbalancergb (52) and colorbalancergb (52) have the same iop_order
[dt_ioppr_check_duplicate_iop_order] modules filmicrgb (58) and filmicrgb (58) have the same iop_order
[dt_ioppr_check_iop_order] module denoiseprofile (0)(9) and denoiseprofile (0)(9) have the same order image 0 (dt_dev_pop_history_items_ext end)
[dt_ioppr_check_iop_order] module exposure (0)(22) and exposure (0)(22) have the same order image 0 (dt_dev_pop_history_items_ext end)
[dt_ioppr_check_iop_order] module channelmixerrgb (0)(31) and channelmixerrgb (0)(31) have the same order image 0 (dt_dev_pop_history_items_ext end)
[dt_ioppr_check_iop_order] module diffuse AA Filter(0)(32) and diffuse (0)(32) have the same order image 0 (dt_dev_pop_history_items_ext end)
[dt_ioppr_check_iop_order] module colorbalancergb (0)(52) and colorbalancergb (0)(52) have the same order image 0 (dt_dev_pop_history_items_ext end)
[dt_ioppr_check_iop_order] module filmicrgb (0)(58) and filmicrgb (0)(58) have the same order image 0 (dt_dev_pop_history_items_ext end)
I managed to narrow it down to a minimal XMP. Can be reproduced using other raw files, too.
DSC_9619_01.NEF.xmp (6.4 KB)
(It’s based on ER6_3846.CR3.xmp from Did something change inside the nightly build of Diffuse or Sharpen module? - #9 by Aliks, but I applied it to a different raw, just to double-check.)
2 Likes
Linux Mint 20.3 ; NVIDIA GeForce RTX 3060/PCIe/SSE2 v: 4.6.0 NVIDIA 510.108.03
Thanks. I recently upgraded to driver 525. Will try reverting to 470, which I’d used before that.
520 is running stable here.
All: the issue has been fixed, and the fix is available on master (Fixing #13120 by jenshannoschwalm · Pull Request #13124 · darktable-org/darktable · GitHub). Thanks, @hannoschwalm, @dterrahe & @Pascal_Obry !