Add feature "include dicom files"

[jose-rfj]

First, I included the tag "model" in the dict "label_info" because I needed the name of the model that generated the label to be further saved.
Then, I included a checkBox in the plugin settings to enable dicom export between server and client. This feature is important because some models can use metadata included in the dicom header, such as slice thickness.
Finally, I added a function call to enable image upload right after segmentation is called, due to the same problem previously described.

[SachidanandAlle]

why docs build failing? otherwise changes r ok
@diazandr3s

[SachidanandAlle]

can @diazandr3s or @tangy5 run the plugin with these changes.. and see if functionality is working...
also please share some snapshots for this new feature

[YanxuanLiu]

/build

[github-actions]

👎 Promotion blocked, new vulnerability found

Vulnerability report

Component	Vulnerability	Description	Severity
Apache Ivy	CVE-2022-46751	Improper Restriction of XML External Entity Reference, XML Injection (aka Blind XPath Injection) vulnerability in Apache Software Foundation Apache Ivy.This issue affects any version of Apache Ivy prior to 2.5.2.

When Apache Ivy prior to 2.5.2 parses XML files - either its own configuration, Ivy files or Apache Maven POMs - it will allow downloading external document type definitions and expand any entity references contained therein when used.

This can be used to exfiltrate data, access resources only the machine running Ivy has access to or disturb the execution of Ivy in different ways.

Starting with Ivy 2.5.2 DTD processing is disabled by default except when parsing Maven POMs where the default is to allow DTD processing but only to include a DTD snippet shipping with Ivy that is needed to deal with existing Maven POMs that are not valid XML files but are nevertheless accepted by Maven. Access can be be made more lenient via newly introduced system properties where needed.

Users of Ivy prior to version 2.5.2 can use Java system properties to restrict processing of external DTDs, see the section about "JAXP Properties for External Access restrictions" inside Oracle's "Java API for XML Processing (JAXP) Security Guide".
|HIGH
Netty Project|CVE-2023-34462|Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. The SniHandler can allocate up to 16MB of heap for each channel during the TLS handshake. When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the SniHandler to allocate 16MB of heap. The SniHandler class is a handler that waits for the TLS handshake to configure a SslHandler according to the indicated server name by the ClientHello record. For this matter it allocates a ByteBuf using the value defined in the ClientHello record. Normally the value of the packet should be smaller than the handshake packet but there are not checks done here and the way the code is written, it is possible to craft a packet that makes the SslClientHelloHandler. This vulnerability has been fixed in version 4.1.94.Final.|MEDIUM
Netty Project|CVE-2023-44487|The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.|HIGH

[diazandr3s]

Hi @jose-rfj,

Sorry i'm just catching up on comments/PRs. Many thanks for your contribution.

I just tested your branch and recorded this video for reference:

dicom-files.mp4

My question is how could we manage the DICOM files stored in the JSON file? As you see in the video, the MONAI Label updates the JSON file and considers each dcm file as a new volume.

Additionally, it stores the converted nii.gz file for the DICOM itself.

Regarding this:

This feature is important because some models can use metadata included in the dicom header, such as slice thickness.

Do you think NRRD firle format will help? What do you think @SachidanandAlle?

Please let us know,

[jose-rfj]

Dear @diazandr3s

Thanks for reaching out. I actually updated locally the plugin to store only the first slice, as all of them store the same header, so only one is needed. How do I update that in here? Do I have to create another PR?

Cheers,
Raniery

Hi @jose-rfj,

Sorry i'm just catching up on comments/PRs. Many thanks for your contribution.

I just tested your branch and recorded this video for reference:

dicom-files.mp4
My question is how could we manage the DICOM files stored in the JSON file? As you see in the video, the MONAI Label updates the JSON file and considers each dcm file as a new volume.

Additionally, it stores the converted nii.gz file for the DICOM itself.

Regarding this:

This feature is important because some models can use metadata included in the dicom header, such as slice thickness.

Do you think NRRD firle format will help? What do you think @SachidanandAlle?

Please let us know,

[diazandr3s]

Dear @diazandr3s

Thanks for reaching out. I actually updated locally the plugin to store only the first slice, as all of them store the same header, so only one is needed. How do I update that in here? Do I have to create another PR?

Cheers, Raniery

Hi @jose-rfj,
Sorry i'm just catching up on comments/PRs. Many thanks for your contribution.
I just tested your branch and recorded this video for reference:
dicom-files.mp4
My question is how could we manage the DICOM files stored in the JSON file? As you see in the video, the MONAI Label updates the JSON file and considers each dcm file as a new volume.
Additionally, it stores the converted nii.gz file for the DICOM itself.
Regarding this:

This feature is important because some models can use metadata included in the dicom header, such as slice thickness.

Do you think NRRD firle format will help? What do you think @SachidanandAlle?
Please let us know,

Thanks @jose-rfj.
I guess you can update this PR. No need to create another one.
Let us know,