Dear Anna, I finally get to reply - I took some time off in the meantime. This is a rough explanation of how image orientation in space are handled in vmtk and Slicer. Sorry if I'm stating the obvious for you, I'm being pedantic just to be sure.
Images are typically acquired with an absolute orientation in space. The reference frame for such orientation is determined by the scanner according to the location of a standard anatomical site of the patient (e.g. the chin) and the geometry of the scanner (e.g. the bed). Once the patient has been positioned in the scanner and "landmarked", the technician will define a series to acquire with a specific origin and orientation with respect to the aforementioned reference frame. These data, namely the origin, spacing and direction cosines of each slice in the image volume, are recorded in the DICOM header. An long as an image volume is read with the correct spacing and pixel ordering, the volume will contain the same amount of information for segmentation purposes, so you can disregard origin and directions for some applications, but it's typically quite handy to have a way of preserving the location of the image volume with respect to the patient reference frame. Note that there isn't anything particularly fundamental about this reference frame for most applications, except that it allows you to correctly handle the mutual location of different volumes acquired within the same scanning session (assuming there's not patient repositioning or undesired motion). Anyway, Slicer allows to load volumes in this patient reference frame. The reference system used by Slicer is named RAS (right-anterior-superior), referring to the direction from where coordinates will increase (right to left = low to high, and so on). Slicer which is based on VTK for its visualization pipeline, implements this using a library built on top of VTK, because VTK natively only deals with image volumes that are oriented along X Y Z. vmtk, on the other hand, is currently closer to VTK's bare metal and doesn't have this oriented images layer built on top of it, so its image volumes can only be oriented as X Y Z. This is a limitation that is bound to be lifted in the future, but how we will do it is currently undecided. Lately there has been some support for visualizing arbitrarily oriented volumes easily in VTK, so we might proceed in that direction - the alternative is to build support for oriented images as a layer on top of VTK, similarly to what Slicer does. We'll see. For the time being, vmtk allows to deal with oriented images in the following way: 1. read in an image from a DICOM volume and generate an XYZ volume 2. generate a segmented surface from the volume 3. transform the surface to a RAS coordinate system using vmtksurfacetransformtoras, which takes the orientation of images and applies it to the resulting surface This latter operation *should* bring the surface in the exact same location as Slicer would had it generated the model itself. So, this is more or less the story. Now, in your case, did you apply vmtksurfacetransformtoras to your surface prior to loading it into Slicer? Thanks and best regards Luca On Jul 31, 2012, at 9:57 PM, Hoppe, Anna L wrote: > Hi Luca, > > I certainly understand your need for clarification!! We have been having > quite a long email exchange & I could have been clearer... > > I was using vmtkimagereader -ifile /Image_path/IM000000 to read in one > volumetric dataset, then piping vmtkimagevoiselector, > vmtklevelsetsegmentation and vmtkmarchingcubes together to create the > associated reconstruction. When I do this for my two datasets > (contrast-enhanced vessel scan & bone scan) I get reconstructions which are > aligned - a good thing! My problems before were actually due to using the > .dcm extension incorrectly & reading in an image set that was not from the > same point in time -- these problems have been fixed. My apologies for > bothering you with problems that were on my end! > > However, throughout the process of figuring out what was wrong, I've noticed > that when I load an image set into 3DSlicer and generate the reconstruction > within this program and then simultaneously load the reconstruction generated > from the same data via VMTK using vmtklevelsetsegmentation, ect. the two are > in different spatial locations (I also observe this when I load the two into > tecplot, or view together using VMTK). See the attached .jpg for a photo of > what I mean, the gray vessels were reconstructed via VMTK & the green vessels > via Slicer. I just wondered if you had any insight into why this is > happening (maybe the two programs set the image origin differently?). You > can recommend something for me to read regarding this problem, too, if it's > easier. I wanted to qualitatively compare the two reconstructions & I know > that I can register them, it just seems strange to do this since both are > generated from the same image data. > > Thank you for your help Luca. It is always appreciated! > Anna > > > > From: Luca Antiga [luca.ant...@orobix.com] > Sent: Thursday, July 26, 2012 2:26 AM > To: Hoppe, Anna L > Cc: vmtk-users@lists.sourceforge.net > Subject: Re: [vmtk-users] vmtk spatial location question > > Hi Anna, > it's surely possible that your dicom file doesn't have a .dcm extension, in > which case it should be omitted on the command line. > Can you check the actual name of the file? > > Also, can you please detail the exact steps you are taking? > > Thanks for the input > > > Luca > > > > On Jul 24, 2012, at 8:34 PM, Hoppe, Anna L wrote: > >> Hi Luca, >> >> When I tried using vmtkimagereader -ifile /Image_path/IM000000.dcm I got the >> error "Archetype file /Image_path/IM000000.dcm does not exist". I tried >> copying and pasting the dicom files to several different directories and >> this error still persists. I also tried vmtkimagereader -ifile >> /Image_path/IM000000 (with the .dcm file extension) and I at least don't get >> the error but the resulting models are still mis-aligned. What am I >> overlooking? >> >> Thanks for all the help! >> Anna >> ________________________________________ >> From: Luca Antiga [luca.ant...@orobix.com] >> Sent: Wednesday, July 18, 2012 11:01 AM >> To: Hoppe, Anna L >> Cc: vmtk-users@lists.sourceforge.net >> Subject: Re: [vmtk-users] vmtk spatial location question >> >> Hi Anna, >> yes, please try the -ifile way. It should work. >> Best, >> >> Luca >> >> >> >> On Jul 18, 2012, at 4:26 PM, Hoppe, Anna L wrote: >> >>> >>> Hi Luca, >>> >>> ok. I'm glad to know that vmtk & Slicer rely on the same code for position >>> estimation. >>> >>> To initially segment the image sets I used vmtkimagereader -f dicom -d >>> dicom_directory. Do you think I should try vmtkimagereader -ifile >>> first_dicom_file_in_series.dcm instead? >>> >>> Thanks for all the help! >>> Anna >>> ________________________________________ >>> From: Luca Antiga [luca.ant...@orobix.com] >>> Sent: Wednesday, July 18, 2012 4:44 AM >>> To: Hoppe, Anna L >>> Cc: vmtk-users@lists.sourceforge.net >>> Subject: Re: [vmtk-users] vmtk spatial location question >>> >>> Hi Anna, >>> if Slicer loads the images right, then I'd expect vmtk to do the same since >>> they rely on the same code for estimating positioning and directions. >>> There must be something we're still missing from the picture. >>> >>> Quick question: how did you load the DICOM images initially, when you >>> segmented them? Using vmtkimagereader -f dicom -d your_directory (old way >>> that I should deprecate) or vmtkimagereader -ifile >>> first_dicom_file_in_series.dcm ? >>> >>> Thanks >>> >>> Luca >>> >>> >>> >>> On Jul 16, 2012, at 7:12 PM, Hoppe, Anna L wrote: >>> >>>> Hi Luca, >>>> >>>> I tried out the sequence of vmtk scripts you mentioned (vmtkimagereader >>>> -ifile 0001_0001.dcm --pipe vmtksurfacetransformtoras -ifile >>>> segmented_surface.vtp -ofile transformed_segmented_surface.vtp). The >>>> resulting transformed surfaces were still misaligned. After looking at >>>> the dicom header files for each volumetric dataset, there is a coordinate >>>> position archived under the name "Image position (patient)" that differs >>>> in the two datasets, I think that this may be what you referred to as the >>>> "patient's coordinate space"; however, when I load these same two image >>>> sets in 3DSlicer and generate surface models within this program these >>>> models are aligned perfectly. So, I know that the two image sets share >>>> the same physical coordinate space, it's just that the two only partially >>>> overlap within that same physical space (with the overlapping region being >>>> what I'm interested in). 3DSlicer is apparently using some info. from >>>> each dicom header file in order to generate aligned surfaces, I'm just not >>>> sure what info. (after having parsed the header and taking a look at the >>>> archived data within -- there doesn't seem to be any image location >>>> coordinates other than the "image location (patient)" archive?). So I am >>>> wondering if it's possible, assuming I find out some info. about the >>>> physical coordinate system my datasets share, to pass this info. onto >>>> vmtksurfaceviewer, or would a program like 3DSlicer be my only option for >>>> model generation for now? >>>> >>>> Thanks for your help. It is greatly appreciated. >>>> Anna >>>> ________________________________________ >>>> From: Luca Antiga [luca.ant...@orobix.com] >>>> Sent: Saturday, July 14, 2012 9:03 AM >>>> To: Hoppe, Anna L >>>> Cc: vmtk-users@lists.sourceforge.net >>>> Subject: Re: [vmtk-users] vmtk spatial location question >>>> >>>> Dear Anna, >>>> >>>> vmtk doesn't natively take into account image orientation yet. It has been >>>> in the wishlist for some time now, but it would require quite some work, >>>> hopefully I'll be able to get it done if there's enough interest in it. >>>> >>>> For the time being, you can recover the original orientation by >>>> transforming the segmented surfaces to their respective patient's >>>> coordinate space: >>>> >>>> vmtkimagereader -ifile 0001_0001.dcm --pipe vmtksurfacetransformtoras >>>> -ifile segmented_surface.vtp -ofile transformed_segmented_surface.vtp >>>> >>>> Note that you have to start from your original dicom series in the >>>> vmtkimagereader, since the transform matrix is taken from there. >>>> >>>> You should do this for both surfaces, and they should align at the end >>>> *if* the two patient reference frames where the same (which doesn't depend >>>> on vmtk, of course). >>>> >>>> If they aren't (you can load the images up in, say, Osirix, and check if >>>> the two series overlap), then you'll have to perform image registration >>>> first. >>>> To this end you could use 3DSlicer, it incorporates quite a few >>>> registration algorithms. >>>> >>>> Hope this helps. >>>> >>>> >>>> Luca >>>> >>>> >>>> >>>> >>>> On Jul 12, 2012, at 9:34 PM, Hoppe, Anna L wrote: >>>> >>>>> Hi VMTK users, >>>>> >>>>> I have two volumetric image sets taken at the same time point with >>>>> slightly different patient locations (according to the dicom header >>>>> files). One is a bone scan and the other is a contrast-enhanced vessel >>>>> scan. When loading these two data sets using vmtkimageviewer, vmtk >>>>> assumes that they share the same patient position and therefore share the >>>>> same origin. Consequently when the vessel and bone scans are segmented, >>>>> they are clearly misaligned. Does vmtk assume the same patient position >>>>> when overlaying any two image sets (the sets share the same number of >>>>> pixel rows and columns and number of images (512x512x512); additionally, >>>>> they have the same pixel spacing)? Is there a way to explicitly give >>>>> vmtkimagereader the patient position of each image set, so that the >>>>> corresponding segmentations will be aligned? >>>>> >>>>> Thank you for your help, >>>>> Anna >>>>> ------------------------------------------------------------------------------ >>>>> Live Security Virtual Conference >>>>> Exclusive live event will cover all the ways today's security and >>>>> threat landscape has changed and how IT managers can respond. Discussions >>>>> will include endpoint security, mobile security and the latest in malware >>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>> _______________________________________________ >>>>> vmtk-users mailing list >>>>> vmtk-users@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/vmtk-users >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> vmtk-users mailing list >>>> vmtk-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/vmtk-users >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> vmtk-users mailing list >>> vmtk-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/vmtk-users >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> vmtk-users mailing list >> vmtk-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/vmtk-users > > <Slicer_VMTK_reconstructions.jpg>------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > vmtk-users mailing list > vmtk-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/vmtk-users ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ vmtk-users mailing list vmtk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vmtk-users
