[MINC-users] mincconcat problem

[Andrew Janke]

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