Hi folks,
I am currently facing some questions regarding a Storage SCU implementation for a VL Endoscopic modality that should also support Secondary Capture storage in case the target remote peer/PACS can not handle the 'newer' VL Endoscopic IOD. One mate talked
about a possible implementation flow where such a modality would first open an assosciation with the remote peer only presenting Presentation Contexts based on the VL Endoscopic Image Abstract Syntax. In case the remote peer did not accept any of these
Presentation Contexts the modality would then transform the data object to the Secondary Capture IOD and open a second assoication presenting only Presentation Contexts based on the Secondary Capture Storage class.

So my questions/problems with this approach would be:
1. Would it not be a better approach to present a complete Presentation Context table with both VL Endoscopic and Secondary Capture abstract syntaxes on one assoication and convert the object on the fly if necessary? Avoding unnecessary assoication
requests that will always fail in case the remote peer really only supports SC storage.

2. Are there still a lot of storage SCPs lacking support for VL Endoscopic Image Storage?

I would really appreciate your feedback on this, especially with your experiences with PACS systems out in the wild.

Best regards,
Morty

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Morty

ad 1: Clearly yes. People sometimes exaggerate about the cost of DICOM assosication establishment, but it is of course more than zero. So establishing a second association would hardly be noticed by the user. But the approach to send one association
request to obtain the SOP class support by the SCP is the more mature solution and will not decrease interoperability.

ad 2: Hard to tell generically, and probably depending on the markets that you are targeting. What I can tell that as we receive it as an industry supplier for interoperability solutions is that in our perception storing surgery evidence in PACS came
much more into fashion in the past years, and general purpose PACS manufacturers who are not adapting to this "trend" may lose market share. These objects are not very complex, so supporting them is not a big deal implementation-wise.

HTH

Markus

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Markus,

thanks for your feedback. As you mentioned I find it the better solution to not pollute a network with unncessary assoicaiton requests even if the additional cost may not be that high.

Regarding point 2.: I would say the modality/market I am planing for is a VL Endoscopic Acquisition Modality for bronchoscopy. So clearly VL Endoscopic Image and Video Endoscopic Image IOD would be the main focus and Secondary Capture just the fallback
if the other are not supported by the remote peers. With that regard I am also planing to give the user of the modality the choice to select if image compression should be used or not when sending an image. This brings me to another question regarding
the case if image compression is in fact active on the device:

I would currently plan this case with the following clear Presentation Context table:
1. | VL Endoscopic Image Storage | JPEG_Baseline
3. | Secondary Capture Image Storage | JPEG_Baseline

Since I am not planing to keep the original uncompressed image file in case the image compression was enabled by the user and won't be able to decompress on the fly.
Would you say that this is valid with the standard? Especially since PS3.5 10.3 mentions that DICOM Default Transfer Syntax (uncompressed) may be offered only if the modality has access to the original pixel data, which in my case it would not have.

Best regards

Morty

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Morty,

10.3 does not say "only", so I think you would be fine offering the default TS as well for the compressed images. If the SCP does not support compression, there is no other way of transferring the images. In the case that you are decompressing for the
transfer, do not miss to set the Lossy Image Compression (0028,2110) attribute in the images to indicate that although the images are currently losslessly compressed, the pixel data has undergone a lossy compression. I.e. it should not be lossily
compressed again.

10.1 However says that you are not required to offer the default TS in your case:
"Both of these requirements, (a) and (b), are waived when the Application Entity sending the pixel data has only access to the pixel data in lossy compressed form or the pixel data in a lossless compressed form that is of such length that it cannot be
encoded in the Default Transfer Syntax, and a Transfer Syntax that uses a pixel data reference is not offered."

So the way you plan to build your presentation contexts is DICOM conformant.

madMorty schrieb am Dienstag, 28. September 2021 um 18:11:51 UTC+2:

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)