fix(dicom-loader): Correctly merge shared and per-frame functional groups for wadouri imageLoader

[olhalit]

Context

This change addresses a critical issue in the WADO-URI loader where DICOM metadata was being incorrectly merged, leading to data loss.

The root cause is the shallow merge strategy used in combineFrameInstanceDataset when combining SharedFunctionalGroupsSequence (x52009229) and PerFrameFunctionalGroupsSequence (x52009230).

When a nested sequence (e.g., PlaneOrientationSequence) exists in both the shared and per-frame groups, the per-frame version would completely overwrite the shared version.
If the per-frame sequence was missing some tags that were present in the shared one, those tags were lost.

This PR fixes the merging logic to ensure that no metadata is lost and that the frame-specific DataSet is correctly constructed.

Changes & Results

Changes

• Added deepMergeElements function: A new private function has been introduced to
  perform a recursive (deep) merge of DICOM element objects.
• Updated Merge Logic: The core logic in combineFrameInstanceDataset was updated to use
  deepMergeElements. Instead of a shallow merge that overwrites entire sequences, the new
  logic correctly merges nested elements within sequences.
• Preserved Attribute Priority: The implementation ensures that attributes from
  PerFrameFunctionalGroupsSequence correctly override those from
  SharedFunctionalGroupsSequence at every level of nesting, as intended by the DICOM
  standard.

Results

• Before: A shallow merge was causing the PerFrameFunctionalGroupsSequence to completely
  overwrite the SharedFunctionalGroupsSequence for tags that existed in both. This led to
  a loss of nested metadata attributes that were present only in the shared sequence.
• After: The new deep merge logic correctly combines the shared and per-frame functional
  groups. Attributes from the per-frame group augment and override the shared group's
  attributes without data loss. The resulting DataSet for each frame is now complete and
  accurate.

Testing

The changes were manually tested using a real-world DICOM file that originally exposed the
metadata merging bug.

1. Test Data:

   • The test was performed with a multi-frame DICOM file that contains both
     SharedFunctionalGroupsSequence (x52009229) and PerFrameFunctionalGroupsSequence
     (x52009230).
   • This file's metadata includes a nested PixelValueTransformationSequence (x00289110)
     in both the shared and per-frame functional groups.
   • The issue was discovered because the PixelSpacing tag (x00280030) was present
     within this sequence in the SharedFunctionalGroupsSequence but was absent from the
     sequence in the PerFrameFunctionalGroupsSequence, which caused it to be lost after
     the previous shallow merge logic.

2. Test Procedure & Results:

   • The problematic DICOM file was loaded using the WADO-URI image loader.
   • The DataSet for a specific frame was then inspected after the image was fully
     loaded.
   • Verification: It was confirmed that the PixelSpacing tag is now correctly inherited
     from the shared PixelValueTransformationSequence and is present in the final
     merged metadata for the frame.

3. Regression Testing:

   • A suite of other standard single-frame and multi-frame DICOM images were also
     loaded successfully, confirming that these changes have not introduced any
     regressions into the standard image loading process.

Checklist

PR

• My Pull Request title is descriptive, accurate and follows the
  semantic-release format and guidelines.

Code

• My code has been well-documented (function documentation, inline comments,
  etc.)

Public Documentation Updates

• [] The documentation page has been updated as necessary for any public API
  additions or removals.

Tested Environment

• "OS: Ubuntu 24.04.2
• "Node version: 20.17.0
• "Browser: Chrome 139.0.7258.66

[sedghi]

Do you have the dicom data to share so that we can test?

[olhalit]

@sedghi Sure, I am sharing some Dicom files with you where this metadata issue is observed:
https://drive.google.com/file/d/1cNy-pLJ0crr0g4p0gctgDJdTT6jfY-Ut/view?usp=sharing

[rfitzfrey]

Hi, I'm respectfully wondering if this PR is lacking something? It's affecting our application so it's something I'm tracking.

[sedghi]

Sorry for the delay we will look