Terminologies and Segment Editor

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

Terminologies and Segment Editor

Fernando Pérez-García
Hi all,

I've seen in the latest nightly that Terminologies have been added. It looks
promising, but I don't know how to add a custom terminology and the link in
the "Help & Acknowledgement" button takes to an empty page.

Also, when modifying a segment color in the Segment Editor module, I think
it would be useful to name the segment after the selected "Property type" in
the Terminology widget. What do you think?


Best,

Fernando



--
View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031209.html
Sent from the slicer-users mailing list archive at Nabble.com.
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Andrey Fedorov-2
Hi Fernando,

thanks for your email, and interest in this development! I actually
didn't realize it already made it into the nightly - great job, Csaba!

> I've seen in the latest nightly that Terminologies have been added. It looks
> promising, but I don't know how to add a custom terminology and the link in
> the "Help & Acknowledgement" button takes to an empty page.
>

The module is in its very early stages of development. We do plan to
work on documentation and user-level tools to configure new
terminologies.

At the moment, terminologies are formalized using JSON files. We
currently have two terminology dictionaries for segmentation
category/type, and one for anatomical locations, available here [1].
We do plan to support a process where new dictionaries could be
contributed by the users as needed for specific applications.

[1] https://github.com/QIICR/dcmqi/tree/master/doc/segContexts

> Also, when modifying a segment color in the Segment Editor module, I think
> it would be useful to name the segment after the selected "Property type" in
> the Terminology widget. What do you think?
>

I completely agree with you. This is something we've been discussing,
and will implement support for assigning more meaningful names to the
segments - see the discussion in [2].

Our development timeline is a worked out example supporting
segmentation, calculation of measurements and round-trip communication
of DICOM-encoded results by the end of November. We will focus on
improvements after that.

Glad to see your interest! If you have any other suggestions/features,
or would like to discuss the area of your interest, please let me know
in this thread, or in a direct email.

[2] https://github.com/QIICR/Reporting/issues/79

>
> Best,
>
> Fernando
>
>
>
> --
> View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031209.html
> Sent from the slicer-users mailing list archive at Nabble.com.
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
Hi Andrey,

I'm back to trying the new Terminologies. I am, however, still struggling
with the rigidity of this new system, compared to the old color tables. What
I'd like to have is:
 - User clicks on new segment's color selector
 - They see a list of *custom* structures and their corresponding color
(terminology or color table created by me)
 - They click on a structure, so the segment has now its name and color

Sorry I haven't gone through the whole Github conversation. Are there any
updates/plans to make the widget behave as proposed?

I tried creating a small JSON terminology, similar to the default ones I
found in the repository. I put it in same directory as the other ones, but
Slicer didn't read it. Is there something I could do about that?


Best,

Fernando



--
View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031554.html
Sent from the slicer-users mailing list archive at Nabble.com.
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
This post has NOT been accepted by the mailing list yet.
In reply to this post by Andrey Fedorov-2
Hi Andrey,

I'm back to trying the new Terminologies. I am, however, still struggling with the rigidity of this new system, compared to the old color tables. What I'd like to have is:
 - User clicks on new segment's color selector
 - They see a list of custom structures and their corresponding color (terminology or color table created by me)
 - They click on a structure, so the segment has now its name and color

Sorry I haven't gone through the whole Github conversation. Are there any updates/plans to make the widget behave as proposed?

I tried creating a small JSON terminology, similar to the default ones I found in the repository. I put it in same directory as the other ones, but Slicer didn't read it. Is there something I could do about that?


Best,

Fernando
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Csaba Pinter-2
In reply to this post by Fernando Pérez-García
Hi Fernando,

On the very short term, you can do this
>>> tl=slicer.modules.terminologies.logic()
>>> tl.LoadTerminologyFromFile(myFile)
You can add this to the slicerrc python file so that it's always loaded.

On the slightly longer term I can add auto-discovery of json files in a specific folder (TBD) as you mentioned, or a Load terminology button in the Terminologies module.
We are continually working on the terminologies feature, making it easier to use and more flexible. So far the related issues were on https://github.com/QIICR/QuantitativeReporting/issues (because it is part of the QIICR project and was a feature to be added for RSNA), but you can add then to mantis now that it's part of Slicer.

csaba

-----Original Message-----
From: slicer-users [mailto:[hidden email]] On Behalf Of Fernando Pérez-García
Sent: Thursday, January 12, 2017 04:44
To: SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

Hi Andrey,

I'm back to trying the new Terminologies. I am, however, still struggling with the rigidity of this new system, compared to the old color tables. What I'd like to have is:
 - User clicks on new segment's color selector
 - They see a list of *custom* structures and their corresponding color (terminology or color table created by me)
 - They click on a structure, so the segment has now its name and color

Sorry I haven't gone through the whole Github conversation. Are there any updates/plans to make the widget behave as proposed?

I tried creating a small JSON terminology, similar to the default ones I found in the repository. I put it in same directory as the other ones, but Slicer didn't read it. Is there something I could do about that?


Best,

Fernando



--
View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031554.html
Sent from the slicer-users mailing list archive at Nabble.com.
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
Hi Csaba,

Thanks, I'll try and let you know if it worked.

Have you finally decided not to use the structure's name for the segment?


Fernando



--
View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031585.html
Sent from the slicer-users mailing list archive at Nabble.com.
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
This post has NOT been accepted by the mailing list yet.
In reply to this post by Csaba Pinter-2
Hi Csaba,

Thanks, I'll try and let you know if it worked.

Have you finally decided not to use the structure's name for the segment?


Fernando
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Csaba Pinter-2
In reply to this post by Fernando Pérez-García
Not sure I understand the question.

csaba

-----Original Message-----
From: slicer-users [mailto:[hidden email]] On Behalf Of Fernando Pérez-García
Sent: Tuesday, January 17, 2017 09:40
To: SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

Hi Csaba,

Thanks, I'll try and let you know if it worked.

Have you finally decided not to use the structure's name for the segment?


Fernando



--
View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031585.html
Sent from the slicer-users mailing list archive at Nabble.com.
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Andrey Fedorov-2
In reply to this post by Fernando Pérez-García
> Have you finally decided not to use the structure's name for the segment?

Fernando, what do you mean?

On Tue, Jan 17, 2017 at 9:40 AM, Fernando Pérez-García
<[hidden email]> wrote:

> Hi Csaba,
>
> Thanks, I'll try and let you know if it worked.
>
> Have you finally decided not to use the structure's name for the segment?
>
>
> Fernando
>
>
>
> --
> View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031585.html
> Sent from the slicer-users mailing list archive at Nabble.com.
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
In reply to this post by Fernando Pérez-García
​Sorry, I meant what I had asked previously on this thread:

> Also, when modifying a segment color in the Segment Editor module, I think 
> it would be useful to name the segment after the selected "Property type" in 
> the Terminology widget. What do you think? 
> 


I partially read your discussion about it on Github, but I wasn't sure of the conclusion.

However I just tried and it works as expected now: when I choose a structure on the Terminologies widget when clicking on the color label of a segment in the Segment Editor, the name of the structure is copied to the name of the segment. Cool!

I think I hadn't seen this working because of the issue with ITK and Linux nightlies: http://na-mic.org/Mantis/view.php?id=4301

Thanks for the support and for your work!


Best,
Fernando


2017-01-17 16:45 GMT+01:00 Andrey Fedorov <[hidden email]>:
> Have you finally decided not to use the structure's name for the segment?

Fernando, what do you mean?

On Tue, Jan 17, 2017 at 9:40 AM, Fernando Pérez-García
<[hidden email]> wrote:
> Hi Csaba,
>
> Thanks, I'll try and let you know if it worked.
>
> Have you finally decided not to use the structure's name for the segment?
>
>
> Fernando
>
>
>
> --
> View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031585.html
> Sent from the slicer-users mailing list archive at Nabble.com.
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Andrey Fedorov-2
In reply to this post by Fernando Pérez-García
Ah, yes - right. This was finalized. The default segment name is
initialized from the segment category type code meaning. You can
change that automatically populated name manually if needed. Glad to
hear that this feature is helpful to you!

On Tue, Jan 17, 2017 at 10:50 AM, Fernando Pérez-García
<[hidden email]> wrote:

> Sorry, I meant what I had asked previously on this thread:
>
>> Also, when modifying a segment color in the Segment Editor module, I think
>> it would be useful to name the segment after the selected "Property type"
>> in
>> the Terminology widget. What do you think?
>>
>
>
> I partially read your discussion about it on Github, but I wasn't sure of
> the conclusion.
>
> However I just tried and it works as expected now: when I choose a structure
> on the Terminologies widget when clicking on the color label of a segment in
> the Segment Editor, the name of the structure is copied to the name of the
> segment. Cool!
>
> I think I hadn't seen this working because of the issue with ITK and Linux
> nightlies: http://na-mic.org/Mantis/view.php?id=4301
>
> Thanks for the support and for your work!
>
>
> Best,
> Fernando
>
>
> 2017-01-17 16:45 GMT+01:00 Andrey Fedorov <[hidden email]>:
>>
>> > Have you finally decided not to use the structure's name for the
>> > segment?
>>
>> Fernando, what do you mean?
>>
>> On Tue, Jan 17, 2017 at 9:40 AM, Fernando Pérez-García
>> <[hidden email]> wrote:
>> > Hi Csaba,
>> >
>> > Thanks, I'll try and let you know if it worked.
>> >
>> > Have you finally decided not to use the structure's name for the
>> > segment?
>> >
>> >
>> > Fernando
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> > http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031585.html
>> > Sent from the slicer-users mailing list archive at Nabble.com.
>> > _______________________________________________
>> > slicer-users mailing list
>> > [hidden email]
>> > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>> > To unsubscribe: send email to [hidden email] with
>> > unsubscribe as the subject
>> > http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>
>
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Csaba Pinter-2
In reply to this post by Fernando Pérez-García

Hi Fernando,

 

This feature is very new and is continually improved, and this is why there are some inconveniences. One fewer now at least :)

The next step for me is to add auto-discovery feature so that json files added to the folder will also loaded.

 

Please don’t stop reporting such issues, these are helpful!

 

csaba

 

From: slicer-users [mailto:[hidden email]] On Behalf Of Fernando Pérez-García
Sent: Tuesday, January 17, 2017 10:50
To: Andrey Fedorov <[hidden email]>
Cc: SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

 

​Sorry, I meant what I had asked previously on this thread:

 

> Also, when modifying a segment color in the Segment Editor module, I think 
> it would be useful to name the segment after the selected "Property type" in 
> the Terminology widget. What do you think? 

 

 

I partially read your discussion about it on Github, but I wasn't sure of the conclusion.

 

However I just tried and it works as expected now: when I choose a structure on the Terminologies widget when clicking on the color label of a segment in the Segment Editor, the name of the structure is copied to the name of the segment. Cool!

 

I think I hadn't seen this working because of the issue with ITK and Linux nightlies: http://na-mic.org/Mantis/view.php?id=4301

 

Thanks for the support and for your work!

 

 

Best,

Fernando

 

 

2017-01-17 16:45 GMT+01:00 Andrey Fedorov <[hidden email]>:

> Have you finally decided not to use the structure's name for the segment?

Fernando, what do you mean?

On Tue, Jan 17, 2017 at 9:40 AM, Fernando Pérez-García
<[hidden email]> wrote:
> Hi Csaba,
>
> Thanks, I'll try and let you know if it worked.
>
> Have you finally decided not to use the structure's name for the segment?
>
>
> Fernando
>
>
>
> --
> View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031585.html

> Sent from the slicer-users mailing list archive at Nabble.com.
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ

 


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
In reply to this post by Fernando Pérez-García

 

Please don’t stop reporting such issues, these are helpful!


​Be careful ​what you ask, I'll keep having issues ;)


I'm glad we're helping each other!
















 

 

csaba

 

From: slicer-users [mailto:[hidden email]] On Behalf Of Fernando Pérez-García
Sent: Tuesday, January 17, 2017 10:50
To: Andrey Fedorov <[hidden email]>
Cc: SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

 

​Sorry, I meant what I had asked previously on this thread:

 

> Also, when modifying a segment color in the Segment Editor module, I think 
> it would be useful to name the segment after the selected "Property type" in 
> the Terminology widget. What do you think? 

 

 

I partially read your discussion about it on Github, but I wasn't sure of the conclusion.

 

However I just tried and it works as expected now: when I choose a structure on the Terminologies widget when clicking on the color label of a segment in the Segment Editor, the name of the structure is copied to the name of the segment. Cool!

 

I think I hadn't seen this working because of the issue with ITK and Linux nightlies: http://na-mic.org/Mantis/view.php?id=4301

 

Thanks for the support and for your work!

 

 

Best,

Fernando

 

 

2017-01-17 16:45 GMT+01:00 Andrey Fedorov <[hidden email]>:

> Have you finally decided not to use the structure's name for the segment?

Fernando, what do you mean?

On Tue, Jan 17, 2017 at 9:40 AM, Fernando Pérez-García
<[hidden email]> wrote:
> Hi Csaba,
>
> Thanks, I'll try and let you know if it worked.
>
> Have you finally decided not to use the structure's name for the segment?
>
>
> Fernando
>
>
>
> --
> View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031585.html

> Sent from the slicer-users mailing list archive at Nabble.com.
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ

 



_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
Hi again,

I have created my terminology and I'm happy to see that it works as
expected. The widget is very elegant.

Yesterday was pretty much the first time in my life I opened a JSON file and
I don't understand most of the fields in Slicer terminologies files, so I
decided to just copy one of the defaults and edit it. I deleted what I
didn't need, edit the names and colors and voilà. All the "contextGroupName"
fields are wrong, but I guess it doesn't matter for my project. I have
attached my little terminology.

I have a larger color table I would like to transform into a terminology,
but with all those codes I'm not sure how I'm going to do it.


When there are many types, I think it would be useful to update the
modifiers combo box when moving using the keyboard instead of clicking on
the mouse. I don't know much about C++ either, but I've dug a bit and I
guess the change would be using the "itemChanged" signal instead of
"itemClicked" [1, 2].


Fernando


[1]
https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L218
[2]
https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L1443





--
View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031631.html
Sent from the slicer-users mailing list archive at Nabble.com.
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
This post has NOT been accepted by the mailing list yet.
In reply to this post by Fernando Pérez-García
Hi again,

I have created my terminology and I'm happy to see that it works as expected. The widget is very elegant.

Yesterday was pretty much the first time in my life I opened a JSON file and I don't understand most of the fields in Slicer terminologies files, so I decided to just copy one of the defaults and edit it. I deleted what I didn't need, edit the names and colors and voilà. All the "contextGroupName" fields are wrong, but I guess it doesn't matter for my project. I have attached my little terminology.

I have a larger color table I would like to transform into a terminology, but with all those codes I'm not sure how I'm going to do it.


When there are many types, I think it would be useful to update the modifiers combo box when moving using the keyboard instead of clicking on the mouse. I don't know much about C++ either, but I've dug a bit and I guess the change would be using the "itemChanged" signal instead of "itemClicked" [1, 2].


Fernando


[1] https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L218
[2] https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L1443

Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Csaba Pinter-2
In reply to this post by Fernando Pérez-García
Hi Fernando,

I fiddled with the key actions a bit a few weeks ago. itemChanged is emitted when the item itself is changed, not the selection, but currentIndexChanged or itemSelectionChanged are good candidates. Unfortunately I hit a few problems and then we had to leave for the project week, but was planning to look into that again.
I wanted to wait for the RapidJson switch before I touch terminologies again, but as I see it was integrated last night, so I can start now.

About the color table to terminology conversion, there could be a reasonable way of doing that automatically if this operation is expected to be needed frequently in the future. There are only three fields that are mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There are two more that are used: 3dSlicerLabel to automatically set the segment name (if absent, it is set, but it is assembled from the type and region information), and recommendedDisplayRGBValue to set the segment color.
I think we could write a converter that takes a color table and creates the terminology context:
- Context name to be the name of the color table
- As there is no category information in the color table, there could be only one category with the same name as the context
- Type entries from the colors
  - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
  - recommendedDisplayRGBValue from the color
  - CodingSchemeDesignator TBD (I don't know enough about how it's used, but naively I'd set the context name here as well)
- No type modifiers
- As region information comes from a different dictionary, it could be used as it is now. The only decision to make is whether the terminology enables region information at all. It can be done by setting the category element showAnatomy (true to enable).

I can implement this converter option in the Terminologies module if others agree on its utility. The details are subject to discussion of course.

csaba

-----Original Message-----
From: slicer-users [mailto:[hidden email]] On Behalf Of Fernando Pérez-García
Sent: Friday, January 20, 2017 05:21
To: SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

Hi again,

I have created my terminology and I'm happy to see that it works as expected. The widget is very elegant.

Yesterday was pretty much the first time in my life I opened a JSON file and I don't understand most of the fields in Slicer terminologies files, so I decided to just copy one of the defaults and edit it. I deleted what I didn't need, edit the names and colors and voilà. All the "contextGroupName"
fields are wrong, but I guess it doesn't matter for my project. I have attached my little terminology.

I have a larger color table I would like to transform into a terminology, but with all those codes I'm not sure how I'm going to do it.


When there are many types, I think it would be useful to update the modifiers combo box when moving using the keyboard instead of clicking on the mouse. I don't know much about C++ either, but I've dug a bit and I guess the change would be using the "itemChanged" signal instead of "itemClicked" [1, 2].


Fernando


[1]
https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L218
[2]
https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L1443





--
View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031631.html
Sent from the slicer-users mailing list archive at Nabble.com.
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
In reply to this post by Fernando Pérez-García


2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
Hi Fernando,

I fiddled with the key actions a bit a few weeks ago. itemChanged is emitted when the item itself is changed, not the selection, but currentIndexChanged or itemSelectionChanged are good candidates. Unfortunately I hit a few problems and then we had to leave for the project week, but was planning to look into that again.

​​Right, I actually meant itemActivated().​​

 
I wanted to wait for the RapidJson switch before I touch terminologies again, but as I see it was integrated last night, so I can start now.

About the color table to terminology conversion, there could be a reasonable way of doing that automatically if this operation is expected to be needed frequently in the future. There are only three fields that are mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There are two more that are used: 3dSlicerLabel to automatically set the segment name (if absent, it is set, but it is assembled from the type and region information), and recommendedDisplayRGBValue to set the segment color.

​If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and contextGroupName​, will my terminology still be valid?

 
I think we could write a converter that takes a color table and creates the terminology context:
- Context name to be the name of the color table
- As there is no category information in the color table, there could be only one category with the same name as the context
- Type entries from the colors
  - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
  - recommendedDisplayRGBValue from the color
  - CodingSchemeDesignator TBD (I don't know enough about how it's used, but naively I'd set the context name here as well)
- No type modifiers
- As region information comes from a different dictionary, it could be used as it is now. The only decision to make is whether the terminology enables region information at all. It can be done by setting the category element showAnatomy (true to enable).

I can implement this converter option in the Terminologies module if others agree on its utility. The details are subject to discussion of course.

​I think this + some documentation would be very useful!

Fernando





 

csaba

-----Original Message-----
From: slicer-users [mailto:[hidden email]] On Behalf Of Fernando Pérez-García
Sent: Friday, January 20, 2017 05:21
To: SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

Hi again,

I have created my terminology and I'm happy to see that it works as expected. The widget is very elegant.

Yesterday was pretty much the first time in my life I opened a JSON file and I don't understand most of the fields in Slicer terminologies files, so I decided to just copy one of the defaults and edit it. I deleted what I didn't need, edit the names and colors and voilà. All the "contextGroupName"
fields are wrong, but I guess it doesn't matter for my project. I have attached my little terminology.

I have a larger color table I would like to transform into a terminology, but with all those codes I'm not sure how I'm going to do it.


When there are many types, I think it would be useful to update the modifiers combo box when moving using the keyboard instead of clicking on the mouse. I don't know much about C++ either, but I've dug a bit and I guess the change would be using the "itemChanged" signal instead of "itemClicked" [1, 2].


Fernando


[1]
https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L218
[2]
https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L1443





--
View this message in context: http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031631.html
Sent from the slicer-users mailing list archive at Nabble.com.
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Andrey Fedorov-2
Fernando, Csaba,

As the background, let me explain where existing segmentation contexts
are coming from.

The first context
https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-DICOM-Master.json
contains all (or most) of the segmentation category/type codes listed
in DICOM part 16 as of some point in the past. It was created based on
earlier work by David Clunie, who either manually or
semi-automatically looked at the context groups in DICOM part 16, and
extracted the information from the tables like this one [1] for
example (and you can see many more CIDs with segmentation types here
[2]), into the form we used for JSON.

As you can see from [1], that table defines the mapping of the SRT
coding scheme code into the other codes that are listed in the JSON
context document. The purpose of this mapping is to enable
cross-linking of the concepts across different
terminologies/ontologies. So "contextGroupName", "UMLSConceptID",
"cid", "CodeValue", "CodeMeaning", "CodingSchemeDesignator",
"SNOMEDConceptID" all come from the definition like [1].

One challenge in this translation task is that you need to have domain
knowledge and put manual effort into defining certain aspects, since
for example, Modifier is applicable only for structures that have
laterality, and that part is not explicitly reflected in the CID
tables. This domain knowledge is what adds "Modifier" part of the
segmentation context.

Segmentation property categories are defined by this table [3], and
"showAnatomy" flag assigned for each Category is also something that
is not formalized by the standard, but is "domain knowledge" (or
"black magic", depending how you want to call it!). That flag tells if
it makes sense to give user an option to define anatomic location for
the given segmentation, and those in turn are formalized by this
anatomic context:

The second, smaller segmentation context
https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json
was created very painstakingly by going over the Slicer
GenericAnatomyLUT [4] (which only containted freetext labels and
colors) and mapping those one by one to either an existing concept in
the standard, or finding the concept in SNOMED, which resulted in [5].
The SNOMED concepts that were needed to describe labels in the Slicer
GenericAnatomyLUT but were missing in DICOM were added in this
correction proposal to the standard [6]. We kept "3dSlicerLabel"
attribute to maintain the link to the LUT. RGB color in both contexts
is mapped from that LUT.

One more thing that you need to understand is what
CodingSchemeDesignator means. These refer to lists of codes maintained
by specific entities/organizations. You can find the list of coding
schemes that are used in DICOM in [7].

With that background, if you are still with me, let me get to your
question. I think there are two approaches:

1. "Proper/painful" approach: follow the process we used to map Slicer
LUT to DICOM/SNOMED codes. For each item you have in your list, look
for the same/similar in DICOM part 16, and create something that looks
similar to Slicer segmentation/category type JSON. This approach will
take time (depending on the length of your list), but is your best
shot at interoperability and helping other people make sense out of
your data.

2. "Easy" approach: as defined in [7], you can establish your own
coding scheme (pick your own name for CodingSchemeDesignator that
starts with 99), and define unique codes for each of the items in your
list under your coding scheme. This approach can be used to formalize
data collection within your group, if you don't have
time/expertise/desire to follow approach 1.

Does this help at all?

Sorry about very limited documentation. We are working on it. I should
probably add the explanation above somewhere to the documentation of
dcmqi here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the
main location for the documentation that maintains these segmentation
contexts).

You forgot to attach your LUT to your earlier email.

AF



[1] example of segmentation property type CID:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7152.html#table_CID_7152
[2] DICOM part 16:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/PS3.16.html
[3] segmentation property categories CID:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7150.html
[4] https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/LookupTables/GenericAnatomyColors
[5] https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporting
[6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
[7] coding schemes:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html

On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García
<[hidden email]> wrote:

>
>
> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>>
>> Hi Fernando,
>>
>> I fiddled with the key actions a bit a few weeks ago. itemChanged is
>> emitted when the item itself is changed, not the selection, but
>> currentIndexChanged or itemSelectionChanged are good candidates.
>> Unfortunately I hit a few problems and then we had to leave for the project
>> week, but was planning to look into that again.
>
>
> Right, I actually meant itemActivated().
>
>
>>
>> I wanted to wait for the RapidJson switch before I touch terminologies
>> again, but as I see it was integrated last night, so I can start now.
>>
>> About the color table to terminology conversion, there could be a
>> reasonable way of doing that automatically if this operation is expected to
>> be needed frequently in the future. There are only three fields that are
>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There are two
>> more that are used: 3dSlicerLabel to automatically set the segment name (if
>> absent, it is set, but it is assembled from the type and region
>> information), and recommendedDisplayRGBValue to set the segment color.
>
>
> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and contextGroupName,
> will my terminology still be valid?
>
>
>>
>> I think we could write a converter that takes a color table and creates
>> the terminology context:
>> - Context name to be the name of the color table
>> - As there is no category information in the color table, there could be
>> only one category with the same name as the context
>> - Type entries from the colors
>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>>   - recommendedDisplayRGBValue from the color
>>   - CodingSchemeDesignator TBD (I don't know enough about how it's used,
>> but naively I'd set the context name here as well)
>> - No type modifiers
>> - As region information comes from a different dictionary, it could be
>> used as it is now. The only decision to make is whether the terminology
>> enables region information at all. It can be done by setting the category
>> element showAnatomy (true to enable).
>>
>> I can implement this converter option in the Terminologies module if
>> others agree on its utility. The details are subject to discussion of
>> course.
>
>
> I think this + some documentation would be very useful!
>
> Fernando
>
>
>
>
>
>
>>
>>
>> csaba
>>
>> -----Original Message-----
>> From: slicer-users [mailto:[hidden email]] On Behalf
>> Of Fernando Pérez-García
>> Sent: Friday, January 20, 2017 05:21
>> To: SPL Slicer Users <[hidden email]>
>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>>
>> Hi again,
>>
>> I have created my terminology and I'm happy to see that it works as
>> expected. The widget is very elegant.
>>
>> Yesterday was pretty much the first time in my life I opened a JSON file
>> and I don't understand most of the fields in Slicer terminologies files, so
>> I decided to just copy one of the defaults and edit it. I deleted what I
>> didn't need, edit the names and colors and voilà. All the "contextGroupName"
>> fields are wrong, but I guess it doesn't matter for my project. I have
>> attached my little terminology.
>>
>> I have a larger color table I would like to transform into a terminology,
>> but with all those codes I'm not sure how I'm going to do it.
>>
>>
>> When there are many types, I think it would be useful to update the
>> modifiers combo box when moving using the keyboard instead of clicking on
>> the mouse. I don't know much about C++ either, but I've dug a bit and I
>> guess the change would be using the "itemChanged" signal instead of
>> "itemClicked" [1, 2].
>>
>>
>> Fernando
>>
>>
>> [1]
>>
>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L218
>> [2]
>>
>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L1443
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031631.html
>> Sent from the slicer-users mailing list archive at Nabble.com.
>> _______________________________________________
>> slicer-users mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>> To unsubscribe: send email to [hidden email] with
>> unsubscribe as the subject
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>
>
>
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with
> unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
In reply to this post by Fernando Pérez-García
HI Andrey,



2017-01-20 16:23 GMT+01:00 Andrey Fedorov <[hidden email]>:
Fernando, Csaba,

As the background, let me explain where existing segmentation contexts
are coming from.

​[...]​


Does this help at all?
 

​Yes, it's a lot of info, but certainly clarifying. I think I'll try option #2 for now.

What if you wanted very customized types? For example I want to segment animals from a photo using Slicer (who knows) and I need a "Dog" and "Cat" types. How would you handle the mandatory fields?




​​
You forgot to attach your LUT to your earlier email.

I tried to upload it on Nabble, I guess I did something wrong. Here it goes.​


​Fernando
























 
AF



[1] example of segmentation property type CID:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7152.html#table_CID_7152
[2] DICOM part 16:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/PS3.16.html
[3] segmentation property categories CID:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7150.html
[4] https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/LookupTables/GenericAnatomyColors
[5] https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporting
[6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
[7] coding schemes:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html

On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García
<[hidden email]> wrote:
>
>
> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>>
>> Hi Fernando,
>>
>> I fiddled with the key actions a bit a few weeks ago. itemChanged is
>> emitted when the item itself is changed, not the selection, but
>> currentIndexChanged or itemSelectionChanged are good candidates.
>> Unfortunately I hit a few problems and then we had to leave for the project
>> week, but was planning to look into that again.
>
>
> Right, I actually meant itemActivated().
>
>
>>
>> I wanted to wait for the RapidJson switch before I touch terminologies
>> again, but as I see it was integrated last night, so I can start now.
>>
>> About the color table to terminology conversion, there could be a
>> reasonable way of doing that automatically if this operation is expected to
>> be needed frequently in the future. There are only three fields that are
>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There are two
>> more that are used: 3dSlicerLabel to automatically set the segment name (if
>> absent, it is set, but it is assembled from the type and region
>> information), and recommendedDisplayRGBValue to set the segment color.
>
>
> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and contextGroupName,
> will my terminology still be valid?
>
>
>>
>> I think we could write a converter that takes a color table and creates
>> the terminology context:
>> - Context name to be the name of the color table
>> - As there is no category information in the color table, there could be
>> only one category with the same name as the context
>> - Type entries from the colors
>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>>   - recommendedDisplayRGBValue from the color
>>   - CodingSchemeDesignator TBD (I don't know enough about how it's used,
>> but naively I'd set the context name here as well)
>> - No type modifiers
>> - As region information comes from a different dictionary, it could be
>> used as it is now. The only decision to make is whether the terminology
>> enables region information at all. It can be done by setting the category
>> element showAnatomy (true to enable).
>>
>> I can implement this converter option in the Terminologies module if
>> others agree on its utility. The details are subject to discussion of
>> course.
>
>
> I think this + some documentation would be very useful!
>
> Fernando
>
>
>
>
>
>
>>
>>
>> csaba
>>
>> -----Original Message-----
>> From: slicer-users [mailto:[hidden email]] On Behalf
>> Of Fernando Pérez-García
>> Sent: Friday, January 20, 2017 05:21
>> To: SPL Slicer Users <[hidden email]>
>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>>
>> Hi again,
>>
>> I have created my terminology and I'm happy to see that it works as
>> expected. The widget is very elegant.
>>
>> Yesterday was pretty much the first time in my life I opened a JSON file
>> and I don't understand most of the fields in Slicer terminologies files, so
>> I decided to just copy one of the defaults and edit it. I deleted what I
>> didn't need, edit the names and colors and voilà. All the "contextGroupName"
>> fields are wrong, but I guess it doesn't matter for my project. I have
>> attached my little terminology.
>>
>> I have a larger color table I would like to transform into a terminology,
>> but with all those codes I'm not sure how I'm going to do it.
>>
>>
>> When there are many types, I think it would be useful to update the
>> modifiers combo box when moving using the keyboard instead of clicking on
>> the mouse. I don't know much about C++ either, but I've dug a bit and I
>> guess the change would be using the "itemChanged" signal instead of
>> "itemClicked" [1, 2].
>>
>>
>> Fernando
>>
>>
>> [1]
>>
>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L218
>> [2]
>>
>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNavigatorWidget.cxx#L1443
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Editor-tp4031210p4031631.html
>> Sent from the slicer-users mailing list archive at Nabble.com.
>> _______________________________________________
>> slicer-users mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>> To unsubscribe: send email to [hidden email] with
>> unsubscribe as the subject
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>
>
>
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with
> unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ


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

MonkeyBrainstemTerminology.json (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Csaba Pinter-2
In reply to this post by Fernando Pérez-García
Hi Fernando and Andrey,

Easy things first:
"If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and contextGroupName, will my terminology still be valid?"
Yes, at least in the scope of the current Slicer implementation.

Now about the custom terminologies. With the proposed converter I quickly drafted, which falls in the second "easy" approach Andrey mentioned, we would probably further increase complexity and decrease interoperability. We talked with Andras, and I think we found a relatively easy-to-implement way for the "proper" approach, in the form of the quick lists that we have been planning all along, albeit a slightly different design.

Basically instead of curating custom json dictionaries, we'd mainly use the default ones defined already in Slicer, and save the quick lists (presets/templates/etc.) to csv files, containing the detailed terminology information similarly to how it's already stored for each segment, see attached file to see its proposed structure. It would be these csv files that are read automatically from disk when starting Slicer, stored in a private scene (exactly for the analogy of the volume rendering presets). The easiest way to store these quick lists in the private scene are dummy segmentation nodes, with the segments being the quick list items storing all terminology information but no image or other data. The user could create new quick lists and edit existing ones in the Terminologies module, by selecting entries in the terminology navigator widget (which appears when double-clicking the color for a segment, and is basically the Terminologies module UI currently), and adding/setting the selection to the selected segment in the quick list table. After the quick list is defined, when the user double-clicks color in Segment editor or Segmentations, the quick list would pop up (under quick list selector combobox), with all terminology controls present but by default collapsed (in case he wants to select something that is not in the quick list). These details can be worked out later.

Fernando's dog and cat use case could be accommodated by creating new Json dictionaries, that can also be used to populate a quick list.

The advantage of this plan is that it addresses the use cases we already discussed, and would be relatively easy to implement. Also it wouldn't introduce new formats, and wouldn't create completely new dictionaries from every color table as my previous suggestion would have.

Please let me know what you think.

csaba

-----Original Message-----
From: Andrey Fedorov [mailto:[hidden email]]
Sent: Friday, January 20, 2017 10:23
To: Fernando Pérez-García <[hidden email]>
Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

Fernando, Csaba,

As the background, let me explain where existing segmentation contexts are coming from.

The first context
https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-DICOM-Master.json
contains all (or most) of the segmentation category/type codes listed in DICOM part 16 as of some point in the past. It was created based on earlier work by David Clunie, who either manually or semi-automatically looked at the context groups in DICOM part 16, and extracted the information from the tables like this one [1] for example (and you can see many more CIDs with segmentation types here [2]), into the form we used for JSON.

As you can see from [1], that table defines the mapping of the SRT coding scheme code into the other codes that are listed in the JSON context document. The purpose of this mapping is to enable cross-linking of the concepts across different terminologies/ontologies. So "contextGroupName", "UMLSConceptID", "cid", "CodeValue", "CodeMeaning", "CodingSchemeDesignator", "SNOMEDConceptID" all come from the definition like [1].

One challenge in this translation task is that you need to have domain knowledge and put manual effort into defining certain aspects, since for example, Modifier is applicable only for structures that have laterality, and that part is not explicitly reflected in the CID tables. This domain knowledge is what adds "Modifier" part of the segmentation context.

Segmentation property categories are defined by this table [3], and "showAnatomy" flag assigned for each Category is also something that is not formalized by the standard, but is "domain knowledge" (or "black magic", depending how you want to call it!). That flag tells if it makes sense to give user an option to define anatomic location for the given segmentation, and those in turn are formalized by this anatomic context:

The second, smaller segmentation context https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json
was created very painstakingly by going over the Slicer GenericAnatomyLUT [4] (which only containted freetext labels and
colors) and mapping those one by one to either an existing concept in the standard, or finding the concept in SNOMED, which resulted in [5].
The SNOMED concepts that were needed to describe labels in the Slicer GenericAnatomyLUT but were missing in DICOM were added in this correction proposal to the standard [6]. We kept "3dSlicerLabel"
attribute to maintain the link to the LUT. RGB color in both contexts is mapped from that LUT.

One more thing that you need to understand is what CodingSchemeDesignator means. These refer to lists of codes maintained by specific entities/organizations. You can find the list of coding schemes that are used in DICOM in [7].

With that background, if you are still with me, let me get to your question. I think there are two approaches:

1. "Proper/painful" approach: follow the process we used to map Slicer LUT to DICOM/SNOMED codes. For each item you have in your list, look for the same/similar in DICOM part 16, and create something that looks similar to Slicer segmentation/category type JSON. This approach will take time (depending on the length of your list), but is your best shot at interoperability and helping other people make sense out of your data.

2. "Easy" approach: as defined in [7], you can establish your own coding scheme (pick your own name for CodingSchemeDesignator that starts with 99), and define unique codes for each of the items in your list under your coding scheme. This approach can be used to formalize data collection within your group, if you don't have time/expertise/desire to follow approach 1.

Does this help at all?

Sorry about very limited documentation. We are working on it. I should probably add the explanation above somewhere to the documentation of dcmqi here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the main location for the documentation that maintains these segmentation contexts).

You forgot to attach your LUT to your earlier email.

AF



[1] example of segmentation property type CID:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7152.html#table_CID_7152
[2] DICOM part 16:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/PS3.16.html
[3] segmentation property categories CID:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7150.html
[4] https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/LookupTables/GenericAnatomyColors
[5] https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporting
[6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
[7] coding schemes:
http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html

On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García <[hidden email]> wrote:

>
>
> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>>
>> Hi Fernando,
>>
>> I fiddled with the key actions a bit a few weeks ago. itemChanged is
>> emitted when the item itself is changed, not the selection, but
>> currentIndexChanged or itemSelectionChanged are good candidates.
>> Unfortunately I hit a few problems and then we had to leave for the
>> project week, but was planning to look into that again.
>
>
> Right, I actually meant itemActivated().
>
>
>>
>> I wanted to wait for the RapidJson switch before I touch
>> terminologies again, but as I see it was integrated last night, so I can start now.
>>
>> About the color table to terminology conversion, there could be a
>> reasonable way of doing that automatically if this operation is
>> expected to be needed frequently in the future. There are only three
>> fields that are
>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There
>> are two more that are used: 3dSlicerLabel to automatically set the
>> segment name (if absent, it is set, but it is assembled from the type
>> and region information), and recommendedDisplayRGBValue to set the segment color.
>
>
> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
> contextGroupName, will my terminology still be valid?
>
>
>>
>> I think we could write a converter that takes a color table and
>> creates the terminology context:
>> - Context name to be the name of the color table
>> - As there is no category information in the color table, there could
>> be only one category with the same name as the context
>> - Type entries from the colors
>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>>   - recommendedDisplayRGBValue from the color
>>   - CodingSchemeDesignator TBD (I don't know enough about how it's
>> used, but naively I'd set the context name here as well)
>> - No type modifiers
>> - As region information comes from a different dictionary, it could
>> be used as it is now. The only decision to make is whether the
>> terminology enables region information at all. It can be done by
>> setting the category element showAnatomy (true to enable).
>>
>> I can implement this converter option in the Terminologies module if
>> others agree on its utility. The details are subject to discussion of
>> course.
>
>
> I think this + some documentation would be very useful!
>
> Fernando
>
>
>
>
>
>
>>
>>
>> csaba
>>
>> -----Original Message-----
>> From: slicer-users [mailto:[hidden email]] On
>> Behalf Of Fernando Pérez-García
>> Sent: Friday, January 20, 2017 05:21
>> To: SPL Slicer Users <[hidden email]>
>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>>
>> Hi again,
>>
>> I have created my terminology and I'm happy to see that it works as
>> expected. The widget is very elegant.
>>
>> Yesterday was pretty much the first time in my life I opened a JSON
>> file and I don't understand most of the fields in Slicer
>> terminologies files, so I decided to just copy one of the defaults
>> and edit it. I deleted what I didn't need, edit the names and colors and voilà. All the "contextGroupName"
>> fields are wrong, but I guess it doesn't matter for my project. I
>> have attached my little terminology.
>>
>> I have a larger color table I would like to transform into a
>> terminology, but with all those codes I'm not sure how I'm going to do it.
>>
>>
>> When there are many types, I think it would be useful to update the
>> modifiers combo box when moving using the keyboard instead of
>> clicking on the mouse. I don't know much about C++ either, but I've
>> dug a bit and I guess the change would be using the "itemChanged"
>> signal instead of "itemClicked" [1, 2].
>>
>>
>> Fernando
>>
>>
>> [1]
>>
>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>> vigatorWidget.cxx#L218
>> [2]
>>
>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>> vigatorWidget.cxx#L1443
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Edi
>> tor-tp4031210p4031631.html Sent from the slicer-users mailing list
>> archive at Nabble.com.
>> _______________________________________________
>> slicer-users mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>> To unsubscribe: send email to [hidden email]
>> with unsubscribe as the subject
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>
>
>
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email]
> with unsubscribe as the subject
> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ

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

TerminologyQuickListTemplate.csv (1K) Download Attachment
12