Re: Medical RP & STL

From: Helisysdon (
Date: Fri Feb 06 1998 - 18:09:34 EET

What is a voxel volume?

-----Original Message-----
From: paul <>
To: RP Mailing List <>
Date: Friday, February 06, 1998 9:42 AM
Subject: Fw: Medical RP & STL

>-----Original Message-----
>From: paul <>
>To: <>
>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
>>With almost all medical imaging 2D slices are generated. Contours can then
>>be produced directly and be interpolated directly to the layer thickness
>>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
>>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
>>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
>>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
>>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 <>
>>To: <>
>>Cc: <>
>>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
>>>> > > 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
>>>> > > 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.
>>>Charles Knox, Vice President Phone: +1 (612) 482-7938
>>>Image3, LLC, Midwest Division FAX: +1 (612) 490-9717
>>>1000 Ingerson Road E-mail:
>>>Shoreview MN 55126-8146 Web:
>>> "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

For more information about the rp-ml, see

This archive was generated by hypermail 2.1.2 : Tue Jun 05 2001 - 22:44:51 EEST