HDR DNG Export to jpg problem

While exploring the functionality, I created a few HDR files in darktable.
First I was surprised to find that the created DNG files could only be opened in darktable. All the other programs I tried showed a black surface with many differently colored dots. Is this a known phenomenon?
Everything else worked like with normal raw files, except the exporting to jpg (exporting to tiff works fine).
Sometimes, with some edits, darktable just drops out of memory with no message, except for an entry in the log file (Magick: caught exception 0xC0000005 “Access violation”…). To make things complicated, it happens only with some edits (i. e. xmp files).
Sometimes with one HDR-DNG file one edit exports fine, and the other causes dt to crash. This has never happened with regular raw or tiff files.
Has anybody experienced something similar - maybe there is a possible solution?

My setup:
darktable 4.6.0
Windows 11

What are your resource settings? (That should not cause a difference between TIFF and JPG, but is worth checking.)

Such issues have come up a few times, with that "Magick: caught exception 0xC0000005 “Access violation”. And only under Windows, afaik.
Tthe dt FAQ might help?

AFAIK the DNG files produced by dt are compliant to the specification. Please report any issues to other apps.

Thank you for your reply!
I checked various “Processing” settings (performance, Open CL) in various combinations. They have no influence on this behaviour, i. e. darktable crashes regardless of these settings.

Thank you for your response! Unfortunately in these documents do not help me with the issue.

Thank you for your reply!
At first I also thought the issue is in the other applications, but it is strange that all the applications I tried (see the list below) exhibited the same behaviour. It is difficult to assume, that all these applications are doing something not conforming to the DNG specifications.

here the list (some free/open source and some commercial):

Irfanview (latest version, 64bit, all plugins installed)
XNView (latest version, extended)
XNView MP (latest version, extended)
Faststone viewer (latest version)
Skylum Aurora (latest version)
Skylum Luminar (various versions, including latest Luminar Neo)
On1 Photo RAW (latest version “MAX” 2024)
Affinity Photo 2 (latest version 2.3.1)
Gimp (latest, 2.10.36)
Silkypix 7 (last available)
Rawtherapee (latest official, 5.9)
Pentax DCU 5 (latest version)

Can you share a specific file that triggers the issue, along with the exact settings for the export module?

I think the relevant part is about the openCL compatibility app, which seems to be automatically installed in certain cases. Some managed to get rid of the problem by removing that app.

I’m not sure what the effect of disabling openCL in darktable would be, but for mlost of the other settings I wouldn’t expect any influence on the behaviour in this respect.

Disclaimer: I’n not using MS-windows.

Sure, no problem:
Vrsic_181104_135633_0067_J_R00-hdr.dng (60.8 MB)
Vrsic_181104_135633_0067_J_R00-hdr.dng.xmp (12.3 KB)
Vrsic_181104_135633_0067_J_R00-hdr_01.dng.xmp (17.8 KB)
and the Export settings:
image

One of the XMP files causes the crash, the other does not.
Btw. how do i associate a XMP to the particular image (raw, dng, tif, …) file in case of multiple instances?

Disabling the OpenCL also has no effect on the behaviour …

Ok, will double-check, thanks for sharing the file.

Edit: There might be something to it after all, thanks for the discovery!

The default naming scheme for sidecars should take care of that:

  • <name>.jpg file → <name>.jpg.xmp sidecar
  • <name>.tif file → <name>.tif.xmp sidecar

etc.

Via load sidecar file:
https://darktable-org.github.io/dtdocs/en/module-reference/utility-modules/lighttable/history-stack/

:smiley: two interpretations of the question… We’ll see what OP meant to ask :wink:

A bit more serious, if indeed you want to apply a sidecar to an image, that not all operations can be applied to non-raw files. I have no idea what happens when you apply a sidecar for a raw file to a jpg…

Yes the FAQ does help you. They provide you with the instructions on how to produce a -d common log of your crash.

Is the HDR a dng file you import into darktable from another software before exporting?

Can you try updating the WhiteLevel tag and try again in other software please? Something like exiftool -IFD0:WhiteLevel=1 Vrsic_181104_135633_0067_J_R00-hdr.dng? (Note that a backup .dng_original will be created.)

Tried to do that, but no effect. In some applications the patterns shown are a bit different …

I believe there is a bit of a misunderstanding here. Perhaps my question regarding the xmp file identification has not been clear enough.

I have three files on the disk:
Vrsic_181104_135633_0067_J_R00-hdr.dng
Vrsic_181104_135633_0067_J_R00-hdr.dng.xmp
Vrsic_181104_135633_0067_J_R00-hdr_01.dng.xmp

When viewed in dt lighttable I have two images (duplicates) with different editing. Both images (in lighttable) have the same name. How do I identify which XMP file belongs to each of the images in lighttable?

The original file gets whatever.ext.xmp; subsequent duplicates are given increasing numberic suffixes, the first duplicate being 01, the 2nd 02 and so on. Even if you remove (delete) duplicates, the numbering carries on, so it’s possible that you end up with whatever_05.ext.xmp and whatever_10.ext.xmp on the disk, if you removed everything but the 5th and 10th duplicate.