[Insight-users] update Mevislab dcm-tiff support

[Rashindra Manniesing]

No that was actually not the reason. I decided on purpose not to adjust
for intercept/slope found in the dcm header since that would involve a
type cast of the pixeltype in some cases (eg in CTA data is often stored
as unsigned short).

I think it is safer not to have this behavior as side effect. Although a
type-cast to short for this particular case may seem trivial, I think it
is better to have the user be aware of the pixeltypes and intensity range
and to let him/her decide whether intensity rescaling should be applied.

Btw: although I may be biased in my judgements, in general I must say the
dcm/tiff format proposed by mevis is quite a handy format to use. First,
their choice of using one dcm file (of the vol) as header information is
simply a very smart thing to do, and it uses compression by default.

Having said that, I would appreciate if developers of ITK would find the
time to update the tiff library (really, there are many bugfixes in the
latest version of 3.9.1) and to drop the support of gdcm 1.0 and stick
with 2.0 to make a cleaner/leaner package!

> On Mon, Oct 5, 2009 at 3:30 PM, Rashindra Manniesing
> <r.manniesing at erasmusmc.nl> wrote:
>>
>> If you are using both the ITK and MevisLab environment, you may be
>> interested in the following implementation for ITK of the dcm/tiff image
>> format that is used by MevisLab. The code has been updated using the
>> following libraries (gdcm 2.0.12, libtiff 3.9.1 and itk 3.14.0), and
>> seems
>
> Excellent :)
>
>> to work very well on windows (visual studio) and linux, both 32 and 64
>> bits,
>> and establish a smooth integration between the two environments without
>> unnecessary data conversion. The dcm/tiff format uses compression by
>> default.
>
>
> I did not quite understood the section "RESCALE INTERCEPT and RESCALE
> SLOPE". Did you get it to work ? Or is there still something not quite
> right ?
>
> Thanks,
> --
> Mathieu
>