[MINC-users] mincconcat problem

[Soren Christensen]

Thanks Andrew!

Cheers
Soren

On 10/26/09, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Soren,
>
> On Fri, Oct 23, 2009 at 21:10, Soren Christensen <sorench at gmail.com> wrote:
>>  I have a problem with mincconcat where I get an unexpected result when
>> first merging, then splitting across time. I do not get back to the
>> starting
>> point in terms of values altough it is close.
>> I originally encountered this as mnc files created by mincconcat (time
>> concat) in some cases differed by integer values of +/-1 relative to the
>> original DICOMs or individual mincfiles prior to running mincconcat.
>>
>> Example:
>> I have two minc files
>> v1.mnc
>> v2.mnc
>> (mincinfo below for all files)
>>
>> I use mincconcat to merge them across time:
>> mincconcat -clobber -concat_dimension time v1.mnc v2.mnc v_concat.mnc
>>
>> ...
>>
>> Is this expected behavior of mincconcat?
>> And if so - is there a way to get around this?
>
> This will depend on the datatype as if your input volumes have
> different ranges there is no way to keep the entire range without a
> bit or range re-scaling and subsequent accuracy loss.
>
> The simple fix is to just do all your processing in float. Once this
> has happened all range scaling is irrelevant.
>
>
> --
> Andrew Janke
> (a.janke at gmail.com || http://a.janke.googlepages.com/)
> Canberra->Australia    +61 (402) 700 883
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www2.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>