No subject

you will need a mechanism to convert your ITK mesh to a set of
contours. Unfortunately, I don't think such an algorithm exists in ITK
(yet), so you will have to write one yourself. It's not too difficult
given a starting mesh:
    // Find intersecting points
    foreach plane intersecting mesh
        foreach edge in mesh
            determine if plane intersects edge, record intersection
        end
    end
    // Order intersection points into closed contour
   get random starting face with intersection
    while more intersections
        for current face, add intersection to contour
        current face = adjacent face sharing same intersection as
current face
    end

On a side note, DICOM is about to be extended to support meshes proper
via the "Surface Segmentation" module:
    ftp://medical.nema.org/medical/dicom/supps/sup132_lb.pdf
If you really need to use RTSTRUCTs right now, too bad. Otherwise the
surface segmentation module seems much more flexible...

HTH

Regards, Dan

> On Wed, Jul 2, 2008 at 12:03 PM, Mathieu Malaterre
> <mathieu.malaterre at gmail.com> wrote:
>>
>> Subrahmanyam,
>>
>> On Wed, Jul 2, 2008 at 11:30 AM, Subrahmanyam Gorthi
>> <subrahmanyam.gorthi at gmail.com> wrote:
>> > Dear Mathieu,
>> >
>> > Many THANKS for your detailed & prompt reply.
>> >
>> > Here is what I am actually trying to implement in ITK:
>> >
>> > Using a segmentation algorithm in ITK, I obtained the coordinates for
>> > 3-D
>> > ROI of a patient's image .
>> > I am now trying to export these results into a "DICOM-RT Structure-Set"
>> > file, for RT-Planning in IMRT.
>>
>> *Very* cool ! Is this integrated with any of the Mesh and/or the Meta
>> Object in ITK too ?
>>
>> > In addition to ROI module, as the DICOM-RT structure-set file has to
>> > contain
>> > other
>> > mandatory modules like patient-module, study module etc.,
>> > I am trying to selectively copy those modules from the associated
>> > patient's
>> > 3-D CT image.
>>
>> Ah, I see why the UID can remains the same here. You did not modify the
>> image :)
>>
>> > I compared the tags of structure-set file that I am creating in ITK with
>> > the  file generated by another software that
>> > a Physician here is using in his hospital;
>> > he was manually drawing the contours on the CT image and the
>> > corresponding
>> > DICOM-RT structure-set file is generated by the software.
>>
>> ok
>>
>> > I observed that for the "structure-set" file generated by that software,
>> > "study-instance UID" tag is same as that of the
>> > other 3-D CT DICOM images and hence, I am trying to do the same for the
>> > file
>> > created through ITK.
>>
>> Yup, in this very special case, then you are even encouraged to keep
>> the same UID :)
>>
>> > From your reply, I understand the importance safety issues in  changing
>> > the
>> > default behavior.
>> > I would like to know:
>> > 1. Is it possible to change the default behavior for ONLY selected UIDs
>> > that
>> > are specified by the user?, and how?
>>
>> I am not sure I understand that. but I guess you can do the in your
>> code (application level):
>>
>>  if( currentuid match [set of known uids] )
>>    GDCMImageIO->KeepOriginalUIDOn ()
>>
>> > 2. I want to finally contribute this code to ITK.
>>
>> Even better !
>>
>> > It would be very happy to know and most probably, implement any better
>> > ways
>> > or modifications to the current approach.
>> > Your suggestions in this regard will be of great help to me.
>>
>> IMHO ITK is clearly lacking support for RTSTRUCT object, so any kind
>> of contribution would be AFAIK very welcome. For instance in a newer
>> release of GDCM, we have now integrated RTSTRUCT object nicely in VTK:
>>
>> See:
>>  http://gdcm.sourceforge.net/html/classvtkGDCMPolyDataReader.html
>>
>> Thus RTSTRUCT now appears as a set of vtkPolyData which is the base
>> object for 2D unstructred data in VTK.
>> I would think that a similar approach can (should?) be taken for ITK.
>> You would need to implement a itk::somethingIO that will read RTSTRUCT
>> and then convert it to either a itk::Mesh/itkQEMesh or SpatialObject
>> and convert back to file. This would be IMHO the most flexible for
>> people.
>>
>> And thus you pipeline would become:
>>
>> 1. GDCMImageIO read (filename)
>> 2. Segmentation
>> 3. RTSTRUCT_IO write ouput_filename
>>
>> does this make sense ?
>>
>> Regards,
>> --
>> Mathieu
>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>
>