Support more viewer options in the ImJoy API
See original GitHub issueWould be nice to be able to pass viewer options when creating the viewer window including cmap
, ui_collapsed
, rotate
, axes
, mode
etc. Just like the options accepted by the view
function in the itkwidgets
,
This can be passed as config
:
const viewer = await api.createWindow({
src: "https://kitware.github.io/itk-vtk-viewer/app/",
config: {...viewer options...},
data: { image: imageArray }
})
For updating the options later, perhaps would be also nice to have setConfig
(and getConfig
).
Issue Analytics
- State:
- Created 3 years ago
- Comments:12 (7 by maintainers)
Top Results From Across the Web
ImJoy Docs: Interactive Documentation Made Easy!
In the ImJoyPlugin instruction, you can pass additional options. More specifically, they can be any options for the <config> block of an ImJoy...
Read more >Interactive Microscopy Control with ImJoy - Pycro-Manager
The returned viewer object contains a set of API functions exported by the itk-vtk-viewer plugin, and we will call viewer.imshow() for displaying images...
Read more >https://raw.githubusercontent.com/imjoy-team/imjoy...
ImJoy API Every plugin runs in its own sandbox-like container environment (web worker or iframe for JavaScript, process for Python).
Read more >ImJoy - ImageJ Wiki
The most common way to build ImJoy is to provide a plugin file. ... We support two-way integration: 1) connect existing web app...
Read more >Overview - ImJoy
Checkout the documentation for how to get started and more details for how to ... Support Javascript, native Python and web Python; Concurrent...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
👍 👍 support for this in #343
For custom codec, we can directly emit progress in the encoder/decoder function. For the transfer progress, typically we just send the data through a certain transport layer (e.g. jupyter or socketio) without knowing the progress. However, I think we can easily support that by changing the way we send data, for example, say we want to send a numpy array to another peer, instead of directly sending the data, we can send a
getChunk
function together with its total length, then the other peer can fetch data chunk by chunk. We can then easily add a callback function in thegetChunk
function to report the progress. This can be done by a custom codec, or we can do it directly by default, we will need to think about the api though. Any idea on how the api should look like?