New function to accept multiple images for segmentation

[JohnnyTeutonic]

I have included a new function to accept multiple images in viz. This function accepts multiple images in its function call to allow for a convenient display of various segmented images in one figure. It also includes an optional parameter which allows for the displaying of the images in different colormaps. I have also included a cast to int inside of imshow_rand when the random colors are being displayed, as I noticed that there was an issue with calling this function (owing to the use of np.ceil).

[coveralls]

Coverage decreased (-0.1%) to 50.472% when pulling 4943a84facfad01c734786c07da42016b5a1ec8f on JohnnyTeutonic:imshow into f84a682a5c84dad7429235c9b09c4e890cd61dc0 on janelia-flyem:master.

[coveralls]

Coverage decreased (-0.2%) to 50.459% when pulling 88f02b4b603ad32904a89b1ae14ecd2a5253af8a on JohnnyTeutonic:imshow into f84a682a5c84dad7429235c9b09c4e890cd61dc0 on janelia-flyem:master.

[coveralls]

Coverage decreased (-0.2%) to 50.406% when pulling 574d00e5047247b1c9b7a17ca65c8b753a1a7883 on JohnnyTeutonic:imshow into f84a682a5c84dad7429235c9b09c4e890cd61dc0 on janelia-flyem:master.

[coveralls]

Coverage decreased (-0.2%) to 50.392% when pulling 8a4009fffbf548424da266f26cfb530b4a6573a8 on JohnnyTeutonic:imshow into f84a682a5c84dad7429235c9b09c4e890cd61dc0 on janelia-flyem:master.

[JohnnyTeutonic]

Also, got big-cat launch to work on linux!

[JohnnyTeutonic]

I think the build is failing because it is building with python3.5 and I have included the 3.6 formatting syntax as you have suggested. Also, I missed your comment about the LAB coloring scheme. I have investigated that and can tell you that the warning is caused by the 'z' axis in the call 'skimage/color/colorconv.py/lab2xyz' where there are pixels with a value lower than zero. I haven't been figure out how to change the code to deal with this warning as yet (barring the explicit suppression of that particular warning) but I can tell you that this doesn't occur when the parameter 'labrandom' is set to false in imshow_rand.

[JohnnyTeutonic]

I had to change the looping back to 'i-1' because plt.subplot has indexing start at 1 for compatibility purposes with MATLAB :)

[jni]

@JohnnyTeutonic you can (and should) change the Python version used for testing in .travis.yml.

Re i+1, I know that subplots use that, I'm saying, make i start from 0 and then use +1 where you have to, rather than making it start from 1 and then using -1 where you have to. =)

Regarding passing axes, here's what I mean: https://matplotlib.org/faq/usage_faq.html#coding-styles

ie instead of:

plt.imshow(image)

do:

if ax is None:
    fig, ax = plt.subplots()
ax.imshow(image)

or:

if ax is None:
    ax = plt.gca()  # get current axes
ax.imshow(image)

Generally, always use ax.imshow and ax.plot, instead of plt.. I know, I know, the existing code doesn't do that. I was young and foolish when I wrote it. Much like you are now. =P =P

[jni]

@JohnnyTeutonic regarding the lab2xyz -> xyz2rgb color conversion, I know (vaguely) that that's what's causing it, what I'm saying is, I would like you to figure out when a Lab triplet is out of range and fix it before converting to RGB. =) OR, you could manually convert lab2xyz, use np.clip to clip the negative z values, and then use xyz2rgb to get the RGB tuples back.

I want to use labrandom basically always because, to my eyes at least, it produces a much more pleasing color map than random RGB. Don't you think?

[JohnnyTeutonic]

Well I tried changing it to 3.6 in the .yml file but still failed. I have tried changing it in setup.py as well to see if that helps... I changed all instances to ax.imshow. I thought of using np.clip last night actually on that! I wasn't able to succeed .I also tried manually changing the values but still have a few pixels get below zero. I will hopefully solve this issue soon :) And yes, I am young and foolish that is true!

[jni]

Ah! Look at what the yml file is doing — it's making a conda environment. So you need to change the environment.yml also. Sorry I missed that.

[JohnnyTeutonic]

No module named cythonize???

[JohnnyTeutonic]

sorry, no module named Cython...Very confused.

[JohnnyTeutonic]

I am wondering whether Cython 0.17 is available yet for python 3.6?

[JohnnyTeutonic]

Well I got rid of the cython error but I am still not succeeding in getting the test to pass.

[JohnnyTeutonic]

I have changed the setup.cfg file, asv.conf.json and setup.py to reflect the adoption of 3.6. I am unsure whether this is what I should have done but obviously I can rollback if need be. Looking at the Travis build, I can see that the virtual env is being created in 3.6 but the tests are being run still in 3.5. I have no idea why...

[JohnnyTeutonic]

I've tried for several hours now to solve the problem with the Z pixels. I have tried clipping as well as altering the values for 'rand_colors' to no avail. The issue to me seems to be with the code inside skimage/color/colorconv.py, Even if you perform np.clip before calling lab2xyz or lab2rgb, it will still complain about Z pixels being below 0. It's not very straightforward to determine values that will not cause Z pixels to be below 0.

[JohnnyTeutonic]

Okay, sorry for all the comments. I tweaked the colours now and the warning is gone...

[jni]

WTF: https://travis-ci.org/janelia-flyem/gala/builds/239038966#L495

Probably some update to networkx that broke the edge iteration. Can you update the test to:

assert (1, 5) in g.edges() or (5, 1) in g.edges()

Not due to your PR but would be nice to have the tests passing before merging. =)

[JohnnyTeutonic]

I have tried to include the changes you suggested. I am a bit confused as to how to pass in the 'axes' parameter in my own function show_multiple_images. My use case is to allow for just one call of my function to show multiple images in the same figure. I have included your changes but am not sure how to pass in the axes object inside my function. I have looked at some documentation but still am a bit confused. Also, I fixed the LAB conversion scheme through randomising the input values. I didn't find a formula...It still is randomised however. I can't see any segments that have the same colour lying contiguously.

[coveralls]

Coverage decreased (-0.3%) to 50.327% when pulling 981755e900282ca8867b2a569b235ffe33ba010b on JohnnyTeutonic:imshow into f84a682a5c84dad7429235c9b09c4e890cd61dc0 on janelia-flyem:master.

[jni]

@JohnnyTeutonic the idea is that you can create the figure ahead of time:

images = ...
n_images = len(images)
fig, axes = plt.subplots(1, len(images))
show_multiple_images(images, axes, 'rand')

(Incidentally, if axes is not None, you probably want to remove the call to plt.figure().)

That way, you now have the flexibility to use some other grid style:

images = ...  # 4 images
fig, axes = plt.subplots(2, 2)
show_multiple_images(images, axes=axes.ravel(), 'rand')

And, this reminded me of something. Rather than using plt.figure and fig.add_axes, you should probably use plt.subplots at the top — this will let you use sharex=True, sharey=True, which will give you joint panning and zooming for all of the panels in your figure.

[coveralls]

Coverage decreased (-0.3%) to 50.327% when pulling b2216725c8d1bb6341ec81f339439342d7a5d0ec on JohnnyTeutonic:imshow into f84a682a5c84dad7429235c9b09c4e890cd61dc0 on janelia-flyem:master.

[JohnnyTeutonic]

I will see if i can wrap my head around it. Incidentally, ev.sorted_vi_components I think has some buggy code....I will try and show you it in person on Tuesday. It is not giving me the desired labels that I need. Here is the output of my notebook showing what I mean with a simple segmentation. Please forgive me if I have mistaken something conceptually. When I call sorted_vi_components, I believe it should be outputting just one label corresponding to a label which has the worst entropy (h(y|x)) found in the gt and one label that corresponds to the worst entropy for h(x|y) for the input segment. If you look at my notebook, you will see that it recursively outputs four four-tuples (giving 16 values), when it should be only outputting a single four-tuple with the label in gt with worst entropy, h(y|x), the label in seg with worst entropy, h(x|y) or whatever the order is... (I fixed the docstring as you know).

You should see that some of the numbers are floating poitn numbers. They definitely correspond to the entropy scores. I think I can maybe fix the code up but only if you think I am right about this...

[jni]

It's not buggy, it's clearly (for once =P) documented in the docstrings:

• https://github.com/janelia-flyem/gala/blob/f84a682a5c84dad7429235c9b09c4e890cd61dc0/gala/evaluate.py#L1214
• https://github.com/janelia-flyem/gala/blob/f84a682a5c84dad7429235c9b09c4e890cd61dc0/gala/evaluate.py#L1258

[jni]

btw let's keep the discussion on here related to the PR.

Also, try to use gist.github.com to share notebooks, rather than screengrabs. You can upload a full notebook to a private gist and then share the URL.

[JohnnyTeutonic]

I read the docstrings of course but I found it a bit difficult to follow what was going on I guess, owing to the complexity of the format. Anyway, I get now that the first tuple is the labels, second is entropy, third is other labels, fourth is other entropy. all good.

[jni]

Here's the NumPy Docstring standard format, which you should be familiar with. =)

https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt

[coveralls]

Coverage decreased (-0.3%) to 50.353% when pulling 75094bda5b92596dc9220218b9a7d050ce6fd11c on JohnnyTeutonic:imshow into f84a682a5c84dad7429235c9b09c4e890cd61dc0 on janelia-flyem:master.