<div>Steve,</div>
<div> </div>
<div>You are right, I meant each slice and not each pixel.</div>
<div> </div>
<div>Bill<br><br></div>
<div class="gmail_quote">On Nov 28, 2007 6:08 PM, Steve M. Robbins <<a href="mailto:steve@sumost.ca">steve@sumost.ca</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">On Wed, Nov 28, 2007 at 08:55:15AM +0100, Mathieu Malaterre wrote:<br>> On Nov 28, 2007 4:40 AM, Steve M. Robbins <<a href="mailto:steve@sumost.ca">steve@sumost.ca</a>> wrote:<br>> > On Mon, Nov 26, 2007 at 11:22:25PM +0100, Mathieu Malaterre wrote:
<br>> ><br>> > > To go into further details, PET for instance has a dynamic<br>> > > slope/intersept.<br>> ><br>> > What do you mean by "dynamic slope/intercept"? That the rescale
<br>> > slope and intercept are specified per-image, even when the image<br>> > series forms a volume? That's not limited to PT; CT has the<br>> > same behaviour, doesn't it?<br>><br>> Hum...
<br>> I have never seen this happen with CT images (due to the nature of<br>> Houndsfield Units this is not typical to go beyond 16 bits well at<br>> least for human composition, in which case a single rescale<br>
> slope/intercept should be enough).<br><br></div>True. I asked the question not because I have seen it in practice,<br>but to make sure I understood what you and Bill were talking about.<br>Somewhere in that conversation it was mentioned that PET scales each
<br>*pixel* individually, which made me wonder whether I understood DICOM<br>correctly. (I think the comment about scaling by pixel was an error<br>and scaling by slice was intended.)<br>
<div class="Ih2E3d"><br><br>> Do you have by any chance a sample dataset, or do you recall the<br>> private vendor doing this ?<br><br></div>I don't recall any CT series in which rescale slope and intercept<br>
change.<br><br>However, let me tell you about a series I did come across in the wild.<br>It was MR and it had different *Bits Stored* across the series: a few<br>images had 12 bits, the next few had 13, some more had 14. I have no
<br>idea why they needed to do this, but it did expose a bug in our code.<br>I can't recall for certain, but I don't think this was a volumetric<br>data set.<br><br>The moral of the story is only that a DICOM reader ought to be
<br>prepared for almost anything and verify assumptions (such as "all<br>rescales and slopes are equal") on the actual input.<br><br>Regards,<br><font color="#888888">-Steve<br><br></font><br>-----BEGIN PGP SIGNATURE-----
<br>Version: GnuPG v1.4.6 (GNU/Linux)<br><br>iD8DBQFHTfTZ0i2bPSHbMcURAtuuAJ42jlUrBTcfOLGOv4lkmb/kmJAP+gCgriqX<br>pDDSZWO9O2luqlOUTlG26Qk=<br>=d07T<br>-----END PGP SIGNATURE-----<br><br>_______________________________________________
<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><br></blockquote></div><br>