Skip to content

Compute the Gabor spectrogram in one place #18

Open

Description

@jtravs

What is wrong

croak computes a Gabor spectrogram in two places with different choices:

  • croak.processing.spectrogram(result, ...) — the retrieval and dispersion views: the gate centres span half the time window, the gate is a twentieth of the window wide (FWHM), on a RetrievalResult only;
  • the synthetic generator's preview, now croak.plotting.screen._gabor — gate centres over the pulse with a 30 % margin, a Gaussian σ of a thirtieth of that span (at least four samples), on any field.

Why it matters

Two implementations of one quantity drift apart, and the generator's version is not reachable from scripts. A single function that takes a field (grid, spectrum, ω₀) with the gate and window as explicit, documented choices would serve both, with processing.spectrogram(result) as a thin wrapper.

What done looks like

One spectrogram function on a field, tested against an analytic case (a linearly chirped Gaussian, whose spectrogram ridge has a known slope), used by both callers; the generator's preview unchanged in what it shows (zoomed to the pulse).

Context

Noticed while moving the generator's preview to the screen-data layer in #16, which kept its computation as it was to stay in scope. Read, not run.

Suggested labels: refactor, area: gui, priority: low.

Activity

  1. added
    refactorInternal restructuring with no change in behaviour
    on Nov 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: guiThe Qt wizardpriority: lowWorth doing, no hurryrefactorInternal restructuring with no change in behaviour

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions