Hello Anna,
sorry for the wait.
On Aug 2, 2013, at 9:08 PM, Hoppe, Anna L wrote:
> Hi Luca (again),
>
> I have another update for you:
>
> 1. Using the script:
> vmtkimagereader -ifile /path/image_001.dcm --pipe vmtkimagewriter
> /path/image001.mha for some reason results in a .mha that is misaligned from
> the original image_001 volume.
You mean from the volume that was read using -f dicom, right?
> So this means that using the following 2 scripts:
> vmtkimagereader -ifile /path/image_001.dcm --pipe vmtklevelsetsegmentation
> --pipe vmtkmarchingcubes -i @.o -ofile /path/test_unaligned.vtp
>
> followed by:
> vmtkimagereader -ifile /path/image_001.dcm --pipe vmtksurfacetransformtoras
> -ifile /path/test_unaligned.vtp -ofile /path/test_aligned.vtp
>
> Actually does result in a surface which is aligned with image_001 volume.
Good, this is how it is supposed to work.
> In other words, if the syntax vmtkimagereader -ifile is used for both the
> segmentation/reconstruction and the transformation back to RAS then
> everything works as it should and the transformed surface aligns with the
> image volume from whence it came (in RAS space of course). Sorry, I know
> this is what you telling me the other day, I was just comparing against the
> wrong thing yesterday.
No worries!
> The light at the end of the tunnel is this: if I re-do my segmentations after
> first reading in the image using vmtkimageviewer -ifile then I'll be able to
> transform the surface back to RAS like I want.
>
> 2.At this point I still don't know how to get the models reconstructed via
> the vmtkimagereader -f dicom -d syntax back to RAS, or the .vti segmentation
> files for that matter. What I was thinking was that if the RAS transform
> matrix for these models simply involved a translation by the origin in xyz
> space, I could just manually manipulate the transformation matrix until I
> found an exact match. I've tried to manually manipulate this matrix using the
> following script:
>
> vmtkimagereader -ifile /path/image_001.dcm --pipe vmtksurfacetransformtoras
> -ifile /path/model_from_vmtkimagereader_dicom_syntax.vtp -matrix 1.0
> -2.0510340648094427e-10 0.0 -90.625 2.0510340648094427e-10 1.0 0.0 -62.9 0.0
> 0.0 1.0 -55.541767 0.0 0.0 0.0 1.0 -ofile /path/model_transformedtoras.vtp
>
> then manually change the -matrix. What I've found from reading online is that
> the matrix is a 4X4 matrix where the fourth value in every row corresponds to
> the an x,y,z translation. So I cut/copied the XyzToRasMatrixCoefficients that
> were the output from vmtkimagereader, then pasted them after -matrix. I
> proceeded to manipulate the fourth matrix value in every row to be either the
> respective origin coordinate or a multiple. I then loaded the image volume
> dicoms into Slicer, made a quickie model, then loaded in
> model_transformedtoras.vtp to see how the 2 compared. What I found is that
> the transformation matrix seems to incorporate the x and z origin values, but
> not the y. In fact to make the 2 models align by eye-balling I used a
> seemingly arbitrarynumber in its place.
>
> My question is: do you know anyway to do this? Or is this why you started off
> by saying there's really no way to back calculate this transformation matrix
> the other day...
What you write about the y value is weird, it shouldn't work this way.
Question: when you load up the two volumes (the -ifile one and the -f dicom
one) using vmtkimageviewer, do you see any of the axes flipped? (by flipped I
mean, like liver on the left vs on the right - I know you're processing brain
images, just using the liver for clarity).
Also, if you look at the i,j,k cursor coordinates while you're clicking on the
image, does the first, second and third coordinate correspond in terms of
spatial directions between the two images?
I'm asking because if the answer is yes, then you should be able to just align
by translation. Otherwise you'll have to flip axes and things could get a bit
trickier.
Feel free to send the two sample images over.
Best,
Luca
> Also, you can feel free to disregard my previous email - I wouldn't want you
> to read 2 very long emails :-)
The questions above should also help for the other message :-)
> Anna
> From: Hoppe, Anna L [anna-ho...@uiowa.edu]
> Sent: Thursday, August 01, 2013 4:47 PM
> To: vmtk-users@lists.sourceforge.net
> Cc: Johnson, Kevin R
> Subject: [vmtk-users] RAS transformation
>
> Hi Luca,
>
> I worked on the xyz to RAS transformation problem. Here are two updates:
>
> 1: I used the 2 different syntax's of vmtkimagereader (vmtkimagereader -ifile
> /path/image_001.dcm --pipe vmtkimagewriter /path/image001.mha and
> vmtkimagereader -f dicom -d /path/ --pipe vmtkimagewriter
> /path/image002.mha). I was able to use vmtkimagereader -f dicom -d /path/
> -flip 1 1 0 --pipe vmtkimagewriter /path/image002.mha to orient the image
> volume correctly relative to the image volume read in using the -ifile syntax.
>
> Here's a photo of the two image volumes in 3D Slicer (note that I just made
> an isosurface model of each in slicer and that's what you're looking at.
> Green is the isosurface corresponding to the image volume read in via -ifile
> and purple is the isosurface of the volume read in by -f dicom -d)
> <ifile_model_dicom_model2.jpeg>
> >From the photo you can see that the two are still displaced, but my
> >suspicion is that the offset is just by the origin coordinates (90.625,
> >137.167068, -55.541767, or some multiple of these). Yet when I try and use
> >vmtkimagereader -f dicom -d /path/ -origin 90.625000 137.167068 -55.541767
> >the image volume is still in the same location it was without using the
> >-origin flag. Does -origin not work when -f dicom -d is used? Is there a
> >way to even align these two image volumes with the flags in vmtkimagereader?
>
>
>
> 2. Just to see if reading in an image volume using vmtkimagereader -ifile
> /path/image_001.dcm, making a model using vmtklevelsetsegmenation and
> vmtkmarchingcubes, and then using vmtksurfacetransformtoras to transform from
> xyz to RAS results in an aligned model & image in RAS space, I tried the
> following 2 scripts:
>
> vmtkimagereader -ifile /path/image_001.dcm --pipe vmtklevelsetsegmentation
> --pipe vmtkmarchingcubes -i @.o -ofile /path/test_unaligned.vtp
>
> followed by:
> vmtkimagereader -ifile /path/image_001.dcm --pipe vmtksurfacetransformtoras
> -ifile /path/test_unaligned.vtp -ofile /path/test_aligned.vtp
>
> The vmtksurfacetransformtoras output (test_aligned.vtp) is shown in gray in
> the following image (recall that the green model is the isosurface
> corresponding to vmtkimagereader -ifile /path/image001.dcm --pipe
> vmtkimagewriter /path/image001.mha):
> <ifile_model_dicom_model3.jpeg>
> So even reading an image volume via -ifile, making a model via vmtk, and then
> running vmtksurfacetransformtoras results in misalignment -seems like this
> should not have happened, am I missing something here?
>
> Thanks for everything - it is appreciated!
> Anna
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk_______________________________________________
> vmtk-users mailing list
> vmtk-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/vmtk-users
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
vmtk-users mailing list
vmtk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vmtk-users
