Decode HDR Latents reports success but writes no EXR sequence to the configured folder

Problem

DecodeHdrNode reports "Decoded successfully" in cases where it writes no EXR files at all, and when it does write them they can land outside the user's project directory. Either way the user is told the decode succeeded and then finds nothing at the path they configured in exr_output_folder.

Two distinct paths produce that same symptom:

1. EXR export is silently skipped. _save_exr_if_requested is only reached from the np.ndarray branches of _encode_video_output / _handle_image_output (decode_hdr_node.py:110, :124). When the driver returns PIL frames instead, both methods delegate to super() and return early — EXR export never runs, nothing is logged about it, and the node still reports success. A user whose latents didn't come from the HDR pipeline gets an MP4 and zero EXRs with no indication why.
2. Files are written to an unanchored path. _resolve_exr_output_path applies only Path(path_value).expanduser() (decode_hdr_node.py:170) — no .absolute() and no workspace anchoring, and expand_path_macros is a no-op unless the value contains {. A relative path therefore resolves against the engine process's CWD rather than the project, and the writer's out_dir.mkdir(parents=True, exist_ok=True) (utils/hdr_video_utils.py:46) silently creates it there. The sibling helper FilePathParameter.get_file_path() does call .absolute(); this node doesn't use it.

Desired outcome: when the node says it decoded successfully, the EXR sequence either exists at a path the user can predict from what they entered, or the node tells them plainly that no EXR sequence was written and why.

Origin

Reported by James Clarendon, relaying a community report: a user converting SDR to HDR locally with a custom diffusion setup found that the Decode HDR Latents node logged a successful decode but produced no .exr files at the folder configured on the node.

Impact

Silent data loss from the user's perspective — the expensive part of the workflow completes and its primary artifact is either missing or unfindable, with no error to act on. There is no way to tell the two causes apart from the node's own success message, so the failure is not self-diagnosable. It also blocks any downstream use of the sequence: encode_linear_hdr_exr_sequence returns the list of absolute paths it wrote (utils/hdr_video_utils.py:95) and _save_exr_if_requested discards them, so the written paths exist only inside the logs string and no output parameter carries them.

Repro / evidence

• Set exr_output_folder to a relative path on Decode HDR Latents and run a decode where the incoming latents were not produced by the HDR pipeline. The node logs a successful decode; no EXR files appear at the configured location and no warning is emitted.
• The node writes EXRs straight to the filesystem — OpenEXR.OutputFile(str(path), header) plus out_dir.mkdir(parents=True, exist_ok=True) (utils/hdr_video_utils.py:46, :71).
• Contributing confusion: docs/nodes/decode_hdr_latents.md documents the output filenames as frame_0000.exr, frame_0001.exr, … but the writer emits frame.0001.exr — dot separator, 1-indexed (utils/hdr_video_utils.py:70). A user checking for the documented filename would conclude nothing was written even in the case where the files are present.

Possible direction

One option, and not the decision: route the EXR write through the engine's file/project system rather than writing to disk from the node, the way SaveEXR in griptape-nodes-library-openexr builds a destination via ProjectFileParameter.build_file() and writes through WriteFileRequest. That would anchor the output in the project and remove the unanchored-relative-path case. Note that it does not by itself address the silent-skip case, which is about the node not surfacing that the HDR branch was never taken.