@NilsNemitz you most recently worked in this area, you have time to take a closer look at this PR?

Hi @StSav012 ,
sorry for not getting around to looking at this, I have been busy with non-programming projects and did not want to create confusion with comments I won't have time to follow up on.

But there's a chance I can take a closer look over the weekend.

Until then, could you remind me why you think rebuilding the definitions of the internal data structures and interfaces is the most helpful approach here?

If I remember correctly, we have the data in various steps of processing available in the internal structures

self._dataset        = None # will hold a PlotDataset for the original data
self._datasetMapped  = None # will hold a PlotDataset for data after mapping transforms (e.g. log scale)
self._datasetDisplay = None # will hold a PlotDataset for data downsampled and limited for display

It seems to me, that if the exporter wants to have the original data, then it could just get self._dataset from PlotDataItem.
What am I missing?

Hi @NilsNemitz,

These days I don't have much time either. @j9ac9k, I'll answer in other threads later.

Well, the problem I recently faced was the following. If I set log mode and save the data via the Export action of the context menu, then the values I see in the file are not what I see in the plot. Namely, they are log10 of what should be according to the axes labels. I don't mind if you resolve the discrepancy another way.

As for self._dataset, it's a protected member, so I wouldn't appeal to it at all.

I think we'll need to change something,though, if we want the exporter to access that data. And I tend to agree that we do want that :)

The reason for the separation between the mapped and the displayed datasets is that the "mapping" (where we currently only have log10) needs to be calculated only once, but the displayed dataset also depends on the current viewport, and potentially needs to be rebuilt on every zoom or scroll. And it seems wasteful to repeat the expensive log calculations every time.

I think it might be simpler to either add the missing interfaces to the raw data, or to have the exporter take some liberties with the private/public boundaries.

I might prefer adding a method to grab the raw/original data, and then to change the exporter to access that.

There are then two open questions that I could see as requiring a little thought:

• Do we want to commit to keeping the original data around? That seems to be the main cost for adding a public interface to it. There were some proposed speed-ups that involved direct conversion of data to Qt paths, never keeping the raw data around. -- But in my opinion, PlotDataItem should remember the data; it is right there in the name,
• Can the raw data export just silently replace the current mapped data export? Or does it need to be a separate option? Are there any other elements (e.g. PlotCurveItem, ScatterPlotItem) that would (inconsitently) still report their mapped coordinates ?

Thank you for the explanation. I wish the names were more self-explanatory.

Do we want to commit to keeping the original data around?

I don't see another way.

Can the raw data export just silently replace the current mapped data export?

To my mind, the only option should be is to export the raw data. The mapped data are of no use to virtually anyone.

 Are there any other elements (e.g. PlotCurveItem, ScatterPlotItem) that would (inconsitently) still report their mapped coordinates?

As far as I have checked, no other *Item changes its data when set to log mode.

It looks like this can be closed now with #2238

Thanks for bringing this up and proposing a fix @StSav012