Markus D. Herrmann

> Effort to troubleshoot this by the user for the first use case - visualization - will be very significant. In fact, for a non-DICOM-savvy user, there will be no...

@fedorov I disagree. If an algorithm failed, then there should be no Segmentation instance. If the algorithm performed segmentation, then any segment that was evaluated should be included in the...

@fedorov If I understand correctly, then it is the challenge to distinguish between different instances of the same segment type that you are concerned about. I agree with you that...

> As implemented, it appears that legacy converter does not sort frames geometrically. Arguably, it should be the responsibility of the reader to sort them, but I wanted to confirm...

> commonly used viewers may not be robust to sort frames (as became evident from the early experience here rordenlab/dcm2niix#372 (comment) - neither Slicer, nor Horos, nor (by default) OsiriX...

> In defense of those applications, fixing those issues may involve dependencies in external libraries (e.g., ITK for Slicer), which may be non-trivial. Fair enough. As long as the objects...

> My $0.02 - highdicom should provide a set of SOPClass-aware utilities that allow sorting of frames in ways that may be useful to the consumer of multiframe instances. I'd...

> Very true - my thought would be that when converting to multiframe you could optionally apply a sorting method that might be needed to work around limitations of consuming...

@pieper I generally don't have any major concerns to expose additional retry parameters. The only thing we should keep in mind that we may want to change the implementation at...

> @hackermd, thoughts on allowing the user to pass an optional sequence of decorators which would wrap all of the http calls? would decouple the retry logic, streamline the addition...