If I just open an image with default exposure,filmic etc then I also don’t seem to have a problem.
It appears to be an issue once I have finished all the edits (couple of exposure, local contrast,colour balance etc) and then apply denoise at the end (which is my usual workflow)
Maybe its just the amount of stuff that’s gone on before and maybe now 4Gb RAM is really not enough anymore which I guess was always going to happen at some point
If it continues to be an issue I’ll just change the way I do things and get denoising done first, turn it off, continue with edits and then turn it on again just before export and DON’T zoom.
I just thought it was worth reporting in case it was a genuine issue or if other people were experiencing the same
I’m also on W10, 9 year old machine, 12 GB RAM. I could move the search radius slider to 30 and back to default, moving other sliders, changing to auto wavelet etc. without a crash.
Windows 10 - darktable 3.4 (8 gb RAM)
No crash whatosever while moving the sliders of the Noise (profiled) module.
Actually, darktable is quite stable even on my 5 years old laptop…
Hmm, not sure because it appears after quite a lot of edits, if I set to scratch then I lose the edits (if I understand correctly) and on new files ‘from scratch’ I don’t have an issue.
For example if I import a new image with just the ‘modern’ default (e.g filmic, exposure, color calibration) I don’t have a problem with denoise.
I can whack the search radius to 30, zoom in, whack the slider down again, zoom out, zoom in etc etc and all is good
It appears after a bit of editing using other modules and masks etc so some other editing either creates a bit of instability or running out of resources or its just a Monday!?!!
If anyone is interested I can post a bit of the XMP file that causes the issue
Okay while I’m trying that there is something else.
Does it matter if the images that cause problems were previously imported in 3.2?
They had not been edited but did contain some active modules e.g filmic etc
I then discarded the history on these in 3.4 and started editing from there
Started from scratch and edited a file - no problem (which is what I expected as I haven’t had issues with ‘new’ files just previously edited ones)
Went back to original set up, opened the problem file - no problem anymore - uuurrrgh - one of those things? A gentle memory leak as Olivier suggested? Windows update? Who knows
I have got to do a load more editing tomorrow so I’ll see what happens
Memory management on windows is not great. In theory the system should write other data to the windows page file (equivalent to the Linux swap), but if the chunk is too big, as it can be with image processing, or the system is too slow, then yes, a hard crash as the application is trying to use memory it doesn’t have.
The darktable recommendation for ram is at least 8GB for this reason.
Normally when an error condition occurs you should have a graceful handling of it, e.g., error message, etc. But it should not crash. Hard to know if in this case darktable is able to detect the problem before things go totally haywire.
Renamed darktable folder in appdata, renamed the original xmp. Opened darktable, imported same image as a new one and edited - no problems
Deleted the daarktable folder in appdata, copied original xmp file back, restarted darktable so now a fresh darktable but with original xmp - couldn’t get darktable to recognise the xmp file i.e. image not showing with correct edits - gave up
Put original darktable folder back in appdata and left original xmp file. Opened darktable (now in original state) edited the same problem image - no problems (this is the original set up that used to crash)
As I said I’ll keep an eye on it and try and diagnose it better
So, if you keep the whole original setup (config folder and xmp), remove the database entry from darktable (in lightroom) and then import it again (with the original xmp present), I wonder if it shows the symptoms of #2.
