[Insight-users] Loading DICOM RTStructs

Luis Ibanez luis.ibanez at kitware.com
Wed Oct 21 12:30:59 EDT 2009 

Hi Mark,

About:

> When I make production code, I put the dll's into an include
> directory, and they are automatically copied from there, so that when
> I get a new version of a library, the code is built and the newly
> compiled library is put into the includes directory.  I'm looking for
> something similar with itk.  One of the big reasons I used C# in this
> project is that C# does not require anything other than the compiled
> library, so I didn't have to track down the header file locations of
> what I was trying to use.


Simply "Install" ITK.

On Windows this can be done by

a) Running CMake and defining the directory:

           CMAKE_INSTALL_PREFIX

     to the directory where you want to install ITK after you build it.

     and then

b)  Open the ITK Visual Studio solution file and select the
     INSTALL project, right-click on it, and build it.

     At that point all the ITK headers and libraries will be installed
     in that destination directory.


-----

About:

> As you can see from my code, I really dislike monolithic files.  It's
> just a stylistic choice, but the CMake paradigm adopted in itk
> definitely seems to favor single-file solutions.


That's not quite correct.

CMake actually facilitate the configuration of very large projects.
including projects of the size of  KDE   :-)

If you have a large project, you just need to setup CMakeLists.txt
files in every directory, and defines as many libraries and executable
you want to build.



> Is there a non-CMake
> way to make an itk project?

Sure, if you don't mind typing in the little text boxes of Visual Studio :-)

Simply install ITK in a directory and add the directories to the list
of directories to search for headers. Then do the same for the libraries.


>  I need the header files to link against,
> not just the dlls and libs; is it safe to assume that all the
> necessary files are in itk/code/common?  And is there a reason that
> only the common library is a dll, and all the others are statically
> linked libraries?


Most of ITK is C++ Templates, that's the reason why you end up with
very few libraries, and quite small ones.  In practice, most of the ITK
code is actually compiled when you build your application. Just as
when you use STL.

Note that in practice, the only good reason for building ITK as Shared
libraries is if you are Wrapping for Tcl, Python or Java, or if you hare
creating Plugins for an application.  Apart from those cases, you are
much better off by building ITK as Static libraries.




      Regards,


            Luis




----------------------------------------------------------------------------
On Fri, Oct 16, 2009 at 10:35 PM, Mark Roden <mmroden at gmail.com> wrote:
> Hi Jason,
>
> My C# solution does exactly the same thing, parsing the file into 2d
> planes that are then merged into a 3D volume.  There are tricks that
> I've found; for instance, structs read into Mimvista's software came
> out horizontally flipped after anonymization; I'm not sure if that was
> a result of the anonymization process or if that's just something that
> Mimvista does.  In any event, my code contains a flag to check whether
> or not an image was made using mimvista's software and then flips the
> contour accordingly.
>
> Just looking through your code briefly, does it create a mask with a
> filled polygon, or an outline?  I'm not familiar enough with itk to be
> able to interpret the insertRegion code, or what
> GetLargestPossibleRegion does in the way you've set things up.  Since
> I didn't have the itk stuff (which is probably doing very nice polygon
> handling), my code includes a large chunk on filling in the polygon.
> Some RTstruct files have the polygon described such that each point is
> about 2 pixels from every other point, regardless of whether all the
> points are on a straight line or not, while some have the most
> geometrically simple version of the polygon.  I'm not sure how that
> would affect your code, so I'll take a look at the files I have.
>
> I've attached my project, which does as you describe but in C# and
> using GDCM.  It also has a linear and cubic interpolator that I
> borrowed (and the copyright's in that code) to do image resizing; one
> of the real reasons to adopt itk was to have better resizing
> functions.  If you want to run the results of this code, just put the
> gdcm dlls into the directory with the executable, or have them as part
> of the path.
>
> When I make production code, I put the dll's into an include
> directory, and they are automatically copied from there, so that when
> I get a new version of a library, the code is built and the newly
> compiled library is put into the includes directory.  I'm looking for
> something similar with itk.  One of the big reasons I used C# in this
> project is that C# does not require anything other than the compiled
> library, so I didn't have to track down the header file locations of
> what I was trying to use.  The major drawback is that the C# layer
> doesn't appear to work properly on 64 bit platforms, something I
> haven't had a chance to debug but I suspect lies with the swig
> translation layer.
>
> As you can see from my code, I really dislike monolithic files.  It's
> just a stylistic choice, but the CMake paradigm adopted in itk
> definitely seems to favor single-file solutions.  Is there a non-CMake
> way to make an itk project?  I need the header files to link against,
> not just the dlls and libs; is it safe to assume that all the
> necessary files are in itk/code/common?  And is there a reason that
> only the common library is a dll, and all the others are statically
> linked libraries?
>
> Thanks,
> Mark
>
>>
>> On Fri, Oct 16, 2009 at 4:30 PM,  <Jason.Dowling at csiro.au> wrote:
>>> Hi Mark,
>>>
>>> No I don't use an itk mesh.  I needed a binary volume for each structure  (you can then mesh your binary volume if you want).  In the DICOM RT file each each structure is represented as a set of points for a single slice (nb there might be > 1 sets of points for a single contour in a single slice, eg for bone).   I work on  a  temporary 2D slice which is inserted back into the 3D volume after it's updated.   I use some of Mathieu's code from the excellent GDCM 2.0 library  to extract the RT points.   For each structure region , I  convert the physical RT points into image space and generate pointlist,  which are used to generate  polygon spatial objects for each contour .  Then I use the SpatialObjectToImageFilterType to copy that structure component onto the 2D slice.  And iterate through the RT file:  at the end of I have one binary volume for each structure.
>>>
>>> If anyone's interested, last year I also wrote an itk RTOG file parser which does a similar thing.
>>>
>>> I've sent the code and test data to you - please let me know if you have any feedback?
>>>
>>> Cheers,
>>> Jason
>>>
>>> ________________________________________
>>> From: Mark Roden [mmroden at gmail.com]
>>> Sent: Saturday, 17 October 2009 1:54 AM
>>> To: Dowling, Jason (ICT Centre, Herston - RBWH)
>>> Cc: mathieu.malaterre at gmail.com; insight-users at itk.org; gdcm-developers at lists.sourceforge.net
>>> Subject: Re: [Insight-users] Loading DICOM RTStructs
>>>
>>> Hi Jason,
>>>
>>> That would be very useful, thanks.
>>>
>>> My code, as I said, is written using the C# wrappers to gdcm.  It then
>>> converts the masks into a char image, where a 1 indicates the presence
>>> of a mask and a 0 does not, and I was going to implement a marching
>>> squares algorithm to go back to an rtstruct.  I'm guessing that your
>>> code goes to an itk mesh; is there a way to convert a mesh into an
>>> image and back again?  I'm messing around with segmentations, and the
>>> papers I'm finding are all pixel-based rather than mesh-based, so
>>> getting the mesh is just part of the problem.
>>>
>>> Thanks!
>>> Mark
>>>
>>> On Fri, Oct 16, 2009 at 12:27 AM,  <Jason.Dowling at csiro.au> wrote:
>>>> Hi Mathieu and Mark,
>>>>
>>>> Yes, I've written a C++ DICOM-RT Struct importer which uses ITK and GDCM 2. I've been testing it on MR and CT volumes of the pelvis (I have also testing it on some head and neck and chest volumes) over the past few weeks.
>>>> I have been planning to write an Insight Journal paper over the past week and will try to do this over the weekend.  I'm happy to send you the code today (as is) if you would like to test/compare it?
>>>>
>>>> Cheers,
>>>> Jason
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Mathieu Malaterre [mailto:mathieu.malaterre at gmail.com]
>>>> Sent: Friday, October 16, 2009 6:13 PM
>>>> To: Mark Roden
>>>> Cc: insight-users at itk.org; Dowling, Jason (ICT Centre, Herston - RBWH); gdcm-developers
>>>> Subject: Re: [Insight-users] Loading DICOM RTStructs
>>>>
>>>> Hi Mark,
>>>>
>>>>  I made a mistake and had a private conversation with Jason Dowling (CC), without CCing gdcm-dev sorry :(
>>>>  He also has been working on a C++ RT Importer using gdcm 2.x. This has been tested on multilpe platform and gives proper results.
>>>>  If you would like we could compare both C++ code and merge them. I know Jason was really close to making a release to the IJ. Jason, any comments ?
>>>>
>>>> cheers
>>>>
>>>> On Fri, Oct 16, 2009 at 1:43 AM, Mark Roden <mmroden at gmail.com> wrote:
>>>>> Hi all,
>>>>>
>>>>> I note that there is now the capability of exporting DICOM RT structs:
>>>>>
>>>>> http://www.insight-journal.org/browse/publication/316
>>>>>
>>>>> However, I can't find any information on how to import these structs.
>>>>> It may just be that my google-fu is weak, so if there is such an
>>>>> example or the like, please let me know.
>>>>>
>>>>> I've written C# code to wrap around gdcm to go into my own image
>>>>> format, so I can use that if I have to, but the conversion would
>>>>> probably be irritating since I'm extremely inexperienced with the itk.
>>>>>  I'd rather follow some sample code.
>>>>>
>>>>> Barring that, should I just post my importer to the development list
>>>>> to get some help on converting it into an itk C++ class?
>>>>>
>>>>> Thanks!
>>>>> Mark
>>>>> _____________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.itk.org/mailman/listinfo/insight-users
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mathieu
>>>>
>>>
>>
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>
>

More information about the Insight-users mailing list