Hi Jeremy, This would be a very useful new feature! I haven't though a lot about this, but specifying the edge values would be the most useful to me. I sometimes need to plot 2D histogram data, and I already have the edges of each bin. The color of the pixel would then correspond to the number of points in that particular 2D bin.
As to how to compute the center, I think all you could do is assume the center is in the middle. If the user wants log-spaced data, then they can pre-compute the log values, and specify those as the bin edges. They could then put custom labels on the axis if they want it to look like a log plot. Does this make sense? So the pylab module in matplotlib has a class for plotting nonuniform images. (See http://matplotlib.org/examples/pylab_examples/image_nonuniform.html) It works by specifying the centers. I'm not sure how it computes the edges (or pixel widths). I'd be happy to do some beta testing of this feature once it is working. I'm looking forward to seeing it in a future version of Veusz. Steve On Sun, Dec 1, 2013 at 12:07 PM, Jeremy Sanders <jer...@jeremysanders.net>wrote: > 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 > Veuszemail@example.com > https://mail.gna.org/listinfo/veusz-discuss >
_______________________________________________ Veusz-discuss mailing list Veuszfirstname.lastname@example.org https://mail.gna.org/listinfo/veusz-discuss