[Bug] Loading of DICOMs has changed order in 3.8

[salimkanoun]

Describe the Bug

See video for the same case,
The first loading is the current main branche
The second loading is the version before 2.0 conrestone upgrade
https://github.com/user-attachments/assets/add8bfe8-42fb-4e45-bf33-a5854d1a5376

I would be better to keep topToBottum and make it configurable,
The loading process probably needs some rethinking as previous loading feature such as InterleaveTopToButtom are now not accessible any,

Probably we need to define loading strategy :

• Globally in the app-config
• Per hanging protocol with customLoadStrategy, if defined it takes priority on the global setting.

The definition of the loading strategy should probably have 2 parameters defined separatly :

• The loading strategy : Interleave, Nth ....
• The orientation : Top to bottom, bottom To Top ....

Steps to Reproduce

Load image

The current behavior

bottom to top

The expected behavior

top to bottom

OS

linux

Node version

20

Browser

Chrome latest

[sedghi]

This seems to be related to htjtk and progressive rendering changes

if i do this it works properly

Most likely this PR
cornerstonejs/cornerstone3D#1471

[sedghi]

@wayfarer3130 I don't think the

imageRetrieveMetadataProvider.add(
      'volume',
      cornerstone.ProgressiveRetrieveImages.interleavedRetrieveStages
    );

plays nice with our custom strategies

I see we removed the

Do you know what is causing this regression?

I think the interleavedRetrieveConfiguration is per volume, but then at OHIF we have across volume interleave and that gets broken i guess if used together with this interleave progressive. I guess it makes sense since if HP defines a strategy for load, any per volume load should get ignored