[vtkusers] VTK mesh to Dicom (PACS)
Dov Grobgeld
dov.grobgeld at gmail.com
Tue Dec 29 14:28:20 EST 2015
The open source gdcm library is easy to use, either from C++ or from
python.
For a C++ example see:
http://gdcm.sourceforge.net/html/GenFakeImage_8cxx-example.html
For python there is also the pydicom library:
https://pypi.python.org/pypi/pydicom/
All of these make it easy to generate dicom files with arbitrary tags. What
is not always clear is what is the minimum set of tags that you need to
provide. But that may be solved by reading a template image and then
modifying all the relevant tags.
vtk also supposedly comes with a dicom writer, but I have no experience
with it.
Regards,
Dov
On Tue, Dec 29, 2015 at 6:31 PM, Sebastian Hilbert <
sebastian.hilbert at gmx.net> wrote:
> Hi,
>
>
>
> Am Tuesday 29 December 2015, 17:52:48 schrieb Dov Grobgeld:
>
> > As long as your PACS doesn't interfer with the contents of your private
>
> > tags, you can probably store whatever you want in it. If the private tags
>
> > are limited in size, than you could create a hack that and save a binary
>
> > blob representing the mesh in the image portion of the data and somehow
>
> > encode this hack in other dicom tags. As long as only your software is
>
> > accessing the dicom "images" you should be ok. But if some other
>
> > application would try to show the images they would display garbage. In
>
> > short, as long as you have someway of storing binary data, you can use
> it.
>
> >
>
>
>
> Here is the relevant excerpt from the spec
>
>
>
>
>
>
>
> What would be the most suitable tool to craft such a Dicom file ?
>
>
>
> The other software's spec states this
>
>
>
> V8 3D IO instances are stand alone DICOM entities implemented as
> Extension1 to the SC Image IOD as defined in PS 3.3 – 2004 Page 104, Table
> A.8.1.3 - Secondary Capture Image Storage SOP Class
> 1.2.840.10008.5.1.4.1.1.7.
>
> Table 3.1 defines the modules to be included in V8 3D IO’s.
>
> The 3D Instance Module is the extension to the standard SC Image IOD. It
> is detailed in # 3.2 and # 4. All other modules in Table 3.1 are standard
> DICOM modules.
>
>
>
> Can anyone comment on this ?
>
>
>
> Regards,
>
> Sebastian
>
>
>
>
>
> > Regards,
>
> > Dov
>
> >
>
> >
>
> > On Tue, Dec 29, 2015 at 3:30 PM, Sebastian Hilbert <
>
> >
>
> > sebastian.hilbert at gmx.net> wrote:
>
> > > Hi all,
>
> > >
>
> > > I was wondering if anyone could point me into the right direction.
>
> > >
>
> > > Background: We are working with MR data of the heart and are rendering/
>
> > > segmenting regions of interest to models (e.g. left atrium). Those are
>
> > > then
>
> > > exported to STL by a software called Philips Intellispace Portal and
>
> > > subsequently converted to VTK. Those meshes/models are then used in
>
> > > clinical
>
> > > routine.
>
> > >
>
> > > Goal: What we would like to achieve somehow is to store these VTK
> meshes
>
> > > in a
>
> > > PACS for data exchange. From what I have understood so far it is not
>
> > > possible
>
> > > to store VTK meshes in a PACS. What would you suggest ? Is this
> something
>
> > > that
>
> > > can be implemented ?
>
> > >
>
> > > There seems to be some related bits in the Dicom specification but I am
>
> > > stuck
>
> > > here.
>
> > >
>
> > > ftp://medical.nema.org/medical/dicom/final/sup132_ft.pdf
>
> > >
>
> > >
>
> > > My research also led me to two solutions by medical device vendors who
>
> > > seem to
>
> > > have implemented a way to store their model formats in Dicom file(s).
> One
>
> > > solution Ensite NavX by St. Jude Medical seems to store the XML (VTK
> ascii
>
> > > like) content in a private tag and the other company seems to store
> (VTK
>
> > > binary ?) data in private tags as well.
>
> > >
>
> > > I do have sample Dicom files from both products as well as the file
> format
>
> > > specifications for both products.
>
> > >
>
> > > I wonder what it would take to come up with a solution based on the
> specs
>
> > > and
>
> > > the sample files. If anyone could point me into the right direction
> that
>
> > > would
>
> > > be great.
>
> > >
>
> > > Regards,
>
> > > Sebastian
>
> > > _______________________________________________
>
> > > 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 VTK FAQ at:
>
> > > http://www.vtk.org/Wiki/VTK_FAQ
>
> > >
>
> > > Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> > >
>
> > > Follow this link to subscribe/unsubscribe:
>
> > > http://public.kitware.com/mailman/listinfo/vtkusers
>
>
>
> _______________________________________________
> 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 VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20151229/e693602b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bild1
Type: image/png
Size: 45466 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20151229/e693602b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bild
Type: image/png
Size: 23653 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20151229/e693602b/attachment-0001.png>
More information about the vtkusers
mailing list