<div dir="ltr">Hi Bill,<div><br></div><div>Yes, I understand that the files must be correctly ordered before writing the new volume. </div><div><br></div><div>My code is attached, in it I am reordering the DICOM files by position and trigger time and taking only the files that correspond to the heart-volume I have chosen (the original files contain more than one volume of the heart taken at different heartbeats). The ordering is done directly with gdcm::Sorter, since I had problems adding restrictions with itkGDCMSeriesFileNames (seems to be a common issue these days). I am using my system's gdcm-2.3.0.</div>
<div><br></div><div>I also thought that maybe the sorting could be a problem, so I copied only the files that correspond to one heart-volume in another folder and used the example DicomSeriesReadImageWrite2.cxx without modifications on it. The resulting DICOM file has the correct order of slices but still not the correct IPP tag.</div>
<div><br></div><div>Regards,</div><div class="gmail_extra"><div><div dir="ltr"><div>--</div>Mariana<br></div></div>
<br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 4:23 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Sorry, I just re-read your email. Please post the compete, modified example source.<div><br></div><div>I'll try to take a look over the weekend...</div><div><br></div></div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 10:23 AM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I just looked at the example code. How are you running it? This example generates a list of filenames to read. With DICOM, the file names are not necessarily related to any order of the slices. For dicom files, the file names can be completely arbitrary.<div>
<br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 9:50 AM, Mariana Bustamante <span dir="ltr"><<a href="mailto:marianabb@gmail.com" target="_blank">marianabb@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Bill,<div><br></div><div>Yes, I also thought that it might still work on Slicer, but the writer is changing the IPP tag on the new file, so the origin is indeed changed.<br>
<div><br></div><div>I don't see any obvious problems on the example code, it's basically the same code as ImageSeriesReadWrite2.cxx except it uses the classes itkGDCMImageIO and itkGDCMSeriesFileNames to manipulate DICOM files. </div>
<div><br></div><div>If indeed there was a problem, I would guess it's on itkGDCMImageIO, in it, the function Write uses the IPP tag from the output of gdcm::Global::GetInstance() to set the origin of the new file. Could it be that this is thought to work if the input is only one file, but not if it's a series of files?</div>
<div><div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra"><div><div dir="ltr"><div>--</div>Mariana<br></div></div><div><div>
<br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 1:41 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">I should appear in the same position in Slicer I think. perhaps there is a bug in the <span style="font-size:13px;font-family:arial,sans-serif">DicomSeriesReadImageWrite2.</span><span style="font-size:13px;font-family:arial,sans-serif">cxx example.</span><span><font color="#888888"><div>
<span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">Bill</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br>
</span></div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 9, 2013 at 4:00 AM, Mariana Bustamante <span dir="ltr"><<a href="mailto:marianabb@gmail.com" target="_blank">marianabb@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Bill,<div><br></div><div>Thanks for the answer.</div>
<div><br></div><div>Maybe that makes sense when reading the image with ITK, but the problem remains when I write the volume to another file, since ITK modifies the IPP tag of the DICOM file to be the last slice. As a result, if I open this new file with Slicer for example, the new origin is the last slice and the image is in the incorrect position. </div>
<div><br></div><div>Shouldn't ITK use the DICOM standard when writing a DICOM file and use the first slice origin as the IPP?</div><div><br></div><div>Regards,</div><div class="gmail_extra"><div><div dir="ltr"><div>--</div>
Mariana<br></div></div><div><div>
<br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 10:11 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">ITK uses a right handed coordinate system. That is why in this case, the last slice is the origin slice. At last that's what I recall.<br><br></div><div class="gmail_extra"><div><div><br><br>
<div class="gmail_quote">
On Thu, Aug 8, 2013 at 1:10 PM, marianabb <span dir="ltr"><<a href="mailto:marianabb@gmail.com" target="_blank">marianabb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hello,<br>
<br>
I am using ITK-4.3.2 to create a volume from a stack of DICOM single-frame<br>
images of the heart.<br>
<br>
Most of the code is taken from the example DicomSeriesReadImageWrite2.cxx,<br>
and the basics work, but I'm confused about whether the volume origin<br>
produced is correct.<br>
<br>
The volume is composed of 14 slices, with spacing [1.0, 1.0, 8.0], the first<br>
and last slices have the following origins (Image Position Patient, DICOM<br>
tag 0020,0032):<br>
- First slice: 42.021, -174.562, 159.592<br>
- Last slice: -27.608, -102.908, 188.461<br>
<br>
The resulting file created with ITK has the last slice IPP as the image<br>
origin, but if I open the original DICOM files with Slicer or Matlab the<br>
resulting image has the first slice IPP as the origin.<br>
<br>
I thought that maybe ITK was just using the IPP of the last file it read,<br>
but if I read the slices in the opposite order (last slice as first as so<br>
on) the resulting origin is still the same as before.<br>
<br>
I understand also that Slicer and DICOM files use the top-left voxel as the<br>
origin, while ITK uses the bottom-left voxel, but this still doesn't explain<br>
using the last slice IPP.<br>
<br>
Any thoughts on this matter would be of great help.<br>
<br>
Thanks!<br>
--<br>
Mariana<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://itk-insight-users.2283740.n2.nabble.com/is-DICOM-volume-origin-calculation-correct-tp7583709.html" target="_blank">http://itk-insight-users.2283740.n2.nabble.com/is-DICOM-volume-origin-calculation-correct-tp7583709.html</a><br>
Sent from the ITK Insight Users mailing list archive at Nabble.com.<br>
_____________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Kitware offers ITK Training Courses, for more information visit:<br>
<a href="http://www.kitware.com/products/protraining.php" target="_blank">http://www.kitware.com/products/protraining.php</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at:<br>
<a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br>
</blockquote></div><br><br clear="all"><br></div></div><span><font color="#888888">-- <br>Unpaid intern in BillsBasement at noware dot com<br>
</font></span></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Unpaid intern in BillsBasement at noware dot com<br>
</div>
</div></div></blockquote></div><br></div></div></div></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Unpaid intern in BillsBasement at noware dot com<br>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Unpaid intern in BillsBasement at noware dot com<br>
</div>
</div></div></blockquote></div><br></div></div>