<div>Matthieu,</div>
<div> </div>
<div>I'm not sure if this is relevant to the current discussion.</div>
<div> </div>
<div>I think that PET data often rescales each pixel with a different rescale value. The results should be a floating point value.</div>
<div> </div>
<div>Bill<br><br></div>
<div class="gmail_quote">On Nov 26, 2007 4:44 PM, Mathieu Malaterre <<a href="mailto:mathieu.malaterre@gmail.com">mathieu.malaterre@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Matthias,<br>
<div class="Ih2E3d"><br>On Nov 26, 2007 8:37 PM, Matthias Schabel <<a href="mailto:mschabel@ucair.med.utah.edu">mschabel@ucair.med.utah.edu</a>> wrote:<br>> I may not fully understand this issue, so apologies in advance if I'm
<br>> missing something, but if the support for rescaleSlope/<br>> rescaleIntercept was removed from the ITK GDCM in ITK 3.4, this change<br>> breaks my code in a way that makes it very difficult to fix...<br><br>
</div>Here is what happen in between ITK 3.2 and 3.4, ITK-GDCM was simply<br>passing all DICOM element from the reader to the writer. This is a bad<br>idea since ITK is also at the same time decompressing (applying the<br>
rescale+slope) to the Stored Pixel. Therefore whenever you would<br>read-write-read-write the linear transform would be applied multiple<br>time... yup this is a bug indeed !<br><br>Now, to answer your question: I did not break any kind of backward
<br>compatibility since -and it's been on my TODO list for a while- there<br>is no support for floating point image in ITK-GDCM.<br>So if you are using some kind of low-level script (at gdcm level), you<br>should still be able to use it. Simply completely by-pass any check
<br>done at ITK-GDCM level (ie. do not pass the meta data dictionary from<br>reader to writer).<br>
<div class="Ih2E3d"><br>> In<br>> particular, I have code that performs pharmacokinetic modeling on<br>> dynamically acquired MRI data to generate quantitative maps of<br>> parameters (such as Ktrans, kep, Vp...) that take on floating point
<br>> values in the approximate range of 0.0-2.0.<br><br></div>2.0 ? That's pretty high for Ktrans/kep/ve, isn't it :)<br>
<div class="Ih2E3d"><br>> These maps are then<br>> exported as DICOM, with appropriate rescale factors and offsets to<br>> minimize truncation error in conversion from float to short. Since the<br>> latest release of the ITK libraries appears to strip rescaleSlope and
<br>> rescaleIntercept on DICOM write, I can no longer specify correct<br>> scaling to the visualization program I'm using (OsiriX). I don't<br>> understand the rationale behind this change - it makes it essentially
<br>> impossible to deal with small floating point numbers in DICOM if you<br>> can't specify these scaling values...<br><br></div>Please send your custom script, and I'll help you get it to work again. Thanks.
<br>
<div class="Ih2E3d"><br>><br>> PS The crashing problem in OSX 10.5 appears to only occur with<br>> dynamically linked versions of the ITK libraries - static linkage<br>> works fine.<br><br></div>Great, thanks for the notice !
<br><br>--<br><font color="#888888">Mathieu<br></font>
<div>
<div></div>
<div class="Wj3C7c">_______________________________________________<br>Insight-users mailing list<br><a href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br><a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">
http://www.itk.org/mailman/listinfo/insight-users</a><br></div></div></blockquote></div><br>