Search This Blog
Sunday, October 27, 2013
Saturday, October 26, 2013
Friday, October 25, 2013
Wednesday, October 23, 2013
Tuesday, October 22, 2013
Monday, October 21, 2013
Sunday, October 20, 2013
Saturday, October 19, 2013
Fully finished the PET->Anatomy registration workflow with full integrated User Interface. In this experiment a 344x344x128 volume with 203 timepoints (original DICOM is 5.83 GB).
It was registered to the MPRAGE with 256x256x160.
Two registration modes were used:
Quick (Nearest neighbor final result), total time 79 sec, combined registered (PET+MRI) file = 496 MB.
Regular (Linear interpolation), total time 217 seconds, combined registered (PET+MRI) file = 653 MB.
It was registered to the MPRAGE with 256x256x160.
Two registration modes were used:
Quick (Nearest neighbor final result), total time 79 sec, combined registered (PET+MRI) file = 496 MB.
Regular (Linear interpolation), total time 217 seconds, combined registered (PET+MRI) file = 653 MB.
Friday, October 18, 2013
Thursday, October 17, 2013
This was investigated and postponed due to a very large changes required:
Major design improvement : Multiresolution Multilayer volmetric entities.
Since the beginning of FireVoxel, only volumes of the same voxel count and size are allowed to be combined in the Multilayerr volumetric entities.
New design relaxes this requirement, by demanding ONLY the physical dimensions of the layers to match so they can be combined into Multilayer volumetric entities.
Motivation: one of the important issues is the presentation of the Registration results. In 4D PET to MPRAGE registration, we desire to keep the dimensions of the MPRAGE intact. But reformatting 220-timepoint PET volume to MPRAGE dimensions leads to multi-GByte volumes. Solution is to keep registration results at the resolution close to original, while able to overlay it over the higher resolution target.
There are other applications of this. If I am not mistaken, we were considering registering the prostate DCE exam to biopsy that have a much higher resolution. It is a similar problem with the size of the registered source.
In short, we want to be able overlay registration result without the explosive and redundant data increase.
It is approached pragmatically, i.e. only currently used workflows would be modified and verified. We will adjust other multilayer functionality as we go. The biggest task and modification of the UI that I foresee is the Vector ROI issues, its dialog etc.
Subscribe to:
Posts (Atom)



