Cool! and a question

[tlambert03]

just wanted to say it's very neat to see this package. just took it for a spin, and it works great. love the delayed option, and it works particularly well having both of those options with napari/napari#1023 where you'll be able to pick which one you want either by dragging/dropping or checking/unchecking:

I'm curious why you chose to go with a default of visible = False? (i was confused at first not seeing anything). Is that particularly useful for the way you use napari?

[evamaxfield]

Thanks @tlambert03!

We have a lot of images that are 4+ channel where a lot of the images come with a brightfield microscopy channel. This causes just too much initial visual overload to the user. If I ever get around to making a PR to napari to allowing the passing of a list of booleans to the visible parameter I would likely release a new version of this plugin to have all channels turned on except for brightfield. Or, just the first three for example.

[tlambert03]

ahhh, makes sense.
I can probably make visible accept a list of bool in a few minutes... will do that tonight.

a possible workaround would be to not use the channel_axis argument, and break up the channels into different (data, meta) tuples yourself. (here's how we do it internally).

[evamaxfield]

I am a bit conflicted about splitting up into different (data, meta) tuples. Totally agree that is one way to do it but I think I am reserving that for the time to come where we parse metadata and look for "segmentation" or similar and tag it as the appropriate layer object. (If that made sense great 😂 )

[tlambert03]

added in napari/napari#1092

[evamaxfield]

@tlambert03 I see that the sequences PR is now merged! Any idea as to when a new napari release will be coming? Will spend some time to resolve this issue regardless though. Any ideas on how to verify napari version for this package?

if napari.__version__ <= "{blah}":
    visible = False
else:
    visible = some_visible_sequence

[tlambert03]

we're pushing to release real soon. so i expect within a week or two? Since technically your whole plugin can't work until the next napari release anyway, how about adding napari>=0.3.0 to your install_requires in setup.py? If you had incorporated this into aicsimageio proper, I'd say don't do that, but as long as you have a separate package for this plugin, you might as well just depend on the napari version that you want people to use.

[evamaxfield]

Ahh cool. Didn't know if that was "best practice" or not to have a version pin for the base repo of a plugin so that makes it easy. Will come back to this once 0.3.0 is released :)

[tlambert03]

I'm not sure it's something you'd always want to do... like, if there was plenty of functionality in your plugin available to users of previous versions of napari (or if there was lots of functionality that didn't relate to napari at all) then I would suggest something like if napari.__version__ >= ..., but since this package is specifically a napari plugin, and since napari reader plugins aren't supported in napari < 0.3.0, I think it's a safe approach here.

[jni]

@JacksonMaxfield we are on the verge of releasing 0.3.0 (next couple of days), and the biggest update is that we have forked pluggy to suit our own purposes (long story), so now the import is from napari_plugin_engine import napari_hook_implementation. We'd love to feature napari-aicsimageio in our release notes, so it would be great if we could get this updated and the PyPI version compatible with the latest version of napari. The latest docs are here:

https://napari.org/docs/plugins/for_plugin_developers.html

We'd be happy to submit a PR for these changes, but we'd still need you to push up a release to PyPI!

Many thanks to @tlambert03 for basically everything to do with plugins in napari. =)

[tlambert03]

Just a minor clarification: for now it will still “work” to import HookimplMarker from pluggy and make your own decorator (that code is cross compatible), so it’s more about setting “conventions” and examples 🙂. (I believe your current plugin on pypi would still work)

[evamaxfield]

Thanks for the update!

I have a PR in to this package to make the necessary changes to resolve the issue that was originally brought up ("balancing initial render time and user feedback that the image has loaded") and upgrades to napari_plugin_engine.

A quick look over would be much appreciated if you have the chance.

Specifically, I have one question on this. Because this issue requires that I can pass multiple visible booleans to add_image but napari==0.3.0 hasn't been released yet, I have just left it off the dependency list. Or I can simply wait until 0.3.0 is released and then immediately release this. Thoughts?

[evamaxfield]

Ehhhh actually on more thinking of this. I am just not going to have a napari version pin on the package. If people are trying to use plugins they should be using >=0.3.0 anyway. So as long as the napari_plugin_engine changes look good (and I tested locally on napari@master) then good to go.

[tlambert03]

that's probably fine :) you're ahead of the game anyway, everyone will likely be on 0.3.0 if they're using your package. will look at your PR now

[evamaxfield]

napari-aicsimageio==0.1.1 released :)

Looking forward to seeing napari==0.3.0 🎉 An accomplishment to be sure 🎉

[tlambert03]

thanks!