feat: V2 add back channel modes and multi-channel display #57
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## v2-mvc #57 +/- ##
=========================================
Coverage ? 74.59%
=========================================
Files ? 28
Lines ? 2925
Branches ? 0
=========================================
Hits ? 2182
Misses ? 743
Partials ? 0 ☔ View full report in Codecov by Sentry. |
|
hey @gselzer, |
There was a problem hiding this comment.
This is super awesome! One major step forwards towards parity with the old viewer!
I had a couple suggestions, but more importantly it seems like RGB mode is broken right now? When I run the following script, I see a 256-channel image, and switching to RGB mode crashes the viewer:
from qtpy.QtWidgets import QApplication
from skimage.data import astronaut
from ndv.controller import ViewerController
app = QApplication([])
viewer = ViewerController() # ultimately, this will be the public api
_data = astronaut()
viewer.data = _data
viewer.show()
app.exec()
src/ndv/controller/_controller.py
Outdated
| handle = self._canvas.add_image( | ||
| data, cmap=lut_ctrl.lut_model.cmap, clims=lut_ctrl.lut_model.clims | ||
| ) | ||
| lut_ctrl.handles.append(handle) | ||
| self._canvas.set_range() |
There was a problem hiding this comment.
In a way, a PImageHandle could be considered a PLutView, no? I'd think we could simplify the code if we refactored the LutController to, instead of having a list[PImageHandle], to just have a list[PLutView]. But you/I could wait to try that in a separate PR...
There was a problem hiding this comment.
In a way, a PImageHandle could be considered a PLutView, no?
hadn't thought about it that way (yet). PImageHandle is something that would directly control a texture object in the canvas (vispy/pygfx) backend (it does not receive input), and PLutView is a widget that does receive input from the user to update the model. If the LutController doesn't have a set of handles to update directly, then we would need to have all of those connections between on_model_lut_changed and the thing that updates the vispy texture back on the main view object. So, at the moment, I think i'm happier having the controller be the one thing that negotiates changes to model/widget/texture for a given LUT. and will likely remove ImgHandles from th main view
yep, haven't yet worked on RGB mode. |
|
I'm going to revert this to a6e120e, before i started working on Color mode... and where I liked the state of it. Will merge and pick up different modes later |
tlambert03
force-pushed
the
v2-add-channels
branch
from
0ee0be1 to
a6e120e
Compare
|
merging so we can play with it in #55 |
tlambert03
changed the title
This pull request includes several updates and improvements to the project, focusing on dependency updates, documentation enhancements, and significant changes to the
ViewerControllerclass in thesrc/ndv/controller/_controller.pyfile. Here are the most important changes:Dependency Updates:
.pre-commit-config.yaml:validate-pyprojectupdated fromv0.22tov0.23.typosupdated fromv1.27.0totypos-dict-v0.11.35.ruff-pre-commitupdated fromv0.7.2tov0.8.0.Documentation Enhancements:
README.md.ViewerController Class Updates:
ChannelModeandLUTModelimports and refactoredViewerControllerto utilize these models.channelModeChangedsignal connection and_on_model_channel_mode_changedmethod to handle channel mode changes. [1] [2]channel_modehandling._update_canvasmethod to handle asynchronous data requests and manage LUT controllers.Miscellaneous Changes:
qtandjupyterinpyproject.toml.mypyfromndv._old_viewer.*tondv.old_viewer.*inpyproject.toml.