Posted by
Gabriel Landini on
Mar 24, 2018; 11:33am
URL: http://imagej.273.s1.nabble.com/Problem-with-Maximum-intensity-projection-tp5020309p5020330.html
Thanks Norbert.
Can I add some comments that might be useful for prospective users: the macro
detects the "deepest" slice with the highest intensity. I.e. if the same
maximum happens in more than one slice the index returned is the highest in
the z direction. If one wants the smallest one, I guess that reversing the
stack would do it (and convert the result value accordingly).
Any reason to restrict it to 100 slices? Maybe do it with 1000 or so, then
check nSlices for >999 at the start and warn the user if so.
Using the t1-head and the 1000 multiplier it gets the 129 slices labelled
correctly, but using 10000 (yes I know...) slices 9 and 10 get labelled both
9. I suppose there is some effect of the representation/rounding of the 32bit
value that we need to be aware of.
Another idea: maybe it would be useful to use a temp file duplicated from the
original, otherwise running it twice on the same image, the macro adds the
fractional part to the original again and returns the wrong index in the
result (and also avoids having the original converted to 32bit and with a tiny
fractional value added).
Thanks again for such a nice idea.
Best wishes,
Gabriel
On Friday, 23 March 2018 20:53:17 GMT
[hidden email] wrote:
> Herbie already gave a link to the documentation:
> > <
https://imagej.nih.gov/ij/macros/examples/MathMacroDemo.txt>
>
> I simply used the macro recorder and chose:
> Process>Math>Macro...
> and forgot to explain.
>
>
> My demo version runs quick enough for the example. But a faster version is
> shown below, where the per-pixel macro code is only used for a single slice
> (the projection):
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html