Slow plotting of spectrogram

[Uwe]

Is it possible to do not lose these single maximums on the spectrogram?

This is a problem of the nearest neighbor resampling. It is very fast, but of course might miss peaks.

QwtPlotMatrixData offers another resampling algo - interpolating between the samples - but it might be too expensive for your use case and you lose the pixel hint optimization. Guess you need to find your own strategy, but in any case you would have to overload:

virtual double QwtRasterData::value( double x, double y );

virtual double QwtRasterData::value( double x, double y );

To copy to clipboard, switch view to plain text mode 

But be careful: this method is called for each pixel of the image. Doing expensive operations here will slow down the image composition.

Uwe

[Anton1]

Hello!

After I changed the display to the one with higher resolution (1920 Ñ… 1080) the spectrogram slowed down.

So now I'd like to return to the approach you suggesed erlier "Incremental image composition". Do I understand it right that it is possible to plot only part of the spectrogram OR to add data to the spectrogram?

I looked at the topic "Incremental Spectrogram".
I do not understand how to properly reimplement method QwtPlotSpectrogram::renderImage.

For example, I have a spectrogram, filling from left to right by columns. I want to render only new part of the picture (Today for display I use overloading method QwtRasterData::value and replot all picture).
1. What triggers the method QwtPlotSpectrogram::renderImage? Repaint, replot etc.? Or do I need to call it myself?
2. How to set the return value in an overloaded method?
3. Do I need an analog for method QwtRasterData::value,that i used when call replot?
4. Can you provide a brief description of how to make incremental spectrogram data plotting?

Thank you in advance.

[Uwe]

The very first thing I recommend to do is - again - enable DEBUG_RENDER in qwt_plot_spectrogram.cpp and check the time needed for your image composition.
What type of values have been reported ( of course in release mode ) ?

Uwe

[Anton1]

I set enable DEBUG_RENDER in qwt_plot_spectrogram.cpp.
If the spectrogram takes nearly full screen, there is the following result - renderImage QSize(1818, 909) 179
If the spectrogram takes small part of screen, there is the following result - renderImage QSize(705, 80) 11
Initial screen resolution is 1920x1080. The data size exceeds the size of the spectrogram.
Can you say what should be done?
Thank you in advance.

[Uwe]

QSize(1818, 909) 179
QSize(705, 80) 11

With the spectrogram example I can see on my box ( i7-3770T CPU @ 2.50GHz with 4 cores ) values like:

• QSize(484, 343) 3
• QSize(1804, 1075) 27

As my system is far away from being a burner I guess we are talking about some slow embedded device on your side ?
To compare the systems: could you check the numbers of the spectrogram example on your box ?

--

Concerning the "Incremental image composition":

class YourSpectrogram: public QwtPlotSpectrogram
{
    ....
 
protected:
    virtual QImage renderImage(
        const QwtScaleMap &xMap, const QwtScaleMap &yMap,
        const QRectF &area, const QSize &imageSize ) const override
    {
        if ( m_image.isNull() )
        {
            m_image = QwtPlotSpectrogram::renderImage(
                xMap, yMap, area, imageSize );
        }
        else
        {
            // find the new area, not being part of the previous image
            // and the width/height in pixels
 
            subArea = ...;
            subImageSize = ...
 
            QImage subImage = QwtPlotSpectrogram::renderImage(
                xMap, yMap, subArea, subImageSize );
 
            // shift the pixels in m_image and copy in those from subImage
            m_image = ...
        }
 
        return m_image;
    }
 
private:
    QImage m_image;
};

class YourSpectrogram: public QwtPlotSpectrogram
{
    ....

protected:
    virtual QImage renderImage(
        const QwtScaleMap &xMap, const QwtScaleMap &yMap,
        const QRectF &area, const QSize &imageSize ) const override
    {
        if ( m_image.isNull() )
        {
            m_image = QwtPlotSpectrogram::renderImage(
                xMap, yMap, area, imageSize );
        }
        else
        {
            // find the new area, not being part of the previous image
            // and the width/height in pixels

            subArea = ...;
            subImageSize = ...

            QImage subImage = QwtPlotSpectrogram::renderImage(
                xMap, yMap, subArea, subImageSize );

            // shift the pixels in m_image and copy in those from subImage
            m_image = ...
        }

        return m_image;
    }

private:
    QImage m_image;
};

To copy to clipboard, switch view to plain text mode 

HTH,
Uwe

PS: if you have a good example for a waterfall plot that could be used as an example ( no huge data files ) you could send me your slow implementation. I would do the optimized implementation then.

[Anton1]

Hello Uwe!
In the spectrogram example I see values like: renderImage QSize(1745, 910) 36.
My computer have parameters i7-3770 CPU @ 3.40GHz with 4 cores.
I'm working on a model for a waterfall plot, I think that I can send it to you early next week.
Thank you in advance.

[Anton1]

Good day, Uwe.
I've done program that could be an example after some changes.
I give a link to the archive: https://cloud.mail.ru/public/LPcx/a7VbvrFGx
Now the program is running slowly, but I hope that it is possible to optimize.
Thank you in advance.

[Uwe]

Not sure what this tarball is supposed to be - looks like some downstripped version of your application, but without doing anything. To be honest I was interested in some simple data factory, that can be used for a waterfall plot - and this part is unfortunately missing.

But at least it shows the implementation of your SpectrogramData::value(), that explains why you have a worse image composition performance than the spectrogram example. Regardless of any further optimization I recommend to speed this one up. As it is called for every pixel it is worth to spend some time on writing it in a performant way.

Uwe