From redoute at cermep.fr  Fri Sep  7 10:05:48 2018
From: redoute at cermep.fr (=?UTF-8?B?SsOpcsO0bWUgUmVkb3V0w6k=?=)
Date: Fri, 7 Sep 2018 16:05:48 +0200
Subject: [MINC-users] dcm2mnc & frames times
Message-ID: <41703ebe-b32d-dd38-64b6-7f87a8128c74@cermep.fr>

Hello all,

we have noticed that frames times for dynamic PET volumes from our 
Siemens PET scanner are strangely extracted during dcm2mnc conversion:

here is an example of the time variable given by mincinfo:

> -0.021253439619000346478
> 29.978746560380997721
> 59.978746560380997721
> 89.97874656037998875
> 119.91498685595000495
> 179.91498685594999074
> 239.91498685594996232
> 299.91498685594996232
> 359.91498685594996232
> 419.91498685594996232
> 479.23494067776994143
> 659.23494067776994143
> 839.23494067776994143
> 1019.2349406777999548
> 1199.2349406778000684
> 1379.2349406778000684
> 1559.2349406778000684
> 1739.2349406778000684
> 1919.2349406778000684
> 2097.8751627063998058
> 2397.8751627063998058
> 2697.8751627063998058
> 2997.8751627063998058
> 3297.8751627063998058
> 3597.8751627063998058
> 3897.8751627063998058
> 4197.8751627064002605
> 4497.8751627064002605
> 4797.8751627064002605
> 5097.8751627064002605

of course we expect integers!

we can try to correct this in our processing scripts, but you can notice 
that for the 10th frame, removing the decimal part leads to an error of 
1 sec ...

> 8th: 299.91498685594996232 => 300 to 360 (60 sec duration)
> 9th: 359.91498685594996232 => 360 to 420
> 10th: 419.91498685594996232 => 420 to *480*
> 11th: 479.23494067776994143 => *479 to 549*

Any ideas?

I can provide a dataset for testing if you need

Thanks

Jerome


-- 
==================================================================
J?r?me Redout?
Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
Responsable imageur TEP-TDM
CERMEP - Imagerie du vivant
59 Bd Pinel. 69677 Bron - FRANCE
tel : 33 (0)4 72 68 86 18 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================


From bert at phalarope.com  Fri Sep  7 10:27:36 2018
From: bert at phalarope.com (Robert D. Vincent)
Date: Fri, 7 Sep 2018 10:27:36 -0400
Subject: [MINC-users] dcm2mnc & frames times
In-Reply-To: <41703ebe-b32d-dd38-64b6-7f87a8128c74@cermep.fr>
References: <41703ebe-b32d-dd38-64b6-7f87a8128c74@cermep.fr>
Message-ID: <CAAd5DeTdqdmeha+jeDxi23mPD8VTgcc9UtHmKaeGb2po_D=YGA@mail.gmail.com>

Hi  J?r?me,

It could well be that these are the numbers recorded in the DICOM files - I
should probably take a look at the series. If you send me a link I'll try
to check it.

    -bert

On Fri, Sep 7, 2018 at 10:08 AM J?r?me Redout? <redoute at cermep.fr> wrote:

> Hello all,
>
> we have noticed that frames times for dynamic PET volumes from our
> Siemens PET scanner are strangely extracted during dcm2mnc conversion:
>
> here is an example of the time variable given by mincinfo:
>
> > -0.021253439619000346478
> > 29.978746560380997721
> > 59.978746560380997721
> > 89.97874656037998875
> > 119.91498685595000495
> > 179.91498685594999074
> > 239.91498685594996232
> > 299.91498685594996232
> > 359.91498685594996232
> > 419.91498685594996232
> > 479.23494067776994143
> > 659.23494067776994143
> > 839.23494067776994143
> > 1019.2349406777999548
> > 1199.2349406778000684
> > 1379.2349406778000684
> > 1559.2349406778000684
> > 1739.2349406778000684
> > 1919.2349406778000684
> > 2097.8751627063998058
> > 2397.8751627063998058
> > 2697.8751627063998058
> > 2997.8751627063998058
> > 3297.8751627063998058
> > 3597.8751627063998058
> > 3897.8751627063998058
> > 4197.8751627064002605
> > 4497.8751627064002605
> > 4797.8751627064002605
> > 5097.8751627064002605
>
> of course we expect integers!
>
> we can try to correct this in our processing scripts, but you can notice
> that for the 10th frame, removing the decimal part leads to an error of
> 1 sec ...
>
> > 8th: 299.91498685594996232 => 300 to 360 (60 sec duration)
> > 9th: 359.91498685594996232 => 360 to 420
> > 10th: 419.91498685594996232 => 420 to *480*
> > 11th: 479.23494067776994143 => *479 to 549*
>
> Any ideas?
>
> I can provide a dataset for testing if you need
>
> Thanks
>
> Jerome
>
>
> --
> ==================================================================
> J?r?me Redout?
> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
> Responsable imageur TEP-TDM
> CERMEP - Imagerie du vivant
> 59 Bd Pinel. 69677 Bron - FRANCE
> tel : 33 (0)4 72 68 86 18 (bureau)
> tel : 33 (0)4 72 68 86 00 (standard)
> fax : 33 (0)4 72 68 86 10
> ==================================================================
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From nick.wang at sickkids.ca  Sat Sep 29 12:20:35 2018
From: nick.wang at sickkids.ca (Nick Wang)
Date: Sat, 29 Sep 2018 16:20:35 +0000
Subject: [MINC-users] Resampling a minc volume while conserving intensity
Message-ID: <YTXPR0101MB12142AA237C870032230AD1BEFED0@YTXPR0101MB1214.CANPRD01.PROD.OUTLOOK.COM>

Hello everyone,


In a registration pipeline, I have a minc volume where each voxel's intensity represents the number of cells in that voxel in physical space. I would like to resample this minc volume nonlinearly to align with an atlas. Mincresample's trilinear resampling does not conserve these counts (intensities) properly. Imagine having a adjacent voxels of intensities 10, 10 and 1 being transformed really close to each other, then I may have a result like 5.5, 5.5, and 5.5


As a rough workaround, I tried multiplying the minc volume by the determinant of the inverse of the transform (as one does with triple integrals), but I believe the discrete nature of minc volumes causes error as well. Imagine having a voxel of intensity 10 being shrunk by a factor of 4, but stays exactly in place. I believe this method would cause the transformed voxel to have an intensity of 40 in the outcome. Even if my reasoning here is wrong, this seems like much of a bandaid solution.


Does anyone have any ideas or have any experience with this? Essentially, I am looking for a resampler that conserves the "local" sums of intensity - local enough such that if I take the sum of the intensities of some small region of voxels in the original minc volume, I should get the same sum as the intensities of the corersponding voxels in the transformed volume.


Thanks,

Nick

________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

From vladimir.fonov at gmail.com  Sat Sep 29 13:22:15 2018
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Sat, 29 Sep 2018 13:22:15 -0400
Subject: [MINC-users] Resampling a minc volume while conserving intensity
In-Reply-To: <YTXPR0101MB12142AA237C870032230AD1BEFED0@YTXPR0101MB1214.CANPRD01.PROD.OUTLOOK.COM>
References: <YTXPR0101MB12142AA237C870032230AD1BEFED0@YTXPR0101MB1214.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <8AA4B0D6-2152-458C-97F4-B1D58262C764@gmail.com>

you need a mass preserving transformation, where the total sum over all voxels of interest stays constant. I would convert counts in the input volume to the density (i.e divide counts by the volume of each voxel). Then resample to the target volume, and finally, multiply by the jacobin determinant of the inverse transformation calculated in the target space (if your transformation is linear, it is equivalent of deviding by the jacobian of the transformation matrix from source space to target space). And finally - multiply densities by the volume of voxel in the target space to convert from densities to counts. 


> On Sep 29, 2018, at 12:20, Nick Wang <nick.wang at sickkids.ca> wrote:
> 
> Hello everyone,
> 
> 
> In a registration pipeline, I have a minc volume where each voxel's intensity represents the number of cells in that voxel in physical space. I would like to resample this minc volume nonlinearly to align with an atlas. Mincresample's trilinear resampling does not conserve these counts (intensities) properly. Imagine having a adjacent voxels of intensities 10, 10 and 1 being transformed really close to each other, then I may have a result like 5.5, 5.5, and 5.5
> 
> 
> As a rough workaround, I tried multiplying the minc volume by the determinant of the inverse of the transform (as one does with triple integrals), but I believe the discrete nature of minc volumes causes error as well. Imagine having a voxel of intensity 10 being shrunk by a factor of 4, but stays exactly in place. I believe this method would cause the transformed voxel to have an intensity of 40 in the outcome. Even if my reasoning here is wrong, this seems like much of a bandaid solution.
> 
> 
> Does anyone have any ideas or have any experience with this? Essentially, I am looking for a resampler that conserves the "local" sums of intensity - local enough such that if I take the sum of the intensities of some small region of voxels in the original minc volume, I should get the same sum as the intensities of the corersponding voxels in the transformed volume.
> 
> 
> Thanks,
> 
> Nick
> 
> ________________________________
> 
> This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

Best regards, Vladimir S. FONOV ~ v.s.fonov <at> ilmarin.info