Feature suggestion / macro question

[zitmen]

I'd like to know if it could be possible to automatically detect the Z range of a 3D
STORM localizations file when doing a visualization, a bit like it is possible for
the XY range (An "Auto" button that uses the extreme Z coordinates in the
file as Zmin and Zmax). This would allow to spare memory (by not generating empty Z
slices), and to spread the Z-color coding in an optimized manner. Ideally, it would
be possible to select a proportion of localizations in the extreme slices (like 1%),
but this could be more complicated. 

As a work-around, I'd like to implement this in a macro that would get the max an min
of Z in a localization file and then lauch a visualization. The problem is, I don't
know how to retrieve a column from the Results window via a macro (I tried to record
the histogram function but to no avail). Any idea on how to do this?

Thanks!

Original issue reported on code.google.com by lechristophe on 2014-10-28 10:10:34

[zitmen]

Ok, I will look into it to see what is possible.

Regarding the macro, I don't know how to do it using the generic macro language, however,
I know it is possible to use JavaScript macro for this, see attached example.

Original issue reported on code.google.com by zitmen on 2014-10-28 15:38:20

---

• Attachment: macro.js

[zitmen]

Thanks, I was able to use your code in a macro via the eval("script") command. Regarding
implementation in ThunderSTORM, something simple like auto-detection of extreme Z coordinates
(like for the XY coordinates) would be perfect.

Original issue reported on code.google.com by lechristophe on 2014-10-28 21:40:04

[zitmen]

The automatic range estimate is now implemented in revision 9f89e6ece096. If the 3D
mode is enabled and if you click on automatic range detection using results, it takes
min/max values and rounds them to the closest values outside of the range given by
the current step size, e.g., min=-253, max = +333, current z-range = "-400:50:+400",
then the z-range is updated to "-300:50:+350".
The daily build will be available later today.

I'll keep this issue open, because removal of empty slices can yield a lot of free
memory, however, it is not as straightforward to implement this, because there will
be some more updates to the rendering dialog in the next version.

Original issue reported on code.google.com by zitmen on 2014-11-03 10:22:55

• Labels added: Type-Enhancement, Priority-Low
• Labels removed: Type-Defect, Priority-Medium

[zitmen]

Sounds good, I'll keep an eye on the next builds. Thanks!

Original issue reported on code.google.com by lechristophe on 2014-11-03 11:44:05