Demo Analyze Everything Hung Up on Reconstruction

[carlos-gomez00]

Issue in: docs/01_code_usage/01_toolboxes/demo_analyze_everything.ipynb

Protocol: (1) Ran Juypter-lab from Miniforge prompt; (2) Opened demo_analyze_everything.ipynb; (3) Edited Cell 3, 4, and 7; (4) Ran code

=> When reaching Cell 12, the code is hung up and causes napari to stop responding.

I have attached the messages from the terminal window. Not sure if this is a computer admin problem or an issue of the parameters I input into the code.

[carlos-gomez00]

When Cell 12 stops and Cell 13 can be clicked following error is displayed:

---

IndexError Traceback (most recent call last) Cell In[13], line 4 1 _ = stress_backend.lbdv_info(Max_SPH_Deg=measurement_parameters['max_degree'], 2 Num_Quad_Pts=measurement_parameters['n_quadrature_points']) ----> 4 results_stress_analysis = measurements.comprehensive_analysis(results_reconstruction[2][0], **measurement_parameters, 5 verbose=verbose, use_dask=parallelize)

IndexError: list index out of range

[jo-mueller]

Hi @carlos-gomez00 ,

this PR should fix the second one of your problems. As for the first one, the PR fixes the link to the dashboard that's created so that it also works for the viewer.

The root cause, in this case, is probably that for some reasons (will have to look into the code), the reconstruction is sampling waaaay too dense on the surface of the droplet and then has to trace-refine a myriad of points, which is unnecessary. I can change the code to ensure that the density of points on the surface is calculated in physical units which should alleviate the problem a bit (but that's a separate PR).

[jo-mueller]

@carlos-gomez00 I just looked into the data you were trying to analyze and found another issue: The .tif image you exported (presumably in Fiji) has the axes order TZCYX but common convention is CTZYX - the Matlab STRESS code probably would have complained about this, too. You can change the axes order in python with something like image.transpose((2, 0, 1, 3, 4)) which fixes the order. Then, of course, you'd have to use only the channel with the droplet data for the analysis (e.g., image[0] after the reformatting).

If you do it from the viewer, this should be fine by default - checking why it was slow now.

Edit: PR #351 should fix the astronomical computation times. If you don't want to wait until the next release, a quick fix would be to change the resampling_length parameter to a higher value (e.g., 10 instead of 1).

This parameter essentially determines how many points on the surface of the droplet are used for the tracing. I assume that the legacy STRES code always resamples the image to a voxel size of 1µm so that the sample resampling_length always works. napari-STRESS gives you a bit more leeway which should make the analysis more precise for higher-resolution data.

[carlos-gomez00]

Hey @jo-mueller I left the workstation running and it did finish running the code, but it had strange results. Probably due to the axes order, I'll try changing it and running it again. Just to show what it did, I pasted the results below.

It finished the analysis

But the rescaled image did not overlap with the previous image

I'll upload with the results after fixing axis on the data

[jo-mueller]

@carlos-gomez00

But the rescaled image did not overlap with the previous image

This, at least, is something I'd expect. The input image doesn't show the correct physical pixel sizes, but the output does. You can fix it by passing the voxel sizes of the input data to the viewer in cell [9]:

viewer.add_image(example_data, scale=[voxel_size_z, voxel_size_y, voxel_size_x])

[jo-mueller]

Hi @carlos-gomez00 ,

can I close this issue?

[jo-mueller]

@carlos-gomez00

365 adds another dependency to the plugin to make sure that the dashboard always comes up when working with timelapse data.

[carlos-gomez00]

Hi @jo-mueller

I have tried to run the Notebook again and this is the error I obtained, the reconstruction didn't show this time

I didn't understand the error as it was set to cubic