3D Example intent unclear

[RossBoylan]

https://github.com/ucsf-deb/bifs/blob/master/examples/bifs_cl_3D.py seems to be about 3D images, judging not only from its name but comments within the file. But the image loaded is only 2 dimensional, even if it is a picture of something 3D.

Actually, it seems the test file is 3D, so this may be a big misunderstanding. Leaving this open until fully understood. In particular, the last paragraph below about passing 2D data to plot_param_func() remains true AFIK.

Having an actual 3D example seems like a good idea, since all of our actual work is with 3D images. Is that the intent? Should it be the intent?

If it is the intent, it is possible the input file ../tests/images/test3Dnoisy_sphere.tiff has become corrupt, or that the routines now in use are concealing 3D data that is actually there, e.g., by reading only the first slice. Have either of those things happened?

Finally, this passes 2D data to plot_param_func(), and 2D data are the only ones that prompt it to use a 3D projection! What's up with that? More about that function in a separate bug.

[RossBoylan]

Tracing through #16 (comment) another bug using this image, it actually is reported to be 3D.

[RossBoylan]

The file is a 3D image, but it is/was being read by imageio.imread() which only reads 2D images. So apparently it pulled out one slice. Then later code, which required a 3D image, failed.

I have fixed that with pending changes that use bifs, rather than imageio, to read the file. Actually, bifs ends up using imageio.volread() under the hood. bifs_cl_3D.py now runs, albeit the uncertainty raised in this issue remains.

The lingering questions are

1. Was there some deliberate intent to work only with a 2D slice? The fact that some of the example code only works with 3D data suggests not, but obviously the old code's use of imageio.imread() suggests there was.
2. Why plot_param_func is doing special handling for 2D data. This second issue is best addressed in plot_param_func() #29, which already mentions it, albeit in an easy to miss way.

This problem bears a family resemblance to #16, which also involves problems using an external package's 2D only method on 3D data. It is possible that the underlying libraries have shifted their assumptions: the functions we were calling may have accommodated 3D better in the past.