<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This is fixed in ITK CVS, thus it should be available in the coming release.<br><br>Thanks again for your bug report,
<br>-M</blockquote><div><br>That's great! <br>About the original pixel range of the xlut_01.dcm test image maybe it's an errata when I told it had a stored pixel range of 128..255 because I extracted that info from the "IHE Year 5 Test Plan for Image Displays" document. The other info is retrieved with the dcmtk library command line tools ( "dcmdump" to be more exactly ). Which tool do you recommend me to extract the original stored pixel range?
<br><br>I also have another question about the Photometric Interpretation. When the image is of type MONOCHROME1 ( higher values are darker, lower values are brighter ) does gdcm reverse the data to be MONOCHROME2 when it's loaded to itk or it does nothing with the Photometric Interpretation?
<br><br>And I ask again, when a modality lut is present ( tag 0x0028,0x3000 ), does gdcm apply it to the image?<br><br>Thanks again for your help!<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
$ cvs ci -m"BUG: The computed component type to store actual pixel<br>values was not working in all cases. Replace it with a solution that<br>computes max/min interval to find out the correct component type"<br>
itkGDCMImageIO.cxx<br>/cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.cxx,v <--<br>itkGDCMImageIO.cxx<br>new revision: 1.115; previous revision: 1.114<br><br></blockquote></div><br>