[Insight-users] GDCM and ITK

[John Drescher]

On Tue, Mar 31, 2009 at 12:04 PM, Mathieu Malaterre
<mathieu.malaterre at gmail.com> wrote:
> On Tue, Mar 31, 2009 at 5:51 PM, John Drescher <drescherjm at gmail.com> wrote:
>> One more BUG.
>>
>> Some integer values are garbage (unsigned only?) while others are valid.
>
> No some binary fields are encoded as mime64. In previous GDCM 1.x
> implementation VR::US / VR::SS used to be converted on-the-fly to
> ASCII (=human readable) version.
>
Makes total sense to me.

>
>> 0028|0002 Samples per Pixel = AQA=
>> 0028|0004 Photometric Interpretation = MONOCHROME2
>> 0028|0010 Rows = AAI=
>> 0028|0011 Columns = AAI=
>> 0028|0030 Pixel Spacing = 0.703125\0.703125
>> 0028|0100 Bits Allocated = EAA=
>> 0028|0101 Bits Stored = EAA=
>> 0028|0102 High Bit = DwA=
>> 0028|0103 Pixel Representation = AQA=
>> 0028|0120 Pixel Padding Value = MPg=
>> 0028|1050 Window Center = -500
>> 0028|1051 Window Width = 1500
>> 0028|1052 Rescale Intercept =  -1024
>> 0028|1053 Rescale Slope =  1
>> 0028|1054 Rescale Type = HU
>
> Fixed.
>
Thank You. I really appreciate this.
>
> $ cvs ci -m"ENH: Stringify VR::US/VR::SS and other simple binary
> fields. Thanks to John Drescher for report." Code/IO
> Running style check
> Running style check
> Processing itkGDCMImageIO.cxx
>
>
I am updating now.

John