-
Notifications
You must be signed in to change notification settings - Fork 26
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
x-cut x-scaling issue with overlay_href #24
Comments
A couple of observations: I notice that p-cuts on this file looks better, but draws outside its cut rectangle. I see a similar out-of-range draw with p-cuts in alaska.prm, btw. If I call overlay_array on a SigPlot with plotType=raster, layerType='2D', the |
Thanks for the detailed feedback on this issue! The jsFiddle pulls sigplot from I've also modified our build script to include the Git hash in the distributed files so there is no longer any ambiguity about what commit produced the files. I'm able to reproduce the x-cut issue and will fix that and inform you when I have a new version for you to test. |
@sterre I'm going to open separate issues for the two other behaviors you observed. |
@jcsammy I just pushed a fix to |
@sterre I cannot reproduce the 'x' button shows 'x' value instead of 'x-cut' on Raster. Here is the code that I'm using:
I'm not sure what you mean by setting Can you provide the |
I think the x-button problem may be a non-problem. The Note that if the subsize equals the data length (one frame), the raster is still blank. (I expected a single row.) Here's the call to reproduce that blankness:
Comment out |
@sterre gotcha, this is as I suspected. If you set layerType to '2D' but don't set a I'm going to change it such that if you pass a header without a subsize to Layer2D, then the subsize is assumed to be the size of the file (i.e. your raster will have one line across the top). I'm also going to add a
|
@maihde, testing on Steps to reproduce:
|
@jcsammy I'm able to reproduce this so I'll will get it fixed. I was looking at the inability to do a jsFiddle x-cut as well; this seems to be similar to the keypress handling issue in Jupyter notebooks. The interaction between jsFiddle and SigPlot is causing keypresses to be missed unless you ensure the plot area has received focus (by mouse-clicking on the plot or the white area next to the plot). In other words jsFiddle steals the focus, so hovering the mouse over the plot isn't sufficient for SigPlot to get focus. You can give it a try here: |
@maihde testing this issue on version {{{2.0.0-rc6-ad99ae5}}} i don't think that x-cut is cutting the appropriate data if you are zoomed into the raster. i have a file that has a signal for about 2/3 of the raster, then no signal for the final 1/3 of the raster. if i zoom in such that part of the view has signal and part doesn't, and then x-cut where there should be no signal, i still see signal in my x-cut. i believe it is taking the location of the mouse within the zoomed view, and then x-cutting the unzoomed data at that location (which does contain signal), then displaying that data zoomed in frequency. put another way, if my raster was one column wide and each row was populated with the row number from 0-99. then i zoom in from 10-20 rows and x-cut the middle, i believe i would see an x-cut value of 50 as opposed to 15. this is just my hunch based on what i'm seeing, i haven't tried this particular test. |
Thanks, I won’t have time to take a look at this until next weekend. There
are a few unit tests that I added for x-cut and y-cut...are you able to
copy and modify one of those to demonstrate the behavior you are seeing?
Michael
…On Fri, Oct 5, 2018 at 11:45 AM jcsammy ***@***.***> wrote:
@maihde <https://github.com/maihde> testing this issue on version
{{{2.0.0-rc6-ad99ae5}}}
i don't think that x-cut is cutting the appropriate data if you are zoomed
into the raster.
i have a file that has a signal for about 2/3 of the raster, then no
signal for the final 1/3 of the raster. if i zoom in such that part of the
view has signal and part doesn't, and then x-cut where there should be no
signal, i still see signal in my x-cut. i believe it is taking the location
of the mouse within the zoomed view, and then x-cutting the unzoomed data
at that location (which does contain signal), then displaying that data
zoomed in frequency.
put another way, if my raster was one column wide and each row was
populated with the row number from 0-99. then i zoom in from 10-20 rows and
x-cut the middle, i believe i would see an x-cut value of 50 as opposed to
15. this is just my hunch based on what i'm seeing, i haven't tried this
particular test.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOCItoGmn6OuZvT3DHLVm2FyV_M51k6ks5uh5rTgaJpZM4Vjpld>
.
|
@maihde I tried using jsfddle to create an example that you can add to your unit tests https://jsfiddle.net/xykbvp3q/5/. The interactive plot.xCut/yCut functions don't seem to be working for me, but this at least shows the problem. Ideally both plots would show a line at 15, when you do their corresponding x/yCut at abscissa 15, but instead they show a plot at 50 because 15 is the middle of the zoom. |
@jcsammy Thanks for the jsFiddle!
Within the jsFiddle environment plot keyboard presses will only take effect
if you first mouse-click on the plot. This is because the logic in SigPlot
for determining if the mouse if over the plot when the keypress is made is
interrupted in the jsFiddle environment. A similar behaviour happens
within Jupyter notebooks. I haven't found a good solution yet to working
around this.
As for the x-cut and y-cut issue you demonstrated, I've found the issue and
have a preliminary fix in place. I should have a fix published this
weekend for you to try out.
…On Mon, Oct 8, 2018 at 9:39 AM jcsammy ***@***.***> wrote:
@maihde <https://github.com/maihde> I tried using jsfddle to create an
example that you can add to your unit tests
https://jsfiddle.net/xykbvp3q/5/.
The interactive plot.xCut/yCut functions don't seem to be working for me,
but this at least shows the problem.
Ideally both plots would show a line at 15, when you do their
corresponding x/yCut at abscissa 15, but instead they show a plot at 50
because 15 is the middle of the zoom.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOCIhZ5RHeeB5V7FEU3d0BZqQ2b05Frks5ui1WngaJpZM4Vjpld>
.
|
Describe the bug
Using version 2.0.0-rc2 which is believed to be hash bf788b7.
I am using overlay_href to raster the attached type 2000 blue file. When I hit 'x' to x-cut the raster, the X_CUT mode plots in index rather then abscissa mode. So I have to zoom down to 0-511 Hz to find my x-cut.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
x-cut should be drawn matching the raster (i.e. abscissa mode or index mode)
jsFiddle
jsFiddle plotter does not seem to have x-cut available
Screenshots
raster.tmp.gz
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: