Help with ImageThreshold to avoid empty planes in a stack?
I am running ImageThreshold with the adaptive method.
ImageThreshold/P=(plane)/M=3/Q simage
The simage can be an image stack. I am running into cases where I get this error message:
error: Method 3 is not supported for this operation.
I have narrowed this down to the fact that simage contains layers that are entirely ZERO and I am setting /P=(-1) (all planes). No other method fails with an error for such a case even with /P=(-1) (however I now also understand why I am getting nonsense in my thresholding results for those other cases).
I want to do a work-around for the case that some layers in a stack may contain all ZEROs (or all ... whatever values) yet still allow /P=(-1). What is the best method? What is the best value to fill a stack layer so that it is ignored in the ImageThreshold calculations when /P=(-1)? What test should I do on the image stack before the adaptive method (or indeed for all other methods) that would assure that I can either a) report an error message before the operation or b) re-format the image stack (ZERO planes) appropriately to be ignored?
Further Background
This is part of a sequence of processing steps. The first step is to remove the background. This first step can be done on a layer-by-layer basis. To preserve the stack integrity, when I subtract the background from just one layer, I fill all other layers with ZEROs in the newly created image stack. That way, I can step through the "background" stack to see which layers have yet to be adjusted. Or I can just reprocess a specific plane in the stack and substitute it into the stack.
I tried NaN as the fill ... This gives the same problems.
The images are (primarily) /B/U format.
Would it help to completely erase layers which have V_sum = 0, or does that impact the analysis?
April 11, 2020 at 08:52 am - Permalink
I have since developed a function that returns 1 when the stack has "valid" images on all planes and 0 when the stack has any plane with a maximum of zero. I use this to allow/disable further processing options (i.e. thresholding on the entire stack with /P=(-1)).
I think after longer consideration, that ImageThreshold might benefit by a /Z flag, if not in general then certainly for the specific case (/M=3). Also, in this case with /M=3 on a zero plane, the threshold could just return an image with all values set to ... ZERO ... by default. Users can then gracefully handle any error that would be set with V_flag.
In my case, when the above changes would be implemented, I would not need to check (and then categorically disallow) the threshold method on the entire stack until all stack planes are valid. All thresholding methods would work without crashing (albeit, as I now fully realize, the results with /P=(-1) will make no sense until all planes in the stack are "valid").
April 11, 2020 at 09:16 am - Permalink
I apologize for any impression that I may have given that Igor Pro crashes in any way during this error. Poor choice of wording that I've since amended. Secondly, I apologize for any impression that I was venting here in great frustration at something that I suddenly found unbelievably wrong with Igor Pro. Poor choice of tone that I hope this note addresses.
My starting intent was to ask whether anyone else had noticed this error and whether I should perhaps be doing something to avoid it that was otherwise supposed to be self-evident.
I appreciate the good grace to be able to correct my mistakes in trying to put an honest intent forward but having a bad go-round at it. No excuses (my poor judgement here), just an appreciation for the ability to correct in hindsight.
April 11, 2020 at 05:49 pm - Permalink
Jeff,
I never thought much of the adaptive method for the following reasons:
1. It is hard wired to a line of 8 pixels so the results depend on minimum feature size.
2. It works on one direction so expect to get different results if you transpose the matrix.
If for some reason this method performs better than any other method in your application then you need to understand what is going on. For starters, the adaptive method (/M=3) does not support /P=-1. This is completely independent of the content of the various layers in your stack. Simply put, if your input wave has more than one layer and you use /P<0 you will get this error message. This means that if you really need to use this particular method then loop over the layers as in:
MatrixOP/FREE/O aa=layer(srcWave,i)
MatrixOP/FREE/O bb=sum(varCols(aa))
if(bb[0]==0)
continue // skip constant layer
endif
ImageThreshold/M=3 aa
Wave M_ImageThresh // store this result somewhere
endfor
I hope this helps,
A.G.
April 11, 2020 at 09:41 pm - Permalink
Thank you AG.
My application is to have all of the methods available in a popup in Image Tools. I coded this without paying attention to how each operation works.
Now that I understand where the real limitation is, I can actually make an easier toggle. I can just code to turn off /P=(-1) for the /M=3 mode.
It is interesting to learn that /M=3 on image and /M=3 on image^t will give different results. I'll have to play around to see whether this could be of help to some of the image analysis that we are doing.
I should eventually get to a point to include analysis layer-by-layer in addition to analysis over-the-whole-stack. The code you give fixes some of my brute-force approaches.
April 12, 2020 at 07:14 am - Permalink