-----Original Message-----
From: paul <biomodeller@email.msn.com>
To: medicalRP@qmi.asn.au <medicalRP@qmi.asn.au>
Date: Friday, February 06, 1998 11:05 PM
Subject: Fw: Medical RP & STL
>Dear Charles,
>
>I tend to agree with Ulli.
>
>The history of STL is derived from the use of the marching cubes algorithm
>devised by Harvey and Kline (from GE) for the surface rendering of 3D
>images. It was used oportunistically as an interface to RP by Mancovich &
>KONTRON in 1991 (although Ulli may have used it earlier-please correct me).
>
>With almost all medical imaging 2D slices are generated. Contours can then
>be produced directly and be interpolated directly to the layer thickness of
>the RP machine eliminating the stair 'stepping effect' with minimal
>computations and file size. This approach was first developed by Mancovich
>and eloquently refined by Swaelens to form the basis of Materialise
>software. Unfortunately though this approach does not allow object rotation
>and advanced image processing which is desirable in state of the art
>biomodelling. However ANATOMICS patent pending BioBuild (TM) software has
>now solved this for biomodelling applications!
>
>STL on the other hand requires the formation of a voxel volume and then the
>surface meshing by polygons. This STL file then has to be resliced to
>generate contours for RP. The first problem is that the STL files are
>extremely large for the RP software to efficently handle and support. Thus
>resolution must be sacrificed. The second problem is that the STL file is
>already an approximation of the original data that must be further
>approximated to decimate the polygons and then approximated again to reform
>contour slices. Logic would clearly indicate that it is easier to go
>directly from image slice to RP contours!
>
>Validation by comparitive studies of STL versus slice processing to
>manufacture biomodels by ANATOMICS clearly indicated that slices were more
>accurate, faster and robust than STL.
>
>We are seeking however to trial further validation on this issue and on the
>issue of biomodel utility through the Intelligent Manufacturing Systems
>International (IMS) Biomodelling trial and welcome input.
>
>Dr Paul D'Urso
>International IMS Co-ordinator
>
>-----Original Message-----
>From: Charles Knox <scivis@mndata.com>
>To: Ulrich.Kliegis@kiel.netsurf.de <Ulrich.Kliegis@kiel.netsurf.de>
>Cc: medicalRP@qmi.asn.au <medicalRP@qmi.asn.au>
>Date: Friday, February 06, 1998 2:15 AM
>Subject: Re: Medical RP & STL
>
>
>>Ulrich G. Kliegis wrote:
>>>
>>>
>>> > Farid TAHA wrote:
>>> > >
>>> > >
>>> > > First of all you lost some "geometrical" precision when you build
the
>>> > > STL file (converting to triangles 3D complex anatomical surfaces )
>>> > > that means that you lost "anatomical" precision.
>>> > >
>>> > > When the STL file is ready you necessary needs to convert this file
>to
>>> > > SLC or CLI files which are "layer" based files that means that you
>>> > > already lost anatomical informations.
>>> >
>>> > Charles Knox wrote:
>>> > Not true. Think of the surface triangles as simply connecting your
>>> > slice contours. A triangle mesh will also let one calculate, by
>>> > interpolation, an unambiguous set of contours at spacings different
>>> > from that of the original data.
>>> >
>>> Basically correct, although this way you have to transport each point
>>> on the contour in the mean (theoretically, at least) six times as
>>> often as you would have to as a point on a contour alone (assuming
>>> the same spatial resolution in the contour that results from the
>>> segmentation of each CT slice). This is pretty congruent with actual
>>> file sizes: STL files (binary) are about 5 to 7 times as large as
>>> their contour based brothers, at least in the cases I prepared so far
>>> in both domains. There are more elegant ways to come to interpolated
>>> contours than tracing triangle surfaces, though.
>>>
>>
>>Hi Dr. Kliegis,
>>
>>Of course, what you say is "basically correct" if you're talking about
>>the STL representation where triangle edges are retraced twice. But,
>>with all respect, your comments are not really addressed to Dr. Taha's
>>concerns which were that a surface representation is less accurate than
>>"layer" data. My point was that it is not, and in fact, from a
>>computational view, to be preferred. Contour data will at some point
>>almost always have to be reinterpolated for the RP machine, due to
>>reorientation of the part or because layer spacing on the machine is
>>different from that of the original data.
>>
>>[snip ..]
>>> > An STL file is simply yet another surface boundary description, one
>>> > that is still better than slice contours as it maintains surface
>>> > connectivity.
>>> This can NOT be said of most solutions, i.e., that an STL file
>>> maintains surface connectivity or anatomical connectedness rather or
>>> better than a contour based data set. It depends mostly on the
>>> measure of intelligence invested in the reconstruction algorithm, and
>>> there is yet a vast field of unexplored ideas to be worked on. - And,
>>> moreover, it depends on the quality of the scans, slice thickness,
>>> distance, scanner resolution, SNR, the applied convolution kernel,
>>> acceleration voltage, applied dose, patient movement,
>>> identificability of anatomical structures in a diseased environment,
>>> and so forth. A small miracle that it works at all.
>>
>>We're well aware of the pitfalls involved in medical imaging. If you'd
>>like I could send you reprints of several papers we at Image3 have
>>authored on the subject.
>>
>>I think, however, that we would all agree that the goal of 3D
>>reconstruction is to arrive at a characterization of a solid object
>>based on discrete sampling by whatever means. A surface is one step
>>removed from the discretized data, a voxel representation further
>>removed. Combining data from different modalities - CT, MR, PET, etc. -
>>can further refine that characterization. The thing is, however, each
>>such representation embodies information about the earlier, i.e. the
>>bounding surface of a set of slice contours is your best estimate of
>>contour connectivity. It seems counterproductive to me to have to fall
>>back on contours when I've already solved the problem of how they are
>>connected by surfaces.
>>--
>>Regards,
>>
>>Charles Knox, Vice President Phone: +1 (612) 482-7938
>>Image3, LLC, Midwest Division FAX: +1 (612) 490-9717
>>1000 Ingerson Road E-mail: scivis@mndata.com
>>Shoreview MN 55126-8146 Web: http://www.image3.com
>>
>> "If people don't want to come out to the ball park,
>> nobody's going to stop them." -- YOGI BERRA
>>
>
>
For more information about the rp-ml, see http://ltk.hut.fi/rp-ml/
This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:44:51 EEST