MagTrace on Hippocampus.

First experiment:  To evaluate the quality of snapping, I used the supplied HC Roi as the guidance.  I clicked precisely on the boundary of the HC-ROI and let the software to adjust the position.
Attached screenshot shows the snapped points, without any manual further corrections.
Note: the snapping was performed on x3 upsampled resolution (EMD\Radial\2.2).

MagTrace:  Restart tracing> fixed the Bug when user had polyline selected on a different slice from currently  MagTrace operational slice.

FireVoxel Build 211 is released.

1.  First version and user interface for the MagTrace semi-automatic tracing functionality.

MagTrace tool:  implemented functionality to resume the tracing of the existing Spline
a) Select the desired spline
b) Press MagTrace button.  Operation will resume from the last point.

Magtrace tool:  prevented the "Double entry" error when user presses snap button before the previous snap operation is finished.

MagTrace tool:  fixed crash when the user clicks within the document window, but not on the image.

PolyTool\MagTrace tool:  don't perform any action if the mouse cursor is out of client are.
(affected:  MouseMove and MouseLButtonDown)

MagTrace: implemented various support function for Splines:
a) UpdateRectangle calculation
b) Spline contour hit test.

Implemented the Spline\Polyline rasterization function.
Several contours and\or holes are allowed.
Spline - polygons could be mixed.
Internally this supports 2.5D polygons (i.e. 2D+SliceIndex).

Created new C++:CDrawTool  "Magnetic Trace" and added a corresponding menu item to avoid cluttering the Polygon functionality.

Improved the semi-automatic "Snap-To-Point" function and corresponding UI.
This is mostly due to better matching and usage of Splines.

Initial pass: user quickly clicks on desired location and proceeds WITHOUT correction

On the second, manual pass, user simply drags the control points (about 5-6) in this example and contour adjusts.

Implemented general  Cubic Hermite Splines 2D function.  It supports several types of splines {CARDINAL,FinalDiff,Catmull-ROM}
The challenge was to implement it so it matches exactly the Microsoft's GDI+ implementation in DrawCurve() - this was achieved.

Function can be easily expanded to 3D.

While "Snap-to-Point" feature works quite well on femur, there are areas where local features are not sufficient to reliably detect the desired location

Problematic boundary for "Snap-to-Point"

Typical structure of the edges.  Local structure is not sufficient to reconstruct a good snapping location.

To solve this problem I propose to include additional mechanisms, see figure below.

"Snap-to-point" would simply snap to a stronger edge within the Snap apperture. This would be incorrect. Instead taking the previous state of the cardinal spline into account, we search for a better snap location.  Snap-to Curve would inregrate the edges strength all along the last segment, so the yellow path would be invalidated. And instead more reliable path chosen.

FireVoxel Build 210A is released.

Implemented the functionality to load real valued 4D Analyze files (*.time+ array of .IMG files)

First runs of new MagPoly tool on the femur:

First user performs several clicks on perceived contour of the femur. Computer calculates the edge pattern next to the click and selects a "snapping" location setting an anchor point.
Two important points:

a) Even if snapping did not work properly - operator proceeds with the next points (there will be a cleanup stage later).
b) Work is performed on a full Zoomout, so User does not have to Zoom In and back and scroll!
c) In between the anchor points, a cardinal spline with application-specific tension is used.
d) 10-voxel snapping radius was used.

Each anchor point corresponds to a single click

In the followup stage. User returns and drags some anchors to improve their positions. In this example about 6 anchors were corrected.

After dragging 6 anchors.

MagPoly tool: a simple interface to extend the functionality of the Polygon. It is purely 2D tool. No 3D extension is foreseen at the moment.



Tool is activated with the present Polygon tool. Then behavior changes according to dialog parameters.

|x|  UseMagPoly - turns the tool on.  Off = regular polyline.

"MagPoly radius":  the cursor changes to a semitransparent circle (similar to the paintbrush cursor). Radius specify the snapping seaarch radius - this way user has some feedback how far she should click.

|x|  Precompute slice edges (for slow computers).  - at the moment I plan to compute edges each time user clicks within the apperture specified by the "MagPoly radius".  Hopefully it will fill instantaneous on the mainstream computer.  Otherwise, with the tool on each time the slice would change, the internal edge layer will be computed.

"Edge Parameters" - parameters identical to the Texture Edge detector.


Additional parameters will appear later on.  F.e. more advance version would snap the curve between the user-specified Anchor points.

Implemented "ROI>Concentric Ring profile" function with the result being copied to the clipboard.

Idea is to capture the spatial characteristics of the tumor by detecting Texture-sensitive edges within the tumor at different scales and different apperture weights.

EMD texture edges, Scale=3, Apperture=constant

 Here are the corresponding Edge strength distribution histograms:  They have a widely varying StdDev/Mean and so on.

We can also Build the "Concentric Profiles" of Edge Strength distribution ( in corresponding order)

"Tumor blob analysis"

Tumor is thresholded.

Dark blob info is available

"Tumor ring profile" trials:

Mean=Blue, StdDev=red,  1 vox step -> inwards

Full Resolution Femur sample:
Run the registration Using URAL, default parameters, Subsample=8,with Finetune=1.
Timings:
Primitive generation:   3 min
AutoFocus:                  50 sec
FineTune:                     25 sec

Result is below.  I don't see a need to change anything about the registration FineTune.
MI problem has to be investigated.

Femur Full-resolution registration sample:

URAL registration works well with the present default parameters. Below is the result for the AutoFocus stage (no Finetune)

Using URAL, AutoFocus-only, no Finetune

However, for the MutualInfo this stage fails with the result grossly misplaced.

FGT segmentation: Implemented a hybrid FAT thresholding method based on Z-alg for when histogram has 2 distinct peaks. New criteria was developed for the absence of such peaks. In that case the PVV segmentation is invoked.
Processed all the 16 "challenge" cases with good results.

Developed completely new application-oriented AirThresholding method. It is based on Z-alg idea.
Validating it on the failed breast FGT samples where selecting across-the-board threshold = 60 did not work.  Specifically, in REIC cases the proper thresholds were substantially higher :  {67,108}
in KELL cases the proper threshold were substantially lower {17,15}

REIC_R

KELL_R

KELL_L

REIC_L

Added the {BiGauss_PVV,BiLaplace_PVV} methods to the menu of Histogram segmentation methods in
a) RoiStats3D dialog
b) "ROI>Split ROI with threshold" menu

Improved the performance of the "Interval Arithmetic" library. This is used in all Histogram segmentations and dynamic modelling.

Developed new thresholding methods  "Bi{Gaussian,Laplacian} with PVV correction".
These methods work on the idea that the histogram segment between 2 peaks is unreliable due to the Partial Volume Voxels (PVV) and should be completely disregarded.  Intuition here is how human thresholds complex fused histograms, just by looking on the side tails of the distribution.

Tested on the difficult case ABBE-R. With the good result.

Histogram modelling

Final segmentation

problematic case ABBE-R
seems the BiLaplacian split found a wrong threshold:

ABBE-R.  BiLaplacian split.  Residual = 2549

However, when we re-segment the BiGaussian model, we obtain much lower residual.

BiGaussian fit.  Residual = 645

ABBE-R:   Split using BiGaussian

However, for Phantoms the BiLaplacian was much better than Gaussian at least for most cases and all phantoms were processed using exclusively BiLaplacian.


Proposal:  We evaluate histogram fit using both {BiLaplace,BiGauss}.  We choose the method that provides smaller fitting residual.

Determine the Air threshold in Breat FGT images:
We inspect the histogram that has a gross-dominant peak around the Signal=0. We fine first evident valley and assign the valley bottom to be the AirThreshold.

New workflow on case ABBE_L:

result of the segmentation:

Testing new FGT workflow on human data:
BiCal + BiLaplace provide excellent result. Exactly the parameters  from Phantom processing
were used

BiCal followed by BiLaplace

Breast FGT phantom workflow:  implemented completely new workflow  BiCal+BiLaplace+MaxCC+EdgeWaveML.  Processed all 24 cases with very good result matching the physical measurement.

Some voxels are marked as FGT, but should be they included at all?  They could be fairly easily excluded by demanding that the FGT+FAT is a Connected object and does not consist of the several
disconnected components. This should be true for Phantom and Human data?

"EdgeWave MultiLabel - Boundary Only" variant was implemented.  Only the boundary voxels of the total region are modified by Multilabel Peel\Grow.
Provides slightly different result

FGT=187.8 cm3, FAT = 944, Total = 1131.8, Fgt%=16.5%

Implemented new algorithm "EdgeWave MultiLabel". This is a general algorithm: given an initial segmentation of the region with multiple labels it applies EdgeWave morphological criteria to correct these regions while completely covering the total region.

This was applied to p1s0_L example that had issues with partial volume voxels being misclassified as FGT.

This algorithm contains both internal and external morphological competition.  So additional algorithm "EdgeWave ML Boundary" will be attempted.

FGT: 180.23, FAT=950, total=1130.23,  FGT percentage=15.9%

Implemented the original variant of the FGT breast workflow.  It consists of BiCal, Bimodal Laplace thresholding.  While providing great (+-4% ground truth) result for some images, other images are problematic. This requires to develop an additional Morphological module, as none of the existing variants of EdgeWave don't seem to fit.

This is the "fused peak" case that Henry sent earlier.  As far as I understand this was the case "p4s0.fvx"-RIGHT (DICOM5)

Again BiCal was applied with the exact parameters as with other cases. Then BiLaplacian with exactly same parameters too.  We see a great histogram split as a result.

Initial fused peaks case resolved.

Corresponding segmentation (top and bottom slices)

FGT processing update:

1. Preliminary results on 4 phantoms with about 200 manual seeds each indicate x4-5 times improvement of BiCal over N3.

2. After fixing the BiLaplace fitting procedure, the phantom histogram splits start to look great. But no great conclusions till the whole set is done.  See below (case p1s1_R.fvx)

Histogram fitting using Bimodal Laplacian (after BiCal)

Understanding breast phantom data:
Provided phantom data should be
a) Thresholded to get the Breast ROI (instead of manual ROI in patient data).
b) L&R breast separated
c) Run NU {N3,Bical}
d) Run Histogram thresholding {Otsu,BiGauss,BiLaplace}
e) provide the results of measurement in cm^3
f) best method matching the ground truth will be selected

BiModal histogram segmentation within the RoiStats3D dialog box.

a) Added the separate "Recompute" button to simplify the processing
b) Currently selected\displayed histogram binning is supplied and used as the distribution for the BiModal modelling.
c) Corrected the Model Curve overlay to be consistent with the change in binning specified by the User.
d) Eliminated the "BiGauss model"  only leaving the "BiGauss with Ratio model".  Just set the very high peak ratio (>10) to get result of the previous models.
e) Fitting Thresholds\Residual are now displayed in the "Threshold" status line.

BiGauss model (residual 57.7)

BiLaplacian model (residual 86.6)

Enabled a correct progress meter inside the Breast-FGT "compounding workflow".

Developed an adaptive function to separate breast image into L&R.  This is to compensate for 2 possible operator related errors:  initial acquisition centering and positioning of the cropping ROI.

BiGauss Histogram modelling (on the ventricles image):
Observation is that the "With Ratio" variant executes much faster than "Without Ratio" variant.
But then on this particular sample  the second one seems to have much better result.

Bimodal Gauss WITH Ratio

Bimodal Gauss (without Ratio)

BiGauss Histogram (without ratio) modelling:  Added the progress bar.

Improved Automatic DICOM loading function (does not require user input). Now function may be supplied with the file folder name. Before it required only the image file name of the actual dicom file.

FireVoxel Build 209 is released.

 1. Fixed the "IM file crash problem" (equal sign was missing):  an appropriate error message would be displayed now.

2. IVIM segmented model:

a) added parameter "Large B-value start" with the default value=200.  User can now change that value.

b) Increased the allowed ranges for Dp=[0,1],  Dt=[0,0.01]

IVIM basic model:

 Increased the allowed ranges for Dp=[0,1],  Dt=[0,0.01]

3. On Mouse Move - Display voxel information:  fixed a defect when the Active Layer is disabled, so moving the mouse did not produce any information in the status line.

Now if the Active is disabled, we choose the First enabled layer to display the voxel info.

4. Synchronize Multiprojection Cursor (mode=ON) functionality:  if there is a single View\Projection of the volume is visible the Crosshair cursor would not be visible.

5.  BiCal on Sodium images: fixed the defect when iterations of BiCal were producing a "better" result. This was due to the custom scheme of processing the REAL images, when internally they were converted to the 15 bit images and this was conflicting with the internal truncation