-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enh: channel sensitivity ui #273
Conversation
Rather than another set of rows with the channel types duplicated it probably makes more sense as a grid layout like
|
I like this idea. Just pushed it |
Well not quite... you still have redundant channel type names and units (other than the "per distance") in there, and they don't line up in rows either: In other words, you did something like this rather than what I suggested:
I think my suggestion is more compact / consistent but contains all the same information. Can you see if my suggestion works? By eye looking at the |
mne_qt_browser/_pg_figure.py
Outdated
"""Convert data to physical units.""" | ||
# Load in some data and measure its range in a timeperiod | ||
start, stop = widget.weakmain()._get_start_stop() | ||
data, _ = widget.weakmain()._load_data(start, stop) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nmarkowitz I resized my window to show 800 (fT/cm)/cm so that the MEG scale bar should be 1cm but it was a bit big. Adjusting the __init__
of class ScaleBar
to use a flat instead of rounded cap (to not draw farther than we should) seemed to fix it:
pen = self.mne.mkPen(color="#AA3377", width=5)
pen.setCapStyle(Qt.FlatCap)
self.setPen(pen)
However, you should not need to know anything about the actual data values to know the effective scale on screen. So using data
at all (and derivatives like peak_to_peak_data
) like you do here should not be needed. The only thing that should matter are:
- The factors that are used to scale the data
- The number of pixels used to / allocated to show those data (which you should get from the viewbox somehow, could be correctly below?), which you can get from the proportion of the viewbox (in pixels) that is dedicated to showing the data
From those two things you should be able to figure out the effective scaling. Unpacking your code later you have (for mm
at least):
pixels_per_data_unit = pixel_height / data_height
peak_to_peak_pixels = peak_to_peak_data * pixels_per_data_unit
dpi = QApplication.primaryScreen().logicalDotsPerInch()
peak_to_peak_inches = peak_to_peak_pixels / dpi
peak_to_peak_mm = peak_to_peak_inches * 25.4
if units == "mm":
return (
_get_channel_scaling(widget, ch_type)
* peak_to_peak_data
/ peak_to_peak_mm
which is equivalent to
dpi = QApplication.primaryScreen().logicalDotsPerInch()
peak_to_peak_mm = peak_to_peak_data * pixel_height / data_height / dpi * 25.4
if units == "mm":
return (
_get_channel_scaling(widget, ch_type)
* peak_to_peak_data
/ peak_to_peak_mm
)
which in turn is equivalent to
dpi = QApplication.primaryScreen().logicalDotsPerInch()
if units == "mm":
return (
_get_channel_scaling(widget, ch_type)
/ (pixel_height / data_height / dpi * 25.4)
)
I'll push a commit to simplify the calculation once I verify it's correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, pushed a commit!
As usual, next I think some tests would be good. For example you could just get whatever the current scalings values are, change the units to / cm
or something and then query the double spin box values and make sure they changed by the correct amount. You could also resize the window by 10% for example and make sure the values change by 10%.
I just did:
and then opened the settings dialog and pressed
Assuming you can replicate, once you fix the bug you can to make sure the values update properly when activating/deactivating butterfly mode. But keep in mind #276 where I point out that butterfly mode is already perhaps somewhat broken. It might be hard for you even to measure the size of the scale bar given the overlap... but you can at least eyeball the top half of the scale bar for the topmost channel type and go based on that I think. |
Thanks for catching that. Just pushed commit |
@larsoner every failed test is due to the sensitivity unit test I added. It passes on my computer but I don't know how to make it pass on github. Maybe I should change what the unit test is? |
It could be some little precision issue, I think it's okay to use |
Just pushed using |
|
Now I have a bug where if I do:
This one looks correct, the distance from the top of the But if I do the same command without the So I think there's some bug with updating the scale bar values perhaps, but I think we can chalk this up to #276. Might be a good one to tackle next if you want @nmarkowitz or you can move on to making the sensitivity boxes interactive (I expect this one might be easy now hopefully)! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few cruft cleanups which I'll commit then mark for merge-when-green, thanks in advance @nmarkowitz !
FYI to spot these things, after you think your code is good for review and you push, I typically try to add one more step before pinging for re-review -- looking briefly at the diff on GitHub in the "Files" tab like https://github.com/mne-tools/mne-qt-browser/pull/273/files. A quick 30-sec scan of your own code probably would have caught these leftover lines to be removed!
Reference issue
#230 , #212 , #208 , mne-tools/mne-python#10888
What does this implement/fix?
Adds widget to settings dialog displaying units of sensor in relation to screen size. Ability to edit widgets will be done in future pull request