-
Notifications
You must be signed in to change notification settings - Fork 113
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
Fix/wadors seg creation #360
base: master
Are you sure you want to change the base?
Conversation
…create a segmentation Updates generateSegmentation to assume it will retrieve JSON Objects if image.data is empty
It fixes both the dataset retrieve from DICOMweb JSON object by separating file meta and retrieved the sourceImageMetadata from metaDataManager if there is no instance in metadataProvider
@pieper I signed up for the office hours next week but I'd appreciate it if you can look through the code and let us know if you see anything weird. And also I didn't know who to ask for a review, any ideas about who is active? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple suggestions, otherwise if it works it looks good to me.
It would be very good to figure out how to make a test though.
@@ -7,4 +7,3 @@ node_modules | |||
yarn-error.log | |||
yarn.lock | |||
.DS_Store | |||
build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this intentional? I think we want to keep these build files out of the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, that's how we tested it without releasing it. I wanted to keep it till we agree that it's ready to merge so that we can test it again
There may be people using this feature in the OHIF community so asking in the office hours makes sense. |
@pieper I think we should publish a 1.0 version of dcmjs without the adapters (as we took them outside) so that PRs similar to this happen to our external adapters |
That sounds very good to me. Do you have bandwidth to make a PR? |
I will look at it with @wayfarer3130 to see what changes should go to 1.0 |
@pieper we are using this as a fork but I wanted to ask my question here as we already have a discussion. I rebased the branch to get the latest changes. The changes that have been done with recent PRs in the patient name are causing some issues. Also as there is still development in the adapters part, I assume you decided not to remove those from dcmjs yet. Would you consider merging this? I'll join the office hours to discuss it if you would. |
Yes, it should be preserving the PersonName VR type since this change: #364. It should make things better by being lossless. Let us know if it's working for you as expected.
The adapters part should be dropped at some point, but I have no problem making them work in the meantime. @sedghi and @wayfarer3130 did you have a chance to look into a release plan? |
@pieper @sedghi - We haven't come up with a release plan for dcmjs to remove the adapters. There are a few things that would be useful to have for that. Would you consider having a second branch for a while to work on a next version release for some length of time - something with breaking changes in it, including:
Maybe: I think the plan should be to have a second branch for a half year or so to work on, then when that is stable, rename the current main branch to a v1 branch, and promote the new branch to main. |
Thanks @wayfarer3130
No urgency on my side, just want to be sure we have a way everyone can make progress without stepping on each others' toes.
This one has been an issue for a while. Originally the code did this automatically avoid the [0]'s cluttering the code, but it meant a lot of code to check VM which also clutters the application code. Also since the DICOM JSON Model has lists for all Values being consistent with that may be easier for people, but I think pydicom behaves in the way you propose. Whatever is decided on this one we should take care to be sure it's applied consistently.
Yes, this would be the time if anyone has suggestions. |
Hi @pieper, Ali Reza wants to keep the version in the cornerstone and wants us to contribute there. We'll work on that but it will take some time as there are a lot of changes. Meanwhile, we will have to keep using the fork. |
When it writes [Object object] it has ended up converting a JavaScript object into a simple string value on the JavaScript side of things - so probably trying to write a full object definition of patient name into a simple string value. |
Yes, this may need to be handled as a special case now. Perhaps by doing |
Thank you for your answers @wayfarer3130, @pieper. Shouldn't the part generating the DICOM 10 object/blob handle the change in the format of the PatientName to PN? Where should it be handled? DicomMetaDictionary.denaturalizeDataset()? |
@pieper, got it. There is no issues with [Object object] |
This PR contains the changes required to make dcmjs work with wadors loading mechanism for CornerstoneWadoImageLoader. It keeps the functionality same for wadouri and if the image.data is empty, it retrieves the required data/tags from the wadors metadata.
'build' folder is intentionally added for testing purposed. Should be removed before merge