Change in color map?

[Uwe]

Now, Qwt wants to take ownership of the color map and I lost my control over the colors, etc. after I set the colormap.

These clone/copy methods of Qwt 5.x were a major source for user problems. That's why I have removed most of them and pass pointers instead - like everyone is used to from the Qt API. But why is this a problem if you want to manipulate the color map from application code ?

Uwe

PS: Right now I'm working to improve the accurancy of the raster item class and to introduce an additional type of raster data for values stored in a matrix. So don't be surpised to find undocumented APIs and ongoing changes.

[bigjoeystud]

These clone/copy methods of Qwt 5.x were a major source for user problems. That's why I have removed most of them and pass pointers instead - like everyone is used to from the Qt API. But why is this a problem if you want to manipulate the color map from application code ?

I have a class which is defined like so:

class ImageData: public QObject, public QwtRasterData
{
...
private:

// We store pointers to a value to use for the color bar
// We need this instead of member variable so that the interactive color bar works

double *_colorMin;
double *_colorMax;
FuncPtr *_colorBarModifier;
};

My GUI changes the values of those pointers.

QwtPlotSpectrogram *spectrogram = new QwtPlotSpectrogram ();
spectrogram->setColorMap (new TransparentLinearColorMap (_colorMap));
spectrogram->setData (image);

image is of type ImageData which is derived from QwtRasterData. _colorMap was connected to the same values of the the min/max. Thus, when the GUI is up and the user is interacting with the color bar and Qwt replots; it is using the current value of those pointers.

Why this no longer works is I have to do this:
spectrogram->setColorMap (new TransparentLinearColorMap (_colorMap));
instead of my previous "spectrogram->setColorMap (_colorMap);" which would make the spectrogram use the same colorMap that the interactive GUI was using. In other words, since spectrogram owns the new'ed colorMap, my GUI is no longer interacting with the right one.

I hope that all makes sense! Anyway, I'm not saying this is the best way of doing this, but maybe I'm missing something easy on either fixing this or a better design?

PS: Right now I'm working to improve the accurancy of the raster item class and to introduce an additional type of raster data for values stored in a matrix. So don't be surpised to find undocumented APIs and ongoing changes.

I look forward to this! Especially if we can have multi-dimensional matrices and easy ways of slicing them.

Joey

[Uwe]

Why this no longer works is I have to do this:
spectrogram->setColorMap (new TransparentLinearColorMap (_colorMap));
instead of my previous "spectrogram->setColorMap (_colorMap);" which would make the spectrogram use the same colorMap that the interactive GUI was using. In other words, since spectrogram owns the new'ed colorMap, my GUI is no longer interacting with the right one.

What about changing your code, so that _colorMap becomes a pointer allocated by new. Then there will be no copy ( in the meantime I have disabled the copy constructor ! ) and you can maniuplate the one and only color map from application code. Note that you have to reassign the color map after changes to disable the internal image cache and trigger the optional auto replot ( of course you can do this manually as well ).

All you have to take care of is, that the color map will be deleted by the destructor of the spectrogram. So it might be better to use the getter of the spectrogram object instead of an additional pointer.

... multi-dimensional matrices and easy ways of slicing them.

In the meantime I have checked in a first version of this class. The new rasterview example shows how to use it. The implementation is not complete, not tested for printing and there are still some 1 pixel alignment errors left. Also the documentation is not yet done, but you can check the code of the rasterview example to see if this would be something for your situation.

Comments are welcome,
Uwe