Search This Blog

Sunday, October 27, 2013

In Dialog ROI  Stats 4D:  added a function to copy TAC to a clipboard in format so it could be easily pasted to Excel without saving to a file.  Also, changed the formatting of  TAC file to include \t to import easily to Excel.

Saturday, October 26, 2013

When dialogs RoiStat3D and RoiStat4D are acivated, the "ROI is empty" error message is displayed,  show the name of the ROI layer.
Added the progress indicator to the FireVoxel document load. This is very helpful when loading very large volumes (such as PET)
Fixed an error writing incorrect datatype in ANALYZE 7.5 format (for 16-bit volume)

Friday, October 25, 2013

Fixed defect: When ROI is saved to DICOM it is incorrectly displayed in Oped DICOM dialog Preview panel.
Fixed several problems when trying to load a single DICOM slice directly from multi-slice DICOM tree.
Fixed  the DICOM-ROI   save and edit problem reported by Alexandra Hotca.

Wednesday, October 23, 2013

Finished the MRTM model.  Fit seems to be better than MRTM0 as in models justification.
Finalizing the #2 MRTM model...
Added a "graphical verification plot" feature to MRTM0 modelling.  Equation is rearranged to the form C(t)=....  So the tissue TAC can be plotted over the model TAC.  In this example dont be discouraged by the mismatch as I drawn an arbitrary "Reference receptor-free Region".

Tuesday, October 22, 2013

Finished the MRTM0 model with virtually identical interface to PMOD.  Tested on a sample "Reference ROI" for providing the Reference Curve.


Monday, October 21, 2013

Integrating Ichise's  MRTM0,MRTM,MRTM2 reference model into FireVoxel dynamic framework.

Sunday, October 20, 2013

Implementing MRTM0, MRTM, MRTM2 reference model within the FireVoxel Dynamic Processing framework.

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.

Friday, October 18, 2013

Eliminated the need for the user to specify the "anchor timepoint" during the PET to Anatomy registration.  Timepoint of Maximum average singnal is selected and the registration is performed to that timepoint
to determine the required transformation for all PET timepoints.
FilmView display:  for large images it is quite slow, with 4.8 sec to display all slices of 344x344x170 volume.
Fully parallelized with the x3.5 speed-up (down to 1.37 sec)
Finalizing integrated PET->MPRAGE workflow to spare the user from a separate Orientation change and Cropping operation.  This is under the MainMenu>Applications>PET>Register to Anatomy.

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.

Wednesday, October 16, 2013

Fully parallelized the "Volume Dynamic Averaging" function with the great speed-up.