On Monday 07 January 2002 2:58 pm, Olof Svensson wrote:
> Hi Jo=E3o,
> I have started to work on making the Windows plplot device win3 a fast
> image device. I can now run the x20c example on Windows and the device
> is fast. However, before sending Alan the patch I'd like to make a
> couple of suggestions for plimage. I have discussed these suggestions
> with Alessandro and he have no objections.
> My primary concern about the current implementation of plimage is use o=
> memory. Here at the ESRF we would like to use plimage to plot relativel=
> large images, i.e. up to 2000 x 2000 pixels. One can do this with the
> current implementation however it uses a lot of memory and the bufferin=
> of the image takes quite some time. In order to solve this problem I
> have the following two suggestions:
> 1. I'd like to remove the two arrays containing the X and Y co-ordinate=
> for every pixel. From what I can see in the code these arrays are not
> yet used - please correct me if I'm wrong.
Yes, they are not yet used, but they will be used when making rotations. =
matter of fact I'm ready to commit changes to plimage/plcore/xwin that=20
implement rotations and translations. I'm hesitating, as the solution is =
100% correct for all situations. And, as you say bellow, this could be ma=
by another function.
> If I understood Alessandro
> right the idea was that these arrays could be used to plot 2D data that
> were not on a regular grid.
That is on my todo list: a plgrid() function that receives irregularly=20
sampled data and returns grided data.
> I understand that this is desirable in some
> circumstances, I have myself worked with correcting 2D detector data fo=
> spatial distortion. However, I think it is wrong to delegate this task
> to plimage. I believe that it is better to have this code outside
> plimage, e.g. to have a function that accepts as arguments the image an=
> the co-ordinates for each pixel and then creates a new image which can
> be sent to plimage.
I agree, but that is the standard way of PLplot to do it.
> 2. I'd also like to go back to having the possibility of sending an
> image as a PLFLT * instead as a PLFLT **. I understand that it is easy
> to handle 2D data with plplot in the PLFLT ** format. However, large
> images are most conveniently stored as PLFLT * in C. Using a PLFLT *
> pointer has the advantage that it can be passed directly to a fast imag=
> device, thus avoiding allocating memory. This pointer could also be
> saved by plbuf_image instead of saving the whole image. (A solution
> could be to add a new plimage function in plplot. The "old" plimage
> could still be used with the PLFLT ** argument. The "new" plimage could
> accept a PLFLT * argument and not allocate any extra memory, except
> needed by the fast image device.)
> What do you think?
I think that it is OK to have an alternate API entry point to plimage() t=
uses PLFLT*. As a matter of fact plimage() alreay uses it internally.
As for the X/Y arrays I'm not sure what the better solution is; I have al=
considered to use a row/column vector to store the pixels coordinates, bu=
abandomned it when implementing rotations.
As for your large 2000x2000 images, it could be possible to accelerate th=
driver, not performing fills and just ploting the point. But at 100dpi yo=
need a 20x20 inch monitor to display the image, so some kind of=20
under-sampling will be necessary, I think.
To Alessandro: have you managed to use plxormod(), so I can drop the=20
To the list: should we consider plimage() so specific to not implement=20
difilt() rotations/translations on it? Remember that plimage() can be use=
place of plshade() for big arrays.
> Plplot-devel mailing list