Visual dicom browser UI refactor

[Punzo]

Refactor DICOM browser to use model/view/delegate pattern for improved performance and maintainability

• Introduced new model, view, and delegate classes for patients, studies, and series to replace legacy item widgets.
• Significantly improved performance and scalability of the DICOM Visual Browser, especially with large datasets.
• Enhanced user experience with more responsive and flexible patient, study, and series browsing.

Ref Slicer PR: https://github.com/Slicer/Slicer/pull/8866 https://github.com/commontk/CTK/issues/1230 https://github.com/commontk/CTK/issues/1230#issuecomment-3402330952

video (I had to compress the video -> low quality):

https://github.com/user-attachments/assets/85d058a4-08f5-44d6-8cb9-a55f9a7d3afd

[Punzo]

@lassoan @jcfr

Few notes of things that I will address January next year.:

1. Qt6 compilation and testing
2. the speed of updateDisplayedFields from ctkDICOMDatabase https://github.com/commontk/CTK/blob/bb28fad455f9bafca0fefa53e30bd862041837d1/Libs/DICOM/Core/ctkDICOMDatabase.cpp#L3725

when importing a very large datasets (e.g. 150 GB subset from IDC with hundreds of patients) in https://github.com/commontk/CTK/blob/bb28fad455f9bafca0fefa53e30bd862041837d1/Libs/DICOM/Core/ctkDICOMIndexer.cpp#L134

the actual import is actually just a couple of minutes with both browsers, but then the update of the display fields can take up to 15 minutes (on a very high-end pc) which is not ideal. I am not familiar with this part of the code, so not sure how to optimize it now, but it needs to be fixed to allow importing large datasets from local disk. In January, I will have a look, but if anyone has some insight/feedback it would be very nice @pieper @cpinter .

3. support for custom schema for the dicom database, see: https://github.com/Slicer/Slicer/pull/8866#issuecomment-3569836027 https://github.com/Slicer/Slicer/pull/8866#issuecomment-3570207357

4. revisit the APIs for the two browsers and standardize as much as possible https://github.com/Slicer/Slicer/pull/8866#discussion_r2553974844

[pieper]

@Punzo I agree, the database field updates are critical but hard to understand. I never found a simple step-by-step description of how they work, so maybe we can either find one or have AI plus the original authors help us create one.

[lassoan]

@cpinter and I implemented the display tables. We are available to help or give any information. Display tables are needed because often you need to show information in the DICOM browser that is computed from various DICOM tags. For example, description of the series is not always stored the SeriesDescription DICOM tag, or you need to aggregate data from multiple tags (modalities in study), or store counts, or latest timestamp, etc.

[pieper]

Thanks @lassoan, yes, I agree the display tables logic is needed. What I never dug into enough to fully understand is when the updates are happening and how to keep from breaking them. I don't have a driving use case at the moment, but it would be great if we could figure out how to coordinate across optimizing imports, organizing extensions for different modalities, and incorporating code like highdicom. Maybe a good project week topic.

[lassoan]

The main pressing issue for me is that framesets are not supported. The browser should display framesets instead of series. But the frameset logic should be implemented in Python because very few people would contribute to DICOM processing logic if it is implemented in C++. In theory, highdicom could be a place for this (as a dicom package that is higher level than pydicom), but probably it would need to be a new, higher-level python package, with some plugin mechanism.