[Insight-users] Urgent: Strange dicom imageIO

[Markus Weigert]

Hi Jim,

thanks for this detailed explanation.
I fixed the problem by setting the rescale slope to 0 before writing 
(not to -1024).
At least with CT data, it works now and the data will always be 
displayed properly (I hope).
First, I also thougt about using the rescaleIntensity filter and scaling 
from 0 - 4096
and using the default slope, but I didn't like the imagination, to write 
some shifted values to disk
and then to recalculate while reading it back in (I prefer to write the 
"real" values and set the intensity shift
for all readers to 0).

Regards,
Markus



Miller, James V (GE, Research) schrieb:

>Markus,
>
>This is the difficulty in working with DICOM in a generic fashion.
>
>When ITK reads a DICOM file/series, it applies the slope/intersept to the
>data to so that the intensity values appear to ITK filters in the units
>of the scanner (HU for CT, counts for PET, etc.).  This allows you to 
>operate on the data in the proper units.  This is particularly important
>for PET images since the each slice in a series usually have a different
>slope value.  In the PET case, the slope HAS to be applied to get the
>data from all the slices to be in the same units.  This is all easy to
>do when reading DICOM.
>
>When writing DICOM, ITK does not undo this mapping.  This is the problem
>that you are seeing.  We have been struggling on how to address this issue.
>If the slope/intersept are specified in the meta data, we put these values
>into the DICOM header.  But we do not unapply this pixel transform. So if 
>you read this data back in, it essentially has had the slope/intersept applied
>twice!
>
>At issue is that the writer doesn't know whether these offsets/scales have
>already been applied to the data and the writer just needs to put these
>values in the header or whether these offsets/scales need to be applied
>by the writer AND the values need to be placed in the header.  We need
>to work on this.
>
>A workaround is place a ShiftScaleImageFilter before the writer to apply
>the pixel manipulation.  This way the writer is provided with data that
>has already been transformed to how it would appear on disk.
>
>Of course, when we fix this issue, your shift/scale calculation will have
>to be removed to avoid applying it twice.
>
>In summary, DICOM is more difficult to produce than the other formats
>that ITK supports.  In particular, the application needs to understand
>DICOM tags and meta data dictionary in order to produce DICOM.  One of the
>things we want to do is make ITK generate DICOM more reliably.  This includes
>identifying the subset of tags that have to be present in order to import
>the data into commerical DICOM compliant applications.
>
>Jim
>
>
>
>
>-----Original Message-----
>From: insight-users-bounces+millerjv=crd.ge.com at itk.org
>[mailto:insight-users-bounces+millerjv=crd.ge.com at itk.org]On Behalf Of
>Markus Weigert
>Sent: Wednesday, May 10, 2006 5:33 PM
>To: insight-users at itk.org
>Subject: [Insight-users] Urgent: Strange dicom imageIO
>
>
>Hi,
>
>today I encountered a strange  problem with dicom ImageIO:
>
>After reading a dicom series of  CT - files and displaying the volume with
>GLTwoImageSliceView (from insight applications), everything is fine.
>The range of the values is -1024 up to 3071, just as it should be.
>
>But after writing the serie again to dicom slices and reading these slices,
>the range is now -2048 to 2047, so there seems to be a shift.
>I don't understand this, because I didn't change anything in the 
>MetaDataDictionaryArray.
>
>Has anybody an idea what could cause this shifting of image values?
>
>Regards,
>Markus
>
>_______________________________________________
>Insight-users mailing list
>Insight-users at itk.org
>http://www.itk.org/mailman/listinfo/insight-users
>
>  
>