-
-
Save mkitti/2f7c5fc3d3f8b0d15dd13f6d67b0e73d to your computer and use it in GitHub Desktop.
| """ | |
| napari.jl | |
| Test using PyCall.jl to invoke Napari ( http://github.com/napari ) from | |
| the Julia language ( https://julialang.org/ ) 1.3.1 | |
| Mark Kittisopikul | |
| January 29th, 2020 | |
| """ | |
| using PyCall | |
| pygui_start(:qt5) | |
| # needed to kickstart Qt5 for some reason | |
| qapp_obj = pyimport("qtpy.QtWidgets").QApplication([""]) | |
| napari = pyimport("napari") | |
| skimagedata = pyimport("skimage.data") | |
| astronaut = skimagedata.astronaut(); | |
| # Modified 2020/09/14 to add name keyword argument | |
| # https://github.com/napari/napari/issues/1630 | |
| napari.view_image(astronaut, name="astronaut") | |
| using Images, TestImages | |
| hela = testimage("hela-cells.tif"); | |
| hela = imadjustintensity(hela); | |
| hela = channelview(hela); | |
| hela = PermutedDimsArray(hela,(2,3,1)); | |
| #napari cannot handle UInt16 ?? Maybe QT issue | |
| #hela = reinterpret(UInt16,hela); | |
| napari.view_image(collect(Float32.(hela))) | |
| mandrill = testimage("mandrill.tif"); | |
| mandrill = channelview(mandrill); | |
| mandrill = reinterpret(UInt8,mandrill); | |
| mandrill = PermutedDimsArray(mandrill,(2,3,1)); | |
| napari.view_image(collect(mandrill)); | |
| if !isinteractive() | |
| qapp_obj.exec() | |
| end |
https://gist.github.com/mkitti/2f7c5fc3d3f8b0d15dd13f6d67b0e73d#file-napari-jl-L20 now requires the name= keyword argument be set.
napari.view_image(astronaut, name="astronaut")
Thanks, works fine with Julia 1.5.3 :)
Great! I've been meaning to create a package around this. Had a few Napari bugs to squash first.
Napari using PyCall also doesn't seem to be super stable. I encountered several crashes (accidentally providing a complex Image or NaN valued images). It always segfaulted my whole Pluto session 😢
That's really unfortunate that there is no good image viewer in Julia available.
ImageView.jl suffers from the Gtk.jl Bug which makes it unusable for me.
What would be needed to wrap it into a Napari.jl package? Do we need to ship a full Python binary or should we do it similar to PyCall.jl?
A Napari.jl package would still depend on PyCall.jl to do the heavy lifting. The other route that could be considered would be using https://zeromq.org/
Some of the issues are Napari bugs due to unexpected input from Julia. Some are PyCall issues. The intent of a Napari.jl package would be to try to save the user from some of those gotchas by normalizing the data.
The Gtk threading issues are unfortunate. There might be a way to pin tasks to threads though, which might resolve some of the issues:
https://julialang.zulipchat.com/#narrow/stream/225542-helpdesk/topic/confused.20by.20how.20threads.20are.20scheduled/near/217623767
JuliaLang/julia#34267 (comment)
I have motivation to roll out a v0.0.1 Napari.jl package this week due to the I2K conference.
Yeah, I guess PyCall.jl is still the best option atm.
If I can help you, just reach out. I'm not experienced in shipping PyCall based packages but maybe I can support adding edge cases which crash.
It would be also cool if it's possible to run Napari in different threads or to prevent that they crash the whole Pluto session.
I haven't forgotten about this. Just a bit busy at the moment.
If you are interested in a full blown Julia package, check out the early preview of Napari.jl: https://github.com/mkitti/Napari.jl
Thanks for posting that 😃