I've written some code which didn't make it into 1.19/1.19.1, designed
to make 2D datasets more general. The idea is to allow a more general
dataset where the y and x steps can vary to give different sized
"pixels". This is really useful if your data are logarithimically
defined, etc.
The current implementation is that the user provides "edges" where the
pixels start and stop (the next starts where the previous stops). The
user provides a list of x and y values which contain 1+number of values
in that direction.
This seemed to be reasonable and is a good fit for "image" type widgets,
where the edge of the image needs to be properly defined. However, there
some issues:
1. The contour widget needs to know where the pixel centres are. If you
have the edges, you need to assume that the centre is in the middle.
This might not be the case for log-stepped data (it's hard to do a log
centre as the widget doesn't really know whether it is log or not).
2. I was investigating making the CSV import able to read 2D data. You
might want to have data like this, where the first row and first column
are x and y values.
1, 10, 100,1000,10000
0, 1, 2, 3, 4, 5
1, 2, 4, 5, 6, 3
3, 3, 1, 0, 2, 3
This again has the issue that the centres are what are defined and not
the edges.
Are pixel centres or edges the right way to describe 2D data? Centres
seem better for contours, edges for images. Should veusz support both
kinds of data? If centres are given, how do we calculate edges, and
vice-versa?
Jeremy
_______________________________________________
Veusz-discuss mailing list
Veusz-discuss@gna.org
https://mail.gna.org/listinfo/veusz-discuss
