Thanks to visit codestin.com
Credit goes to github.com

Skip to content

flipping of imshow in specgram #17878

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

Closed
TomFD opened this issue Jul 10, 2020 · 5 comments · Fixed by #17897
Closed

flipping of imshow in specgram #17878

TomFD opened this issue Jul 10, 2020 · 5 comments · Fixed by #17897
Labels
Difficulty: Easy https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues Good first issue Open a pull request against these issues if there are no active ones!
Milestone

Comments

@TomFD
Copy link

TomFD commented Jul 10, 2020

Bug report

Bug summary

The function

matplotlib.pyplot.specgram

uses imshow internally to plot a spectrogram but does not set the origin. So someone can externally overwrite the standard behaviour and wonder, why the spectrogramm is flipped.

Unintensionally, this can even happen if another imshow was used before with different origin.

Code for reproduction

For reproduction, only the origin setting before the function call is added to the standard demo and flips the output.

import matplotlib.pyplot as plt
import numpy as np
np.random.seed(19680801)
dt = 0.0005
t = np.arange(0.0, 20.0, dt)
s1 = np.sin(2 * np.pi * 100 * t)
s2 = 2 * np.sin(2 * np.pi * 400 * t)
s2[t <= 10] = s2[12 <= t] = 0
nse = 0.01 * np.random.random(size=len(t))
x = s1 + s2 + nse  # the signal
NFFT = 1024  # the length of the windowing segments
Fs = int(1.0 / dt)  # the sampling frequency
fig, (ax1, ax2) = plt.subplots(nrows=2)
ax1.plot(t, x)

# now overwrite the setting to get the spectrogramm flipped
plt.rcParams["image.origin"] = 'lower'

Pxx, freqs, bins, im = ax2.specgram(x, NFFT=NFFT, Fs=Fs, noverlap=900)
plt.show()

Actual outcome

Flipping of the spectrogram without flipping the y-axis.

Expected outcome

Non-flipping independent of origin setting of imshow or specifically, "image.origin" of rcParams.

Matplotlib version

3.2.1
conda installation

Suggestion

Someone with the knowledge should add the keyword origin='upper' to the relevant imshow command of specgram.

@tacaswell
Copy link
Member

The semantics around extent / origin / the default extents is a bit complicated (see https://matplotlib.org/tutorials/intermediate/imshow_extent.html).

The relevant code for this is at

im = self.imshow(Z, cmap, extent=extent, vmin=vmin, vmax=vmax,
**kwargs)
I think it makes sense that if we are pinning the extent we should also pin the origin.

@tacaswell tacaswell added Good first issue Open a pull request against these issues if there are no active ones! Difficulty: Easy https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues labels Jul 11, 2020
@tacaswell tacaswell added this to the v3.4.0 milestone Jul 11, 2020
@tacaswell
Copy link
Member

The work here is to:

  • make sure that setting the origin the inner call to imshow in specgram is actually the correct fix
  • add a test (via check_figures_equal)
  • document a behavior change

@kate-perkins
Copy link
Contributor

I would like to work on this for the SciPy 2020 sprint.

@theodorju
Copy link
Contributor

I am also looking into this as part of the SciPy 2020 sprint.

@tacaswell
Copy link
Member

sorry for not being clear. What I mean by "pin" is "ensure that in spcegram we always pass origin='upper' to the underlying imshow call independent of what the rcparam is"

@thedorathanasiadis and I had a brief verbal discussion about this too (that I should have moved to this issue in text, sorry). that we have two ways to fix this:

  1. make origin='upper' work correctly for specgram and sort out how to change the ylimits etc and add origin as a kwarg to specgram. This we be adding a new feature that, given the context of specgram
  2. make specgram ignore the rcparam and prevent the user from passing in origin as a kwarg

I am inclined to option 2 (it is simpler and given that I think this has been broken forever no one is clamoring for this feature). Going with option 2 now does not prevent us from being able to do option 1 later, but if we go with option 1 now we can't go back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Difficulty: Easy https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues Good first issue Open a pull request against these issues if there are no active ones!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants