-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add feature "include dicom files" #1664
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Jose Raniery <[email protected]>
Signed-off-by: Jose Raniery <[email protected]>
Signed-off-by: Jose Raniery <[email protected]>
…n to include dicom files, if marked in settings, prior segmentation Signed-off-by: Jose Raniery <[email protected]>
…F402 error Signed-off-by: Jose Raniery <[email protected]>
Signed-off-by: Jose Raniery <[email protected]>
for more information, see https://pre-commit.ci
why docs build failing? otherwise changes r ok |
can @diazandr3s or @tangy5 run the plugin with these changes.. and see if functionality is working... |
/build |
👎 Promotion blocked, new vulnerability foundVulnerability report
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". |
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.mp4My 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:
Do you think NRRD firle format will help? What do you think @SachidanandAlle? Please let us know, |
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,
|
Thanks @jose-rfj. |
change to acl format (Project-MONAI#1706)
Signed-off-by: Jose Raniery <[email protected]>
…verhead Signed-off-by: Jose Raniery <[email protected]>
for more information, see https://pre-commit.ci Signed-off-by: Jose Raniery <[email protected]>
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.