Create Dicom Series possoble improvement

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Create Dicom Series possoble improvement

Kevin Wang

Hi All,


Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that. 


so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?


Thanks,


Kevin


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

pinter

Hi Kevin,

 

I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html

 

Can you perform what you want with the new DICOM export?

 

csaba

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement

 

Hi All,

 

Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that. 

 

so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?

 

Thanks,

 

Kevin


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

lasso2

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.

 

Andras

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin,

 

I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html

 

Can you perform what you want with the new DICOM export?

 

csaba

 

From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement

 

Hi All,

 

Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that. 

 

so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?

 

Thanks,

 

Kevin


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Kevin Wang

Hi Andras and Csaba,


I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level. 


so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work. 


I hope I made it clear. if not, let me know.


Thanks,


Kevin



On January 26, 2015 at 4:34 PM Andras Lasso <[hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.

 

Andras

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin,

 

I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html

 

Can you perform what you want with the new DICOM export?

 

csaba

 

From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement

 

Hi All,

 

Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that. 

 

so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?

 

Thanks,

 

Kevin


 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Steve Pieper-2
Hi Kevin - 

I agree, adding features to the current CLI will be helpful given the current implementation of the export process.  I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects.  I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

-Steve

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang <[hidden email]> wrote:

Hi Andras and Csaba,


I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level. 


so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work. 


I hope I made it clear. if not, let me know.


Thanks,


Kevin



On January 26, 2015 at 4:34 PM Andras Lasso <[hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.

 

Andras

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin,

 

I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html

 

Can you perform what you want with the new DICOM export?

 

csaba

 

From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement

 

Hi All,

 

Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that. 

 

so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?

 

Thanks,

 

Kevin


 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.



_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Kevin Wang

Hi Steve,


Thanks for the comments. 


I also prefer DCMTK to GDCM for dicom reading/writing. will this new dcmtk-based exports code entirely implemented in Slicer or based on ITK or CTK? I ask this since dcmtk support in ITK is very limited currently. 


Kevin

On January 27, 2015 at 10:07 AM Steve Pieper <[hidden email]> wrote:

Hi Kevin -

I agree, adding features to the current CLI will be helpful given the current implementation of the export process. I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects. I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

-Steve

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang < [hidden email]> wrote:

Hi Andras and Csaba,


I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level.


so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work.


I hope I made it clear. if not, let me know.


Thanks,


Kevin



On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.


Andras


From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement


Hi Kevin,


I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html


Can you perform what you want with the new DICOM export?


csaba


From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement


Hi All,


Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that.


so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?


Thanks,


Kevin



_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.



 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Steve Pieper-2
Hi Kevin - 

Right now we are mostly focused on the pure dcmtk portion, with some CLIs, mostly for segmentation objects.  There's been a lot of progress on this but its not in the dcmtk master yet.

Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make them use the higher level dcmtk API while adding support for things like DCE and other multiframe DICOM objects.

If we do add any support at the CTK level it would probably be in the context of a Qt-style wrapper of the highest level dcmtk API and some integration with the CTK CLI processing.  The networking part of DICOM would still be in CTK and not in ITK.

Best,
Steve

On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang <[hidden email]> wrote:

Hi Steve,


Thanks for the comments. 


I also prefer DCMTK to GDCM for dicom reading/writing. will this new dcmtk-based exports code entirely implemented in Slicer or based on ITK or CTK? I ask this since dcmtk support in ITK is very limited currently. 


Kevin

On January 27, 2015 at 10:07 AM Steve Pieper <[hidden email]> wrote:

Hi Kevin -

I agree, adding features to the current CLI will be helpful given the current implementation of the export process. I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects. I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

-Steve

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang < [hidden email]> wrote:

Hi Andras and Csaba,


I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level.


so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work.


I hope I made it clear. if not, let me know.


Thanks,


Kevin



On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.


Andras


From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement


Hi Kevin,


I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html


Can you perform what you want with the new DICOM export?


csaba


From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement


Hi All,


Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that.


so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?


Thanks,


Kevin



_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.



 



_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Kevin Wang

Hi Steve,


Thanks for your comments. If I understand correctly, you are adding a high level dcmtk api on top of the current low level dcmtk api. then you would like to have ITKDCMTKImageIO to use them for importing/exporting. that all sounds great. 


What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the high level api which would use the low level dcmtk api. but if you have already got a plan then that is perfect. is there some kind of wiki or documents to describe how the high level dcmtk api looks like?


Kevin

On January 27, 2015 at 11:32 AM Steve Pieper <[hidden email]> wrote:

Hi Kevin -

Right now we are mostly focused on the pure dcmtk portion, with some CLIs, mostly for segmentation objects. There's been a lot of progress on this but its not in the dcmtk master yet.

Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make them use the higher level dcmtk API while adding support for things like DCE and other multiframe DICOM objects.

If we do add any support at the CTK level it would probably be in the context of a Qt-style wrapper of the highest level dcmtk API and some integration with the CTK CLI processing. The networking part of DICOM would still be in CTK and not in ITK.

Best,
Steve

On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang < [hidden email]> wrote:

Hi Steve,


Thanks for the comments.


I also prefer DCMTK to GDCM for dicom reading/writing. will this new dcmtk-based exports code entirely implemented in Slicer or based on ITK or CTK? I ask this since dcmtk support in ITK is very limited currently.


Kevin

On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:

Hi Kevin -

I agree, adding features to the current CLI will be helpful given the current implementation of the export process. I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects. I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

-Steve

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang < [hidden email]> wrote:

Hi Andras and Csaba,


I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level.


so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work.


I hope I made it clear. if not, let me know.


Thanks,


Kevin



On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.


Andras


From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement


Hi Kevin,


I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html


Can you perform what you want with the new DICOM export?


csaba


From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement


Hi All,


Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that.


so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?


Thanks,


Kevin



_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.





 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Steve Pieper-2
Hi Kevin - 

You can get a sense of it from the code that Andrey has been developing here:

https://github.com/QIICR/Iowa2DICOM


The changes to dcmtk are not public yet (they will be in a few months -- Michael wants to finalize them before putting them out).  But you can see them in use in these converter utilities (i.e. look at EncodeSEG).

Agreed that for many purposes people will be able to use ITK Readers and Writers to access the functionality, but sometimes it will be better to use the dcmtk api itself.

Best,
Steve

On Tue, Jan 27, 2015 at 12:11 PM, Kevin Wang - Techna <[hidden email]> wrote:

Hi Steve,


Thanks for your comments. If I understand correctly, you are adding a high level dcmtk api on top of the current low level dcmtk api. then you would like to have ITKDCMTKImageIO to use them for importing/exporting. that all sounds great. 


What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the high level api which would use the low level dcmtk api. but if you have already got a plan then that is perfect. is there some kind of wiki or documents to describe how the high level dcmtk api looks like?


Kevin

On January 27, 2015 at 11:32 AM Steve Pieper <[hidden email]> wrote:

Hi Kevin -

Right now we are mostly focused on the pure dcmtk portion, with some CLIs, mostly for segmentation objects. There's been a lot of progress on this but its not in the dcmtk master yet.

Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make them use the higher level dcmtk API while adding support for things like DCE and other multiframe DICOM objects.

If we do add any support at the CTK level it would probably be in the context of a Qt-style wrapper of the highest level dcmtk API and some integration with the CTK CLI processing. The networking part of DICOM would still be in CTK and not in ITK.

Best,
Steve

On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang < [hidden email]> wrote:

Hi Steve,


Thanks for the comments.


I also prefer DCMTK to GDCM for dicom reading/writing. will this new dcmtk-based exports code entirely implemented in Slicer or based on ITK or CTK? I ask this since dcmtk support in ITK is very limited currently.


Kevin

On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:

Hi Kevin -

I agree, adding features to the current CLI will be helpful given the current implementation of the export process. I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects. I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

-Steve

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang < [hidden email]> wrote:

Hi Andras and Csaba,


I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level.


so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work.


I hope I made it clear. if not, let me know.


Thanks,


Kevin



On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.


Andras


From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement


Hi Kevin,


I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html


Can you perform what you want with the new DICOM export?


csaba


From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement


Hi All,


Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that.


so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?


Thanks,


Kevin



_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.





 



_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

pinter

Hi Kevin,

 

This Mantis issue tracks adding an exported series to an existing study:

http://www.na-mic.org/Bug/view.php?id=3937

 

I investigated this today, and what I learned is this:

- CreateDICOMSeries module (and so the scalar volume plugin) cannot set the study instance UID, it is most probably automatically generated by itk::ExtractImageFilter

- Same happens in Plastimatch's Rt_study::save_dicom

So it seems that (all) the plugins will need to support adding series to existing study.

 

Also the DICOM export feature needs to support it. I think it should be quite easy on this level: the study nodes need to store their UIDs if imported from DICOM, and if it exists, then the exporter only exports the new series under that, passing the study UID to the plugins.

I started making some necessary changes, and I'll commit them tomorrow.

 

After that the plugins need to be modified to pass study UID to their respective exporters, including the new SegObj one.

 

csaba

 

From: Steve Pieper [mailto:[hidden email]]
Sent: January 27, 2015 13:37
To: Kevin Wang - Techna
Cc: Csaba Pinter; slicer-devel; Andras Lasso
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin - 

 

You can get a sense of it from the code that Andrey has been developing here:

 

https://github.com/QIICR/Iowa2DICOM

 

 

The changes to dcmtk are not public yet (they will be in a few months -- Michael wants to finalize them before putting them out).  But you can see them in use in these converter utilities (i.e. look at EncodeSEG).

 

Agreed that for many purposes people will be able to use ITK Readers and Writers to access the functionality, but sometimes it will be better to use the dcmtk api itself.

 

Best,

Steve

 

On Tue, Jan 27, 2015 at 12:11 PM, Kevin Wang - Techna <[hidden email]> wrote:

Hi Steve,

 

Thanks for your comments. If I understand correctly, you are adding a high level dcmtk api on top of the current low level dcmtk api. then you would like to have ITKDCMTKImageIO to use them for importing/exporting. that all sounds great. 

 

What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the high level api which would use the low level dcmtk api. but if you have already got a plan then that is perfect. is there some kind of wiki or documents to describe how the high level dcmtk api looks like?

 

Kevin

On January 27, 2015 at 11:32 AM Steve Pieper <[hidden email]> wrote:

Hi Kevin -

 

Right now we are mostly focused on the pure dcmtk portion, with some CLIs, mostly for segmentation objects. There's been a lot of progress on this but its not in the dcmtk master yet.

 

Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make them use the higher level dcmtk API while adding support for things like DCE and other multiframe DICOM objects.

 

If we do add any support at the CTK level it would probably be in the context of a Qt-style wrapper of the highest level dcmtk API and some integration with the CTK CLI processing. The networking part of DICOM would still be in CTK and not in ITK.

 

Best,

Steve

 

On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang < [hidden email]> wrote:

Hi Steve,

 

Thanks for the comments.

 

I also prefer DCMTK to GDCM for dicom reading/writing. will this new dcmtk-based exports code entirely implemented in Slicer or based on ITK or CTK? I ask this since dcmtk support in ITK is very limited currently.

 

Kevin

On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:

Hi Kevin -

 

I agree, adding features to the current CLI will be helpful given the current implementation of the export process. I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects. I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

 

-Steve

 

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang < [hidden email]> wrote:

Hi Andras and Csaba,

 

I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level.

 

so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work.

 

I hope I made it clear. if not, let me know.

 

Thanks,

 

Kevin

 

 

On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.

 

Andras

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin,

 

I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html

 

Can you perform what you want with the new DICOM export?

 

csaba

 

From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement

 

Hi All,

 

Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that.

 

so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?

 

Thanks,

 

Kevin

 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

 

 

 


 

 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Kevin Wang
In reply to this post by Steve Pieper-2

Hi Steve,


Thanks for the links! and it all looks promising. Looking forward to it in the DCMTK trunk.


Kevin

On January 27, 2015 at 1:37 PM Steve Pieper <[hidden email]> wrote:

Hi Kevin -

You can get a sense of it from the code that Andrey has been developing here:

https://github.com/QIICR/Iowa2DICOM


The changes to dcmtk are not public yet (they will be in a few months -- Michael wants to finalize them before putting them out). But you can see them in use in these converter utilities (i.e. look at EncodeSEG).

Agreed that for many purposes people will be able to use ITK Readers and Writers to access the functionality, but sometimes it will be better to use the dcmtk api itself.

Best,
Steve

On Tue, Jan 27, 2015 at 12:11 PM, Kevin Wang - Techna < [hidden email]> wrote:

Hi Steve,


Thanks for your comments. If I understand correctly, you are adding a high level dcmtk api on top of the current low level dcmtk api. then you would like to have ITKDCMTKImageIO to use them for importing/exporting. that all sounds great.


What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the high level api which would use the low level dcmtk api. but if you have already got a plan then that is perfect. is there some kind of wiki or documents to describe how the high level dcmtk api looks like?


Kevin

On January 27, 2015 at 11:32 AM Steve Pieper < [hidden email]> wrote:

Hi Kevin -

Right now we are mostly focused on the pure dcmtk portion, with some CLIs, mostly for segmentation objects. There's been a lot of progress on this but its not in the dcmtk master yet.

Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make them use the higher level dcmtk API while adding support for things like DCE and other multiframe DICOM objects.

If we do add any support at the CTK level it would probably be in the context of a Qt-style wrapper of the highest level dcmtk API and some integration with the CTK CLI processing. The networking part of DICOM would still be in CTK and not in ITK.

Best,
Steve

On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang < [hidden email]> wrote:

Hi Steve,


Thanks for the comments.


I also prefer DCMTK to GDCM for dicom reading/writing. will this new dcmtk-based exports code entirely implemented in Slicer or based on ITK or CTK? I ask this since dcmtk support in ITK is very limited currently.


Kevin

On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:

Hi Kevin -

I agree, adding features to the current CLI will be helpful given the current implementation of the export process. I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects. I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

-Steve

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang < [hidden email]> wrote:

Hi Andras and Csaba,


I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level.


so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work.


I hope I made it clear. if not, let me know.


Thanks,


Kevin



On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.


Andras


From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement


Hi Kevin,


I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html


Can you perform what you want with the new DICOM export?


csaba


From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement


Hi All,


Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that.


so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?


Thanks,


Kevin



_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.







 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Kevin Wang
In reply to this post by pinter

Hi Csaba,


So there is already a ticket for this issue. 


Yes, currently CreateDICOMSeires and Plastimatch does not support exporting to existing study. My original email was basically asking for this feature to be added. if you can add the support in dicom export, then I can do the changes for CreateDICOMSeries.


Thanks,


Kevin

On January 27, 2015 at 5:33 PM Csaba Pinter <[hidden email]> wrote:

Hi Kevin,

 

This Mantis issue tracks adding an exported series to an existing study:

http://www.na-mic.org/Bug/view.php?id=3937

 

I investigated this today, and what I learned is this:

- CreateDICOMSeries module (and so the scalar volume plugin) cannot set the study instance UID, it is most probably automatically generated by itk::ExtractImageFilter

- Same happens in Plastimatch's Rt_study::save_dicom

So it seems that (all) the plugins will need to support adding series to existing study.

 

Also the DICOM export feature needs to support it. I think it should be quite easy on this level: the study nodes need to store their UIDs if imported from DICOM, and if it exists, then the exporter only exports the new series under that, passing the study UID to the plugins.

I started making some necessary changes, and I'll commit them tomorrow.

 

After that the plugins need to be modified to pass study UID to their respective exporters, including the new SegObj one.

 

csaba

 

From: Steve Pieper [mailto:[hidden email]]
Sent: January 27, 2015 13:37
To: Kevin Wang - Techna
Cc: Csaba Pinter; slicer-devel; Andras Lasso
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin - 

 

You can get a sense of it from the code that Andrey has been developing here:

 

https://github.com/QIICR/Iowa2DICOM

 

 

The changes to dcmtk are not public yet (they will be in a few months -- Michael wants to finalize them before putting them out).  But you can see them in use in these converter utilities (i.e. look at EncodeSEG).

 

Agreed that for many purposes people will be able to use ITK Readers and Writers to access the functionality, but sometimes it will be better to use the dcmtk api itself.

 

Best,

Steve

 

On Tue, Jan 27, 2015 at 12:11 PM, Kevin Wang - Techna <[hidden email]> wrote:

Hi Steve,

 

Thanks for your comments. If I understand correctly, you are adding a high level dcmtk api on top of the current low level dcmtk api. then you would like to have ITKDCMTKImageIO to use them for importing/exporting. that all sounds great. 

 

What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the high level api which would use the low level dcmtk api. but if you have already got a plan then that is perfect. is there some kind of wiki or documents to describe how the high level dcmtk api looks like?

 

Kevin

On January 27, 2015 at 11:32 AM Steve Pieper <[hidden email]> wrote:

Hi Kevin -

 

Right now we are mostly focused on the pure dcmtk portion, with some CLIs, mostly for segmentation objects. There's been a lot of progress on this but its not in the dcmtk master yet.

 

Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make them use the higher level dcmtk API while adding support for things like DCE and other multiframe DICOM objects.

 

If we do add any support at the CTK level it would probably be in the context of a Qt-style wrapper of the highest level dcmtk API and some integration with the CTK CLI processing. The networking part of DICOM would still be in CTK and not in ITK.

 

Best,

Steve

 

On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang < [hidden email]> wrote:

Hi Steve,

 

Thanks for the comments.

 

I also prefer DCMTK to GDCM for dicom reading/writing. will this new dcmtk-based exports code entirely implemented in Slicer or based on ITK or CTK? I ask this since dcmtk support in ITK is very limited currently.

 

Kevin

On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:

Hi Kevin -

 

I agree, adding features to the current CLI will be helpful given the current implementation of the export process. I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects. I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

 

-Steve

 

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang < [hidden email]> wrote:

Hi Andras and Csaba,

 

I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level.

 

so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work.

 

I hope I made it clear. if not, let me know.

 

Thanks,

 

Kevin

 

 

On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.

 

Andras

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin,

 

I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html

 

Can you perform what you want with the new DICOM export?

 

csaba

 

From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement

 

Hi All,

 

Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that.

 

so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?

 

Thanks,

 

Kevin

 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

 

 

 


 

 


 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

pinter

Sounds great! I'll commit some preliminary code today and we can discuss how to proceed. Maybe at today's SlicerRT hangout at noon.

 

If somebody wants to participate, please shoot me an email and I'll send the hangout link once it's started.

Or we can talk about it next Tuesday at the Slicer hangout.

 

I think basically the question is how urgent this feature is for scalar volume, as if there is going to be a brand new DCMTK implementation and we will deviate from the CLI / ITK implementation, then it could make sense to focus on the new one. I don't know the priorities and the time frames though.

 

Thanks,

csaba

 

From: Kevin Wang [mailto:[hidden email]]
Sent: January 28, 2015 09:16
To: Csaba Pinter; Steve Pieper
Cc: slicer-devel; Andras Lasso
Subject: RE: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Csaba,

 

So there is already a ticket for this issue. 

 

Yes, currently CreateDICOMSeires and Plastimatch does not support exporting to existing study. My original email was basically asking for this feature to be added. if you can add the support in dicom export, then I can do the changes for CreateDICOMSeries.

 

Thanks,

 

Kevin

On January 27, 2015 at 5:33 PM Csaba Pinter <[hidden email]> wrote:

Hi Kevin,

 

This Mantis issue tracks adding an exported series to an existing study:

http://www.na-mic.org/Bug/view.php?id=3937

 

I investigated this today, and what I learned is this:

- CreateDICOMSeries module (and so the scalar volume plugin) cannot set the study instance UID, it is most probably automatically generated by itk::ExtractImageFilter

- Same happens in Plastimatch's Rt_study::save_dicom

So it seems that (all) the plugins will need to support adding series to existing study.

 

Also the DICOM export feature needs to support it. I think it should be quite easy on this level: the study nodes need to store their UIDs if imported from DICOM, and if it exists, then the exporter only exports the new series under that, passing the study UID to the plugins.

I started making some necessary changes, and I'll commit them tomorrow.

 

After that the plugins need to be modified to pass study UID to their respective exporters, including the new SegObj one.

 

csaba

 

From: Steve Pieper [[hidden email]]
Sent: January 27, 2015 13:37
To: Kevin Wang - Techna
Cc: Csaba Pinter; slicer-devel; Andras Lasso
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin - 

 

You can get a sense of it from the code that Andrey has been developing here:

 

https://github.com/QIICR/Iowa2DICOM

 

 

The changes to dcmtk are not public yet (they will be in a few months -- Michael wants to finalize them before putting them out).  But you can see them in use in these converter utilities (i.e. look at EncodeSEG).

 

Agreed that for many purposes people will be able to use ITK Readers and Writers to access the functionality, but sometimes it will be better to use the dcmtk api itself.

 

Best,

Steve

 

On Tue, Jan 27, 2015 at 12:11 PM, Kevin Wang - Techna <[hidden email]> wrote:

Hi Steve,

 

Thanks for your comments. If I understand correctly, you are adding a high level dcmtk api on top of the current low level dcmtk api. then you would like to have ITKDCMTKImageIO to use them for importing/exporting. that all sounds great. 

 

What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the high level api which would use the low level dcmtk api. but if you have already got a plan then that is perfect. is there some kind of wiki or documents to describe how the high level dcmtk api looks like?

 

Kevin

On January 27, 2015 at 11:32 AM Steve Pieper <[hidden email]> wrote:

Hi Kevin -

 

Right now we are mostly focused on the pure dcmtk portion, with some CLIs, mostly for segmentation objects. There's been a lot of progress on this but its not in the dcmtk master yet.

 

Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make them use the higher level dcmtk API while adding support for things like DCE and other multiframe DICOM objects.

 

If we do add any support at the CTK level it would probably be in the context of a Qt-style wrapper of the highest level dcmtk API and some integration with the CTK CLI processing. The networking part of DICOM would still be in CTK and not in ITK.

 

Best,

Steve

 

On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang < [hidden email]> wrote:

Hi Steve,

 

Thanks for the comments.

 

I also prefer DCMTK to GDCM for dicom reading/writing. will this new dcmtk-based exports code entirely implemented in Slicer or based on ITK or CTK? I ask this since dcmtk support in ITK is very limited currently.

 

Kevin

On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:

Hi Kevin -

 

I agree, adding features to the current CLI will be helpful given the current implementation of the export process. I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects. I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

 

-Steve

 

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang < [hidden email]> wrote:

Hi Andras and Csaba,

 

I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level.

 

so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work.

 

I hope I made it clear. if not, let me know.

 

Thanks,

 

Kevin

 

 

On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.

 

Andras

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin,

 

I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html

 

Can you perform what you want with the new DICOM export?

 

csaba

 

From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement

 

Hi All,

 

Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that.

 

so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?

 

Thanks,

 

Kevin

 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

 

 

 


 

 


 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Kevin Wang

Hi Csaba,


I think it is not that urgent plus there will be a new DCMTK implementation in next few months. Basically I got my own version of create dicom series working for me so I am not in a rush.


Kevin

On January 28, 2015 at 11:29 AM Csaba Pinter <[hidden email]> wrote:

Sounds great! I'll commit some preliminary code today and we can discuss how to proceed. Maybe at today's SlicerRT hangout at noon.

 

If somebody wants to participate, please shoot me an email and I'll send the hangout link once it's started.

Or we can talk about it next Tuesday at the Slicer hangout.

 

I think basically the question is how urgent this feature is for scalar volume, as if there is going to be a brand new DCMTK implementation and we will deviate from the CLI / ITK implementation, then it could make sense to focus on the new one. I don't know the priorities and the time frames though.

 

Thanks,

csaba

 

From: Kevin Wang [mailto:[hidden email]]
Sent: January 28, 2015 09:16
To: Csaba Pinter; Steve Pieper
Cc: slicer-devel; Andras Lasso
Subject: RE: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Csaba,

 

So there is already a ticket for this issue. 

 

Yes, currently CreateDICOMSeires and Plastimatch does not support exporting to existing study. My original email was basically asking for this feature to be added. if you can add the support in dicom export, then I can do the changes for CreateDICOMSeries.

 

Thanks,

 

Kevin

On January 27, 2015 at 5:33 PM Csaba Pinter <[hidden email]> wrote:

Hi Kevin,

 

This Mantis issue tracks adding an exported series to an existing study:

http://www.na-mic.org/Bug/view.php?id=3937

 

I investigated this today, and what I learned is this:

- CreateDICOMSeries module (and so the scalar volume plugin) cannot set the study instance UID, it is most probably automatically generated by itk::ExtractImageFilter

- Same happens in Plastimatch's Rt_study::save_dicom

So it seems that (all) the plugins will need to support adding series to existing study.

 

Also the DICOM export feature needs to support it. I think it should be quite easy on this level: the study nodes need to store their UIDs if imported from DICOM, and if it exists, then the exporter only exports the new series under that, passing the study UID to the plugins.

I started making some necessary changes, and I'll commit them tomorrow.

 

After that the plugins need to be modified to pass study UID to their respective exporters, including the new SegObj one.

 

csaba

 

From: Steve Pieper [[hidden email]]
Sent: January 27, 2015 13:37
To: Kevin Wang - Techna
Cc: Csaba Pinter; slicer-devel; Andras Lasso
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin - 

 

You can get a sense of it from the code that Andrey has been developing here:

 

https://github.com/QIICR/Iowa2DICOM

 

 

The changes to dcmtk are not public yet (they will be in a few months -- Michael wants to finalize them before putting them out).  But you can see them in use in these converter utilities (i.e. look at EncodeSEG).

 

Agreed that for many purposes people will be able to use ITK Readers and Writers to access the functionality, but sometimes it will be better to use the dcmtk api itself.

 

Best,

Steve

 

On Tue, Jan 27, 2015 at 12:11 PM, Kevin Wang - Techna <[hidden email]> wrote:

Hi Steve,

 

Thanks for your comments. If I understand correctly, you are adding a high level dcmtk api on top of the current low level dcmtk api. then you would like to have ITKDCMTKImageIO to use them for importing/exporting. that all sounds great. 

 

What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the high level api which would use the low level dcmtk api. but if you have already got a plan then that is perfect. is there some kind of wiki or documents to describe how the high level dcmtk api looks like?

 

Kevin

On January 27, 2015 at 11:32 AM Steve Pieper <[hidden email]> wrote:

Hi Kevin -

 

Right now we are mostly focused on the pure dcmtk portion, with some CLIs, mostly for segmentation objects. There's been a lot of progress on this but its not in the dcmtk master yet.

 

Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make them use the higher level dcmtk API while adding support for things like DCE and other multiframe DICOM objects.

 

If we do add any support at the CTK level it would probably be in the context of a Qt-style wrapper of the highest level dcmtk API and some integration with the CTK CLI processing. The networking part of DICOM would still be in CTK and not in ITK.

 

Best,

Steve

 

On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang < [hidden email]> wrote:

Hi Steve,

 

Thanks for the comments.

 

I also prefer DCMTK to GDCM for dicom reading/writing. will this new dcmtk-based exports code entirely implemented in Slicer or based on ITK or CTK? I ask this since dcmtk support in ITK is very limited currently.

 

Kevin

On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:

Hi Kevin -

 

I agree, adding features to the current CLI will be helpful given the current implementation of the export process. I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects. I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

 

-Steve

 

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang < [hidden email]> wrote:

Hi Andras and Csaba,

 

I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level.

 

so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work.

 

I hope I made it clear. if not, let me know.

 

Thanks,

 

Kevin

 

 

On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.

 

Andras

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin,

 

I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html

 

Can you perform what you want with the new DICOM export?

 

csaba

 

From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement

 

Hi All,

 

Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that.

 

so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?

 

Thanks,

 

Kevin

 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

 

 

 


 

 


 


 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

pinter

Alright. I will make sure this feature is supported by the export mechanism and then the plugins can take care of the rest at their own pace.

 

csaba

 

From: Kevin Wang [mailto:[hidden email]]
Sent: January 28, 2015 11:35
To: Csaba Pinter; Steve Pieper
Cc: slicer-devel; Andras Lasso
Subject: RE: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Csaba,

 

I think it is not that urgent plus there will be a new DCMTK implementation in next few months. Basically I got my own version of create dicom series working for me so I am not in a rush.

 

Kevin

On January 28, 2015 at 11:29 AM Csaba Pinter <[hidden email]> wrote:

Sounds great! I'll commit some preliminary code today and we can discuss how to proceed. Maybe at today's SlicerRT hangout at noon.

 

If somebody wants to participate, please shoot me an email and I'll send the hangout link once it's started.

Or we can talk about it next Tuesday at the Slicer hangout.

 

I think basically the question is how urgent this feature is for scalar volume, as if there is going to be a brand new DCMTK implementation and we will deviate from the CLI / ITK implementation, then it could make sense to focus on the new one. I don't know the priorities and the time frames though.

 

Thanks,

csaba

 

From: Kevin Wang [[hidden email]]
Sent: January 28, 2015 09:16
To: Csaba Pinter; Steve Pieper
Cc: slicer-devel; Andras Lasso
Subject: RE: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Csaba,

 

So there is already a ticket for this issue. 

 

Yes, currently CreateDICOMSeires and Plastimatch does not support exporting to existing study. My original email was basically asking for this feature to be added. if you can add the support in dicom export, then I can do the changes for CreateDICOMSeries.

 

Thanks,

 

Kevin

On January 27, 2015 at 5:33 PM Csaba Pinter <[hidden email]> wrote:

Hi Kevin,

 

This Mantis issue tracks adding an exported series to an existing study:

http://www.na-mic.org/Bug/view.php?id=3937

 

I investigated this today, and what I learned is this:

- CreateDICOMSeries module (and so the scalar volume plugin) cannot set the study instance UID, it is most probably automatically generated by itk::ExtractImageFilter

- Same happens in Plastimatch's Rt_study::save_dicom

So it seems that (all) the plugins will need to support adding series to existing study.

 

Also the DICOM export feature needs to support it. I think it should be quite easy on this level: the study nodes need to store their UIDs if imported from DICOM, and if it exists, then the exporter only exports the new series under that, passing the study UID to the plugins.

I started making some necessary changes, and I'll commit them tomorrow.

 

After that the plugins need to be modified to pass study UID to their respective exporters, including the new SegObj one.

 

csaba

 

From: Steve Pieper [[hidden email]]
Sent: January 27, 2015 13:37
To: Kevin Wang - Techna
Cc: Csaba Pinter; slicer-devel; Andras Lasso
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin - 

 

You can get a sense of it from the code that Andrey has been developing here:

 

https://github.com/QIICR/Iowa2DICOM

 

 

The changes to dcmtk are not public yet (they will be in a few months -- Michael wants to finalize them before putting them out).  But you can see them in use in these converter utilities (i.e. look at EncodeSEG).

 

Agreed that for many purposes people will be able to use ITK Readers and Writers to access the functionality, but sometimes it will be better to use the dcmtk api itself.

 

Best,

Steve

 

On Tue, Jan 27, 2015 at 12:11 PM, Kevin Wang - Techna <[hidden email]> wrote:

Hi Steve,

 

Thanks for your comments. If I understand correctly, you are adding a high level dcmtk api on top of the current low level dcmtk api. then you would like to have ITKDCMTKImageIO to use them for importing/exporting. that all sounds great. 

 

What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the high level api which would use the low level dcmtk api. but if you have already got a plan then that is perfect. is there some kind of wiki or documents to describe how the high level dcmtk api looks like?

 

Kevin

On January 27, 2015 at 11:32 AM Steve Pieper <[hidden email]> wrote:

Hi Kevin -

 

Right now we are mostly focused on the pure dcmtk portion, with some CLIs, mostly for segmentation objects. There's been a lot of progress on this but its not in the dcmtk master yet.

 

Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make them use the higher level dcmtk API while adding support for things like DCE and other multiframe DICOM objects.

 

If we do add any support at the CTK level it would probably be in the context of a Qt-style wrapper of the highest level dcmtk API and some integration with the CTK CLI processing. The networking part of DICOM would still be in CTK and not in ITK.

 

Best,

Steve

 

On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang < [hidden email]> wrote:

Hi Steve,

 

Thanks for the comments.

 

I also prefer DCMTK to GDCM for dicom reading/writing. will this new dcmtk-based exports code entirely implemented in Slicer or based on ITK or CTK? I ask this since dcmtk support in ITK is very limited currently.

 

Kevin

On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:

Hi Kevin -

 

I agree, adding features to the current CLI will be helpful given the current implementation of the export process. I'd just point out that before long we'll want to switch to dcmtk-based exports to take advantage of the newer features it has to support multiframe and other dicom objects. I suspect we'll be inspired from the features of the Create a DICOM Series module, but with a pretty fresh implementation.

 

-Steve

 

On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang < [hidden email]> wrote:

Hi Andras and Csaba,

 

I agree that we should start to use the new DICOM export. However, as I understand, the new DICOM export still employs this CLI module for the actual export. so the actual setting up of the UIDs still happens in this module and not at the DICOM export level.

 

so this improvement would actually benefit the DICOM export as well as right now it can only create a new study since it uses this module for actual work.

 

I hope I made it clear. if not, let me know.

 

Thanks,

 

Kevin

 

 

On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:

I agree that the old DICOM export mechanism should be deprecated (and removed in the next major version) to reduce software maintenance workload.

 

Andras

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: Monday, January 26, 2015 4:00 PM
To: Kevin Wang; slicer-devel
Subject: Re: [slicer-devel] Create Dicom Series possoble improvement

 

Hi Kevin,

 

I think we should move towards using the new DICOM export mechanism instead of improving this basic module.

See http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html

 

Can you perform what you want with the new DICOM export?

 

csaba

 

From: [hidden email] [[hidden email]] On Behalf Of Kevin Wang
Sent: January 26, 2015 14:30
To: slicer-devel
Subject: [slicer-devel] Create Dicom Series possoble improvement

 

Hi All,

 

Recently I used the "Create Dicom Series" CLI module. However, I encountered a bit limitation of the module. The module works well creating a new study as well new series. However, what I wanted to do is to create a series and add it back to original study. this requires to set the StudyInstatnceUID and FrameOfReferenceUID to be the same as the original study's. I have to do a bit code changes to achieve that.

 

so my question is: does this seems to be a reasonable feature to add to the module? if so, I will create a ticket for this task. also there seems to be no category for this module in Mantis. should I just assign the ticket to Dicom module?

 

Thanks,

 

Kevin

 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

 

 

 


 

 


 


 


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Andrey Fedorov
In reply to this post by pinter
Csaba,

> I think basically the question is how urgent this feature is for scalar
> volume, as if there is going to be a brand new DCMTK implementation and we
> will deviate from the CLI / ITK implementation, then it could make sense to
> focus on the new one. I don't know the priorities and the time frames
> though.
>

unfortunately, we do not have a clear timeline for integrating the new
DCMTK features, due to bureaucratic hurdles and delays in putting
contracts in place for this work to happen. I am hoping the time frame
is few months for updating the master. The new DCMTK API is just the
first step, it does not yet include APIs for the multiframe MR/CT.
Once that API is available, it should be followed by the development
of the higher level converter.

So, all in all, we are probably looking at around Summer where a good
alternative to the current converter could be developed.

I do not know what is the user base for the current
converter/exporter, so not sure how urgent the change discussed is. It
does sound like implementing the feature Kevin needs should not take a
lot of work though.

One suggestion I would have for this work is to modify the
converter/exporter to be able to accept a reference DICOM series
instances that would be used to populate the fields of the newly
created object. Without such series creation of a valid DICOM object
that preserves all necessary information to be correctly integrated
into the original study is hard if not impossible.


On Wed, Jan 28, 2015 at 11:29 AM, Csaba Pinter <[hidden email]> wrote:

> Sounds great! I'll commit some preliminary code today and we can discuss how
> to proceed. Maybe at today's SlicerRT hangout at noon.
>
>
>
> If somebody wants to participate, please shoot me an email and I'll send the
> hangout link once it's started.
>
> Or we can talk about it next Tuesday at the Slicer hangout.
>
>
>
> I think basically the question is how urgent this feature is for scalar
> volume, as if there is going to be a brand new DCMTK implementation and we
> will deviate from the CLI / ITK implementation, then it could make sense to
> focus on the new one. I don't know the priorities and the time frames
> though.
>
>
>
> Thanks,
>
> csaba
>
>
>
> From: Kevin Wang [mailto:[hidden email]]
> Sent: January 28, 2015 09:16
> To: Csaba Pinter; Steve Pieper
> Cc: slicer-devel; Andras Lasso
> Subject: RE: [slicer-devel] Create Dicom Series possoble improvement
>
>
>
> Hi Csaba,
>
>
>
> So there is already a ticket for this issue.
>
>
>
> Yes, currently CreateDICOMSeires and Plastimatch does not support exporting
> to existing study. My original email was basically asking for this feature
> to be added. if you can add the support in dicom export, then I can do the
> changes for CreateDICOMSeries.
>
>
>
> Thanks,
>
>
>
> Kevin
>
> On January 27, 2015 at 5:33 PM Csaba Pinter <[hidden email]> wrote:
>
> Hi Kevin,
>
>
>
> This Mantis issue tracks adding an exported series to an existing study:
>
> http://www.na-mic.org/Bug/view.php?id=3937
>
>
>
> I investigated this today, and what I learned is this:
>
> - CreateDICOMSeries module (and so the scalar volume plugin) cannot set the
> study instance UID, it is most probably automatically generated by
> itk::ExtractImageFilter
>
> - Same happens in Plastimatch's Rt_study::save_dicom
>
> So it seems that (all) the plugins will need to support adding series to
> existing study.
>
>
>
> Also the DICOM export feature needs to support it. I think it should be
> quite easy on this level: the study nodes need to store their UIDs if
> imported from DICOM, and if it exists, then the exporter only exports the
> new series under that, passing the study UID to the plugins.
>
> I started making some necessary changes, and I'll commit them tomorrow.
>
>
>
> After that the plugins need to be modified to pass study UID to their
> respective exporters, including the new SegObj one.
>
>
>
> csaba
>
>
>
> From: Steve Pieper [mailto:[hidden email]]
> Sent: January 27, 2015 13:37
> To: Kevin Wang - Techna
> Cc: Csaba Pinter; slicer-devel; Andras Lasso
> Subject: Re: [slicer-devel] Create Dicom Series possoble improvement
>
>
>
> Hi Kevin -
>
>
>
> You can get a sense of it from the code that Andrey has been developing
> here:
>
>
>
> https://github.com/QIICR/Iowa2DICOM
>
>
>
> https://github.com/QIICR/Iowa2DICOM/tree/master/ConvertSegmentations
>
>
>
> The changes to dcmtk are not public yet (they will be in a few months --
> Michael wants to finalize them before putting them out).  But you can see
> them in use in these converter utilities (i.e. look at EncodeSEG).
>
>
>
> Agreed that for many purposes people will be able to use ITK Readers and
> Writers to access the functionality, but sometimes it will be better to use
> the dcmtk api itself.
>
>
>
> Best,
>
> Steve
>
>
>
> On Tue, Jan 27, 2015 at 12:11 PM, Kevin Wang - Techna
> <[hidden email]> wrote:
>
> Hi Steve,
>
>
>
> Thanks for your comments. If I understand correctly, you are adding a high
> level dcmtk api on top of the current low level dcmtk api. then you would
> like to have ITKDCMTKImageIO to use them for importing/exporting. that all
> sounds great.
>
>
>
> What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the
> high level api which would use the low level dcmtk api. but if you have
> already got a plan then that is perfect. is there some kind of wiki or
> documents to describe how the high level dcmtk api looks like?
>
>
>
> Kevin
>
> On January 27, 2015 at 11:32 AM Steve Pieper <[hidden email]> wrote:
>
> Hi Kevin -
>
>
>
> Right now we are mostly focused on the pure dcmtk portion, with some CLIs,
> mostly for segmentation objects. There's been a lot of progress on this but
> its not in the dcmtk master yet.
>
>
>
> Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make
> them use the higher level dcmtk API while adding support for things like DCE
> and other multiframe DICOM objects.
>
>
>
> If we do add any support at the CTK level it would probably be in the
> context of a Qt-style wrapper of the highest level dcmtk API and some
> integration with the CTK CLI processing. The networking part of DICOM would
> still be in CTK and not in ITK.
>
>
>
> Best,
>
> Steve
>
>
>
> On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang <
> [hidden email]> wrote:
>
> Hi Steve,
>
>
>
> Thanks for the comments.
>
>
>
> I also prefer DCMTK to GDCM for dicom reading/writing. will this new
> dcmtk-based exports code entirely implemented in Slicer or based on ITK or
> CTK? I ask this since dcmtk support in ITK is very limited currently.
>
>
>
> Kevin
>
> On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:
>
> Hi Kevin -
>
>
>
> I agree, adding features to the current CLI will be helpful given the
> current implementation of the export process. I'd just point out that before
> long we'll want to switch to dcmtk-based exports to take advantage of the
> newer features it has to support multiframe and other dicom objects. I
> suspect we'll be inspired from the features of the Create a DICOM Series
> module, but with a pretty fresh implementation.
>
>
>
> -Steve
>
>
>
> On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang <
> [hidden email]> wrote:
>
> Hi Andras and Csaba,
>
>
>
> I agree that we should start to use the new DICOM export. However, as I
> understand, the new DICOM export still employs this CLI module for the
> actual export. so the actual setting up of the UIDs still happens in this
> module and not at the DICOM export level.
>
>
>
> so this improvement would actually benefit the DICOM export as well as right
> now it can only create a new study since it uses this module for actual
> work.
>
>
>
> I hope I made it clear. if not, let me know.
>
>
>
> Thanks,
>
>
>
> Kevin
>
>
>
>
>
> On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:
>
> I agree that the old DICOM export mechanism should be deprecated (and
> removed in the next major version) to reduce software maintenance workload.
>
>
>
> Andras
>
>
>
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Csaba Pinter
> Sent: Monday, January 26, 2015 4:00 PM
> To: Kevin Wang; slicer-devel
> Subject: Re: [slicer-devel] Create Dicom Series possoble improvement
>
>
>
> Hi Kevin,
>
>
>
> I think we should move towards using the new DICOM export mechanism instead
> of improving this basic module.
>
> See
> http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html
>
>
>
> Can you perform what you want with the new DICOM export?
>
>
>
> csaba
>
>
>
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Kevin Wang
> Sent: January 26, 2015 14:30
> To: slicer-devel
> Subject: [slicer-devel] Create Dicom Series possoble improvement
>
>
>
> Hi All,
>
>
>
> Recently I used the "Create Dicom Series" CLI module. However, I encountered
> a bit limitation of the module. The module works well creating a new study
> as well new series. However, what I wanted to do is to create a series and
> add it back to original study. this requires to set the StudyInstatnceUID
> and FrameOfReferenceUID to be the same as the original study's. I have to do
> a bit code changes to achieve that.
>
>
>
> so my question is: does this seems to be a reasonable feature to add to the
> module? if so, I will create a ticket for this task. also there seems to be
> no category for this module in Mantis. should I just assign the ticket to
> Dicom module?
>
>
>
> Thanks,
>
>
>
> Kevin
>
>
>
>
> _______________________________________________
> slicer-devel mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> To unsubscribe: send email to [hidden email] with
> unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>
>
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> slicer-devel mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> To unsubscribe: send email to [hidden email] with
> unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>
>
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Kevin Wang

Hi Andrey,


Good point! I guess the overall mesage is that we do not get our hope too high for now.


the suggestion to add a reference DICOM series sounds right and it is relatively easy to add to the create dicom series CLI. however, it would require some code changes at DICOM export level to be able to track the original/referenced DICOM series.


Kevin

On January 28, 2015 at 11:41 AM Andriy Fedorov <[hidden email]> wrote:


Csaba,

> I think basically the question is how urgent this feature is for scalar
> volume, as if there is going to be a brand new DCMTK implementation and we
> will deviate from the CLI / ITK implementation, then it could make sense to
> focus on the new one. I don't know the priorities and the time frames
> though.
>

unfortunately, we do not have a clear timeline for integrating the new
DCMTK features, due to bureaucratic hurdles and delays in putting
contracts in place for this work to happen. I am hoping the time frame
is few months for updating the master. The new DCMTK API is just the
first step, it does not yet include APIs for the multiframe MR/CT.
Once that API is available, it should be followed by the development
of the higher level converter.

So, all in all, we are probably looking at around Summer where a good
alternative to the current converter could be developed.

I do not know what is the user base for the current
converter/exporter, so not sure how urgent the change discussed is. It
does sound like implementing the feature Kevin needs should not take a
lot of work though.

One suggestion I would have for this work is to modify the
converter/exporter to be able to accept a reference DICOM series
instances that would be used to populate the fields of the newly
created object. Without such series creation of a valid DICOM object
that preserves all necessary information to be correctly integrated
into the original study is hard if not impossible.


On Wed, Jan 28, 2015 at 11:29 AM, Csaba Pinter <[hidden email]> wrote:
> Sounds great! I'll commit some preliminary code today and we can discuss how
> to proceed. Maybe at today's SlicerRT hangout at noon.
>
>
>
> If somebody wants to participate, please shoot me an email and I'll send the
> hangout link once it's started.
>
> Or we can talk about it next Tuesday at the Slicer hangout.
>
>
>
> I think basically the question is how urgent this feature is for scalar
> volume, as if there is going to be a brand new DCMTK implementation and we
> will deviate from the CLI / ITK implementation, then it could make sense to
> focus on the new one. I don't know the priorities and the time frames
> though.
>
>
>
> Thanks,
>
> csaba
>
>
>
> From: Kevin Wang [mailto:[hidden email]]
> Sent: January 28, 2015 09:16
> To: Csaba Pinter; Steve Pieper
> Cc: slicer-devel; Andras Lasso
> Subject: RE: [slicer-devel] Create Dicom Series possoble improvement
>
>
>
> Hi Csaba,
>
>
>
> So there is already a ticket for this issue.
>
>
>
> Yes, currently CreateDICOMSeires and Plastimatch does not support exporting
> to existing study. My original email was basically asking for this feature
> to be added. if you can add the support in dicom export, then I can do the
> changes for CreateDICOMSeries.
>
>
>
> Thanks,
>
>
>
> Kevin
>
> On January 27, 2015 at 5:33 PM Csaba Pinter <[hidden email]> wrote:
>
> Hi Kevin,
>
>
>
> This Mantis issue tracks adding an exported series to an existing study:
>
> http://www.na-mic.org/Bug/view.php?id=3937
>
>
>
> I investigated this today, and what I learned is this:
>
> - CreateDICOMSeries module (and so the scalar volume plugin) cannot set the
> study instance UID, it is most probably automatically generated by
> itk::ExtractImageFilter
>
> - Same happens in Plastimatch's Rt_study::save_dicom
>
> So it seems that (all) the plugins will need to support adding series to
> existing study.
>
>
>
> Also the DICOM export feature needs to support it. I think it should be
> quite easy on this level: the study nodes need to store their UIDs if
> imported from DICOM, and if it exists, then the exporter only exports the
> new series under that, passing the study UID to the plugins.
>
> I started making some necessary changes, and I'll commit them tomorrow.
>
>
>
> After that the plugins need to be modified to pass study UID to their
> respective exporters, including the new SegObj one.
>
>
>
> csaba
>
>
>
> From: Steve Pieper [mailto:[hidden email]]
> Sent: January 27, 2015 13:37
> To: Kevin Wang - Techna
> Cc: Csaba Pinter; slicer-devel; Andras Lasso
> Subject: Re: [slicer-devel] Create Dicom Series possoble improvement
>
>
>
> Hi Kevin -
>
>
>
> You can get a sense of it from the code that Andrey has been developing
> here:
>
>
>
> https://github.com/QIICR/Iowa2DICOM
>
>
>
> https://github.com/QIICR/Iowa2DICOM/tree/master/ConvertSegmentations
>
>
>
> The changes to dcmtk are not public yet (they will be in a few months --
> Michael wants to finalize them before putting them out). But you can see
> them in use in these converter utilities (i.e. look at EncodeSEG).
>
>
>
> Agreed that for many purposes people will be able to use ITK Readers and
> Writers to access the functionality, but sometimes it will be better to use
> the dcmtk api itself.
>
>
>
> Best,
>
> Steve
>
>
>
> On Tue, Jan 27, 2015 at 12:11 PM, Kevin Wang - Techna
> <[hidden email]> wrote:
>
> Hi Steve,
>
>
>
> Thanks for your comments. If I understand correctly, you are adding a high
> level dcmtk api on top of the current low level dcmtk api. then you would
> like to have ITKDCMTKImageIO to use them for importing/exporting. that all
> sounds great.
>
>
>
> What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the
> high level api which would use the low level dcmtk api. but if you have
> already got a plan then that is perfect. is there some kind of wiki or
> documents to describe how the high level dcmtk api looks like?
>
>
>
> Kevin
>
> On January 27, 2015 at 11:32 AM Steve Pieper <[hidden email]> wrote:
>
> Hi Kevin -
>
>
>
> Right now we are mostly focused on the pure dcmtk portion, with some CLIs,
> mostly for segmentation objects. There's been a lot of progress on this but
> its not in the dcmtk master yet.
>
>
>
> Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to make
> them use the higher level dcmtk API while adding support for things like DCE
> and other multiframe DICOM objects.
>
>
>
> If we do add any support at the CTK level it would probably be in the
> context of a Qt-style wrapper of the highest level dcmtk API and some
> integration with the CTK CLI processing. The networking part of DICOM would
> still be in CTK and not in ITK.
>
>
>
> Best,
>
> Steve
>
>
>
> On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang <
> [hidden email]> wrote:
>
> Hi Steve,
>
>
>
> Thanks for the comments.
>
>
>
> I also prefer DCMTK to GDCM for dicom reading/writing. will this new
> dcmtk-based exports code entirely implemented in Slicer or based on ITK or
> CTK? I ask this since dcmtk support in ITK is very limited currently.
>
>
>
> Kevin
>
> On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:
>
> Hi Kevin -
>
>
>
> I agree, adding features to the current CLI will be helpful given the
> current implementation of the export process. I'd just point out that before
> long we'll want to switch to dcmtk-based exports to take advantage of the
> newer features it has to support multiframe and other dicom objects. I
> suspect we'll be inspired from the features of the Create a DICOM Series
> module, but with a pretty fresh implementation.
>
>
>
> -Steve
>
>
>
> On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang <
> [hidden email]> wrote:
>
> Hi Andras and Csaba,
>
>
>
> I agree that we should start to use the new DICOM export. However, as I
> understand, the new DICOM export still employs this CLI module for the
> actual export. so the actual setting up of the UIDs still happens in this
> module and not at the DICOM export level.
>
>
>
> so this improvement would actually benefit the DICOM export as well as right
> now it can only create a new study since it uses this module for actual
> work.
>
>
>
> I hope I made it clear. if not, let me know.
>
>
>
> Thanks,
>
>
>
> Kevin
>
>
>
>
>
> On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:
>
> I agree that the old DICOM export mechanism should be deprecated (and
> removed in the next major version) to reduce software maintenance workload.
>
>
>
> Andras
>
>
>
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Csaba Pinter
> Sent: Monday, January 26, 2015 4:00 PM
> To: Kevin Wang; slicer-devel
> Subject: Re: [slicer-devel] Create Dicom Series possoble improvement
>
>
>
> Hi Kevin,
>
>
>
> I think we should move towards using the new DICOM export mechanism instead
> of improving this basic module.
>
> See
> http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html
>
>
>
> Can you perform what you want with the new DICOM export?
>
>
>
> csaba
>
>
>
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Kevin Wang
> Sent: January 26, 2015 14:30
> To: slicer-devel
> Subject: [slicer-devel] Create Dicom Series possoble improvement
>
>
>
> Hi All,
>
>
>
> Recently I used the "Create Dicom Series" CLI module. However, I encountered
> a bit limitation of the module. The module works well creating a new study
> as well new series. However, what I wanted to do is to create a series and
> add it back to original study. this requires to set the StudyInstatnceUID
> and FrameOfReferenceUID to be the same as the original study's. I have to do
> a bit code changes to achieve that.
>
>
>
> so my question is: does this seems to be a reasonable feature to add to the
> module? if so, I will create a ticket for this task. also there seems to be
> no category for this module in Mantis. should I just assign the ticket to
> Dicom module?
>
>
>
> Thanks,
>
>
>
> Kevin
>
>
>
>
> _______________________________________________
> slicer-devel mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> To unsubscribe: send email to [hidden email] with
> unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>
>
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> slicer-devel mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
> To unsubscribe: send email to [hidden email] with
> unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>
>
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>


_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
Reply | Threaded
Open this post in threaded view
|

Re: Create Dicom Series possoble improvement

Andrey Fedorov
On Wed, Jan 28, 2015 at 12:12 PM, Kevin Wang
<[hidden email]> wrote:
> Good point! I guess the overall mesage is that we do not get our hope too
> high for now.
>

Unfortunately, yes ...

I considered myself rather conservative, but was burned already by
setting my own hopes too high...

Better keep hopes low and get a pleasant surprise in the end :-)

>
> the suggestion to add a reference DICOM series sounds right and it is
> relatively easy to add to the create dicom series CLI. however, it would
> require some code changes at DICOM export level to be able to track the
> original/referenced DICOM series.
>
>
> Kevin
>
> On January 28, 2015 at 11:41 AM Andriy Fedorov <[hidden email]>
> wrote:
>
>
> Csaba,
>
>> I think basically the question is how urgent this feature is for scalar
>> volume, as if there is going to be a brand new DCMTK implementation and we
>> will deviate from the CLI / ITK implementation, then it could make sense
>> to
>> focus on the new one. I don't know the priorities and the time frames
>> though.
>>
>
> unfortunately, we do not have a clear timeline for integrating the new
> DCMTK features, due to bureaucratic hurdles and delays in putting
> contracts in place for this work to happen. I am hoping the time frame
> is few months for updating the master. The new DCMTK API is just the
> first step, it does not yet include APIs for the multiframe MR/CT.
> Once that API is available, it should be followed by the development
> of the higher level converter.
>
> So, all in all, we are probably looking at around Summer where a good
> alternative to the current converter could be developed.
>
> I do not know what is the user base for the current
> converter/exporter, so not sure how urgent the change discussed is. It
> does sound like implementing the feature Kevin needs should not take a
> lot of work though.
>
> One suggestion I would have for this work is to modify the
> converter/exporter to be able to accept a reference DICOM series
> instances that would be used to populate the fields of the newly
> created object. Without such series creation of a valid DICOM object
> that preserves all necessary information to be correctly integrated
> into the original study is hard if not impossible.
>
>
> On Wed, Jan 28, 2015 at 11:29 AM, Csaba Pinter <[hidden email]>
> wrote:
>> Sounds great! I'll commit some preliminary code today and we can discuss
>> how
>> to proceed. Maybe at today's SlicerRT hangout at noon.
>>
>>
>>
>> If somebody wants to participate, please shoot me an email and I'll send
>> the
>> hangout link once it's started.
>>
>> Or we can talk about it next Tuesday at the Slicer hangout.
>>
>>
>>
>> I think basically the question is how urgent this feature is for scalar
>> volume, as if there is going to be a brand new DCMTK implementation and we
>> will deviate from the CLI / ITK implementation, then it could make sense
>> to
>> focus on the new one. I don't know the priorities and the time frames
>> though.
>>
>>
>>
>> Thanks,
>>
>> csaba
>>
>>
>>
>> From: Kevin Wang [mailto:[hidden email]]
>> Sent: January 28, 2015 09:16
>> To: Csaba Pinter; Steve Pieper
>> Cc: slicer-devel; Andras Lasso
>> Subject: RE: [slicer-devel] Create Dicom Series possoble improvement
>>
>>
>>
>> Hi Csaba,
>>
>>
>>
>> So there is already a ticket for this issue.
>>
>>
>>
>> Yes, currently CreateDICOMSeires and Plastimatch does not support
>> exporting
>> to existing study. My original email was basically asking for this feature
>> to be added. if you can add the support in dicom export, then I can do the
>> changes for CreateDICOMSeries.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Kevin
>>
>> On January 27, 2015 at 5:33 PM Csaba Pinter <[hidden email]>
>> wrote:
>>
>> Hi Kevin,
>>
>>
>>
>> This Mantis issue tracks adding an exported series to an existing study:
>>
>> http://www.na-mic.org/Bug/view.php?id=3937
>>
>>
>>
>> I investigated this today, and what I learned is this:
>>
>> - CreateDICOMSeries module (and so the scalar volume plugin) cannot set
>> the
>> study instance UID, it is most probably automatically generated by
>> itk::ExtractImageFilter
>>
>> - Same happens in Plastimatch's Rt_study::save_dicom
>>
>> So it seems that (all) the plugins will need to support adding series to
>> existing study.
>>
>>
>>
>> Also the DICOM export feature needs to support it. I think it should be
>> quite easy on this level: the study nodes need to store their UIDs if
>> imported from DICOM, and if it exists, then the exporter only exports the
>> new series under that, passing the study UID to the plugins.
>>
>> I started making some necessary changes, and I'll commit them tomorrow.
>>
>>
>>
>> After that the plugins need to be modified to pass study UID to their
>> respective exporters, including the new SegObj one.
>>
>>
>>
>> csaba
>>
>>
>>
>> From: Steve Pieper [mailto:[hidden email]]
>> Sent: January 27, 2015 13:37
>> To: Kevin Wang - Techna
>> Cc: Csaba Pinter; slicer-devel; Andras Lasso
>> Subject: Re: [slicer-devel] Create Dicom Series possoble improvement
>>
>>
>>
>> Hi Kevin -
>>
>>
>>
>> You can get a sense of it from the code that Andrey has been developing
>> here:
>>
>>
>>
>> https://github.com/QIICR/Iowa2DICOM
>>
>>
>>
>> https://github.com/QIICR/Iowa2DICOM/tree/master/ConvertSegmentations
>>
>>
>>
>> The changes to dcmtk are not public yet (they will be in a few months --
>> Michael wants to finalize them before putting them out). But you can see
>> them in use in these converter utilities (i.e. look at EncodeSEG).
>>
>>
>>
>> Agreed that for many purposes people will be able to use ITK Readers and
>> Writers to access the functionality, but sometimes it will be better to
>> use
>> the dcmtk api itself.
>>
>>
>>
>> Best,
>>
>> Steve
>>
>>
>>
>> On Tue, Jan 27, 2015 at 12:11 PM, Kevin Wang - Techna
>> <[hidden email]> wrote:
>>
>> Hi Steve,
>>
>>
>>
>> Thanks for your comments. If I understand correctly, you are adding a high
>> level dcmtk api on top of the current low level dcmtk api. then you would
>> like to have ITKDCMTKImageIO to use them for importing/exporting. that all
>> sounds great.
>>
>>
>>
>> What I planned to do was to think of ITKDCMTKImageIO/ITKGDCMImageIO as the
>> high level api which would use the low level dcmtk api. but if you have
>> already got a plan then that is perfect. is there some kind of wiki or
>> documents to describe how the high level dcmtk api looks like?
>>
>>
>>
>> Kevin
>>
>> On January 27, 2015 at 11:32 AM Steve Pieper <[hidden email]> wrote:
>>
>> Hi Kevin -
>>
>>
>>
>> Right now we are mostly focused on the pure dcmtk portion, with some CLIs,
>> mostly for segmentation objects. There's been a lot of progress on this
>> but
>> its not in the dcmtk master yet.
>>
>>
>>
>> Longer term we would like to rethink DWIConvert and ITKDCMTKImageIO to
>> make
>> them use the higher level dcmtk API while adding support for things like
>> DCE
>> and other multiframe DICOM objects.
>>
>>
>>
>> If we do add any support at the CTK level it would probably be in the
>> context of a Qt-style wrapper of the highest level dcmtk API and some
>> integration with the CTK CLI processing. The networking part of DICOM
>> would
>> still be in CTK and not in ITK.
>>
>>
>>
>> Best,
>>
>> Steve
>>
>>
>>
>> On Tue, Jan 27, 2015 at 10:51 AM, Kevin Wang <
>> [hidden email]> wrote:
>>
>> Hi Steve,
>>
>>
>>
>> Thanks for the comments.
>>
>>
>>
>> I also prefer DCMTK to GDCM for dicom reading/writing. will this new
>> dcmtk-based exports code entirely implemented in Slicer or based on ITK or
>> CTK? I ask this since dcmtk support in ITK is very limited currently.
>>
>>
>>
>> Kevin
>>
>> On January 27, 2015 at 10:07 AM Steve Pieper < [hidden email]> wrote:
>>
>> Hi Kevin -
>>
>>
>>
>> I agree, adding features to the current CLI will be helpful given the
>> current implementation of the export process. I'd just point out that
>> before
>> long we'll want to switch to dcmtk-based exports to take advantage of the
>> newer features it has to support multiframe and other dicom objects. I
>> suspect we'll be inspired from the features of the Create a DICOM Series
>> module, but with a pretty fresh implementation.
>>
>>
>>
>> -Steve
>>
>>
>>
>> On Tue, Jan 27, 2015 at 9:06 AM, Kevin Wang <
>> [hidden email]> wrote:
>>
>> Hi Andras and Csaba,
>>
>>
>>
>> I agree that we should start to use the new DICOM export. However, as I
>> understand, the new DICOM export still employs this CLI module for the
>> actual export. so the actual setting up of the UIDs still happens in this
>> module and not at the DICOM export level.
>>
>>
>>
>> so this improvement would actually benefit the DICOM export as well as
>> right
>> now it can only create a new study since it uses this module for actual
>> work.
>>
>>
>>
>> I hope I made it clear. if not, let me know.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Kevin
>>
>>
>>
>>
>>
>> On January 26, 2015 at 4:34 PM Andras Lasso < [hidden email]> wrote:
>>
>> I agree that the old DICOM export mechanism should be deprecated (and
>> removed in the next major version) to reduce software maintenance
>> workload.
>>
>>
>>
>> Andras
>>
>>
>>
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Csaba Pinter
>> Sent: Monday, January 26, 2015 4:00 PM
>> To: Kevin Wang; slicer-devel
>> Subject: Re: [slicer-devel] Create Dicom Series possoble improvement
>>
>>
>>
>> Hi Kevin,
>>
>>
>>
>> I think we should move towards using the new DICOM export mechanism
>> instead
>> of improving this basic module.
>>
>> See
>>
>> http://slicer-devel.65872.n3.nabble.com/FW-slicer-users-Create-a-DICOM-series-module-change-DOB-td4033014.html
>>
>>
>>
>> Can you perform what you want with the new DICOM export?
>>
>>
>>
>> csaba
>>
>>
>>
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Kevin Wang
>> Sent: January 26, 2015 14:30
>> To: slicer-devel
>> Subject: [slicer-devel] Create Dicom Series possoble improvement
>>
>>
>>
>> Hi All,
>>
>>
>>
>> Recently I used the "Create Dicom Series" CLI module. However, I
>> encountered
>> a bit limitation of the module. The module works well creating a new study
>> as well new series. However, what I wanted to do is to create a series and
>> add it back to original study. this requires to set the StudyInstatnceUID
>> and FrameOfReferenceUID to be the same as the original study's. I have to
>> do
>> a bit code changes to achieve that.
>>
>>
>>
>> so my question is: does this seems to be a reasonable feature to add to
>> the
>> module? if so, I will create a ticket for this task. also there seems to
>> be
>> no category for this module in Mantis. should I just assign the ticket to
>> Dicom module?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Kevin
>>
>>
>>
>>
>> _______________________________________________
>> slicer-devel mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>> To unsubscribe: send email to [hidden email] with
>> unsubscribe as the subject
>>
>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>
>>
>> The information in this e-mail is intended only for the person to whom it
>> is
>> addressed. If you believe this e-mail was sent to you in error and the
>> e-mail
>> contains patient information, please contact the Partners Compliance
>> HelpLine at
>> http://www.partners.org/complianceline . If the e-mail was sent to you in
>> error
>> but does not contain patient information, please contact the sender and
>> properly
>> dispose of the e-mail.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> slicer-devel mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>> To unsubscribe: send email to [hidden email] with
>> unsubscribe as the subject
>>
>> http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ
>>
>>
>> The information in this e-mail is intended only for the person to whom it
>> is
>> addressed. If you believe this e-mail was sent to you in error and the
>> e-mail
>> contains patient information, please contact the Partners Compliance
>> HelpLine at
>> http://www.partners.org/complianceline . If the e-mail was sent to you in
>> error
>> but does not contain patient information, please contact the sender and
>> properly
>> dispose of the e-mail.
>>
_______________________________________________
slicer-devel mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ