Export pipeline crashes on certain NEF files in the dehaze module

[fpottbaecker]

Describe the bug

I have a few images from a recent walk in a nicely illuminated park.
I processed them (mostly copying a set of module settings (including dehaze at default settings), plus minor adjustments).
Some of these images crash the export pipeline when they are exported, during the processing of the dehaze module (it seems). Not all images are affected.

Steps to reproduce

1. Open broken.NEF (attached) in darktable
2. Activate dehaze for the image (or use the attached sidecar)
3. Export the image

Expected behavior

darktable should export the image

Logfile | Screenshot | Screencast

The export freezes after the dehaze module (according to the logs).
Further exports are not possible. Cancelling the export requires two presses on the x in the list of tasks. Quitting darktable afterwards results in a non responding application (on macOS).

Attached are three scenarios:

• Exporting a working image and then a broken image (darktable-working_then_broken.log).
• Opening the image in darkroom, playing with settings, then exporting (darktable-darkroom_then_export.log)
• Exporting the image without dehaze works, with dehaze breaks (darktable-normal_then_dehaze.log)

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

darktable 5.0.0

What OS are you using?

Mac

What is the version of your OS?

macOS 14.7.1 (23H222)

Describe your system?

No response

Are you using OpenCL GPU in darktable?

I dont know

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

broken.zip
working.zip

[fpottbaecker]

If it helps, I identified another culprit without people in it, sidecar included: broken2.zip

[ptilopteri]

* Fabian Pottbäcker ***@***.***> [01-05-25 12:55]:

If it helps, I identified another culprit without people in it, sidecar included: [broken2.zip](https://github.com/user-attachments/files/18311146/broken2.zip)

downloaded, imported with xmp and exported w/o a problem openSUSE Tumbleweed VERSION="20250103 darktable 5.1.0+37~g1108e69877 1gb G04 Nvidia 32gb system memory i7 >14 years old -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

[jade-nl]

darktable doesn't crash on my side (stable 5.0.0), but the export process is "forever".

This one might be related to/ same as: #18113

I don't have the development version, so cannot check if the fix from 18113 works for this one.

[fpottbaecker]

Performance Issue does not occur for me with current nightly, which includes #18113.

So technically the main issue could be closed.
However, should I open a separate issue / edit this issue for the other problem (a hung export cannot really be cancelled and needs a darktable restart to work again)?

[jade-nl]

@fpottbaecker

I believe the hanging export is part of the issue. There's mention of it, the hanging, in #18113.

I see that behaviour as well. I can close darktable but I still have to hard kill a misbehaving process that stays alivel in 5.0.0.

Seems to me that it is safe to close this one if you do not see this behaviour any longer in the latest nightly build.

[fpottbaecker]

@jade-nl Okay, closing this, since it is resolved.

I still think another issue should track the dead export pipeline: If you run into this issue and try to cancel the export, you can do it, but you also cannot start a new one. Granted, the export pipeline should never crash, but at least to me it feels like the program should be able to recover from that more gracefully. But it is not high priority.