Posted by
vischer on
Mar 24, 2018; 5:25pm
URL: http://imagej.273.s1.nabble.com/Problem-with-Maximum-intensity-projection-tp5020309p5020331.html
Hi Gabriel,
good idea to duplicate the file, which I have done in the version below.
And thanks for pointing out that a maximum can occur several times.
I also documented the limitations. These depend on the number of bits needed for the stacks's brightest pixel, as the remainder of the 23 bit mantissa can be used for the z-identifiers.
(In the 16-bit T1 sample image you mentioned, the maximum pixel is at ~800, so there is plenty room).
The new version (below) automatically subdivides the fractional part (0 to <1) into the needed bins to identify the slices, so I don't need to use a fixed number like "100" in the previous version (but it has become a bit more cryptic).
//Part A: Creating a demo stack
close("Demo*");
random("seed", 0);
newImage("Demo", "8-bit random", 20, 20, 10);
run("Scale...", "x=30 y=30 interpolation=None average create process");
//demo image: in top left square, max intensity is 190 and occurs in slice#9 (1-based)
//Part B:
//From an 8- or 16-bit stack, a map of maximum positions is created
//Limit for 8 bit: 32K slices
//limit for 16 bit images: 127 slices
run("Duplicate...", "title=Demo32 duplicate");
run("32-bit"); //still holding integers
maxSlc=nSlices;
for(slc = 0; slc < nSlices; slc++){
setSlice(slc + 1);
run("Add...", "slice value=" + (slc/maxSlc) );//add fractional slice identifiers
}
run("Z Project...", "projection=[Max Intensity]");
run("Macro...", "code=round(1+v%1*"+ maxSlc +")"); //isolate and multiply fractional part
rename("Demo_Max_Positions");
run("Fire");
close("Demo32");
best regards,
Norbert
> On 24. Mar 2018, at 12:33, Gabriel Landini <
[hidden email]> wrote:
>
> 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--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html