GMM fails in cases where background is zero

[raacampbell]

In acquisition systems where the agar intensity is very low, downsampling and median filtering the preview image produces just zeros in the agar region. The result is that the gmm fails and so the acquisition stops. Things I've noticed:

• I am getting -inf for some reason in the function that does the GMM. If those are there the GMM fails
• It probably helps to downsample less and/or not med filt.
• The autoThresh does not medfilt and downsample so can produce a different threshold.

[raacampbell]

Getting rid of Nans and stopping the code that removes bright pixels from getting too crazy seems to be all that's needed:
9a389ba

We are OK with still downsampling as we did and filtering as we did.

[raacampbell]

However, it remains the case that imaging at 1040 nm on NV produces very low pixel counts in agar and the result is that the threshold estimate is wrong and the algorithm ends up losing tissue. We will need to generate some test data at 1040 nm on NV to figure out parameters more carefully. In the mean time see if increasing the retained data from 0.25 to 0.3 or 0.35 is safe. This could be enough to push NV over the edge and get it working well.

[raacampbell]

Testing with one brain at 1040 nm right now and it does seem happier there with value at 0.35. However we might be seeing failure of the GMM here in tests. So need to check carefully.

• Repeat on both pickaxe and cubie as pickaxe has the data with the low numbers that cubie lacks.
• Disable the fixed seed to confirm stuff.

[raacampbell]

Yet it still makes weird random mistakes like this

Sadly, therefore, it's not trustworthy.

[raacampbell]

OK... It looks like the range of DAQ values on NV remains very low. I don't know why we see this a problem now and not previously, but it obviously isn't going to help. So I need to focus on correcting that first. Should have FPGA free now so I can try switching to that and seeing if that helps. I don't see why it would, but it remains the main difference between NV and BS.

[raacampbell]

I looked at this carefully and two things of note have happened:

1. The AD range of NV was low. It turns out that ScanImage was failing to honour the AD range for the 6124. I have swapped to an FPGA and we have a better range.
2. I suspect we may be seeing some issues with number of microns per pixel. I set up a recording with the new DAQ and when it reached the bulb it started doing weird things. See DD203_FPGA920. It started failing to leave a sufficient border and the threshold went up. It then started to image just one tile.

So go over that recording and also the FG_photo that failed and see what could be happening.

Add to the GMM code a clause to end the recording if the FOV is just one tile in size.

[raacampbell]

The wider DAQ range has not fixed the problem, I don't think. I have two recordings with the NV MaiTai and the new algorithm indeed has more problems than the old one. I possibly is failing in different ways compared what I see at the rig, but it is failing.

[raacampbell]

One way to approach this problem is:

1. Check whether for most acquisitions calculating threshold once at start and using this throughout works well with GMM.
2. Do we start to get lots of problems if we use threshold from just the previous section?

The above is definitely the case with FG_SNL_photo25_chan1 acquired with Mai Tai on NV. So the threshold is too unreliable with the GMM for some reason.

The other issue is that tissue being present at ROI borders is not detected and just doesn't seem to figure in how it works. So it's prone to chopping off tissue.

• Confirm that the GMM version still triggers ROI expansion as does the old version for samples where this should happen.

• What does BT.getThreshold do with the GMM alg? Is it even needed?

• Identify where the following error comes from running FG MaiTai brain via BT in dummy mode. We get the same error when running via autoROI.test.runOnStackStruct. EDIT: it comes from the fact that autoROI.autothresh.wholeImageGMM.removeBrightBlocks generates many NaNs because the image that enters it has infs in the region outside of the brain.

mergeOverlapping has found 8 regions
Warning: Rows of X with missing data will not be used. 
> In gmdistribution.fit (line 29)
  In fitgmdist (line 135)
  In autoROI.autothresh.wholeImageGMM.obtainCleanBackgroundSD>gmmSD (line 88)
  In autoROI.autothresh.wholeImageGMM.obtainCleanBackgroundSD (line 59)
  In autoROI.autoThresh (line 26)
  In autoROI (line 236)
  In BT/getNextROIs (line 122)
  In BT/bake (line 323)
  In BakingTray.gui.acquisition_view/bake_callback (line 52)
  In BakingTray.gui.acquisition_view/buildFigure>@(varargin)obj.bake_callback(varargin{:}) (line 60) 

[raacampbell]

I have a found a huge difference between the FG data and other data. The autoROI dataMask, which should be a rectangle indicating the shape of the brain, is actually brain shaped in the FG data. So regions that are non sample are zeros. This explains a lot...

It's an issue with offsets. The image has lots of negative numbers. In all the other data, the image is substantially more positive and so this doesn't lead to any problems:

tIm = autoROI.getSubImageUsingBoundingBox(im, tBoundingBox,true,minIm); % Pull out just this sub-region
imForThresh = imForThresh + tIm;
dataMask = dataMask + (tIm>0); % <--- problem here

So maybe need to look into why these data have negative number even though the BS amps are heavily offset and no problem occurs ever. Also see if we have a more robust way of doing the above so tIm>0 never needs to be there. Alice's data does the same thing, even though the dynamic range is higher. So this is encouraging. We know what's wrong at last.

FIXED: a3efa7a

[raacampbell]

Alice's sample (NeuroVis_MaiTai/sample_210124_122422/) has too many false positives and gives huge ROIs compared to everything else.

• Figure out why
• Consider if we shouldn't repurpose the original code that finds the number of SDs but use it to drive the number of SDs we extract from the GMM.

OK! The dominant problem is not tThreshSD being wrong. The old alg has it as 6.2 for this sample. If I run the old alg at tThreshSD=5, then it more or less does as before. The real issue is that the tThresh value produced by the new algorithm is all over the place:

That in turn is driven by the SD being all over the place. I need to clean up the SD. Once that's done, all this should work better.

By using a fixed region of agar as the background I demonstrate that the new alg works just fine. So the challenge is choosing this. The problem, therefore, lies in autoROI.autothresh.wholeImageGMM.removeBrightBlocks and whether/how we go about removing pixels associated with the sample.

NOTE: the oscillation I see above is common. Other samples with this algorithm also do this. So we need to work out where it comes from. Might solve the problem then. One option worth checking is whether this is due to have so many negative pixels since the DAQ was altered. <--- WOAH. That's it. I don't know why, but if I ensure AK sample has no negative numbers the new ROI routine works just fine. So:

• Figure out why negative numbers are a problem
• Figure out why the DAQ change has led to these in the first place
  If all numbers are positive we are OK and it works. If all are negative we are not. Also if some are negative. This is with AK data. I don't know why particularly these data are problematic and older data (that also straddle zero) are not. But this is good news because it suggests something trivial is at play.