Re: [Plplot-devel] plimage

[Joao C. <jc...@fe...>]

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=
f
> memory. Here at the ESRF we would like to use plimage to plot relativel=
y
> 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=
g
> 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=
s
> 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. =
As a=20
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 =
not=20
100% correct for all situations. And, as you say bellow, this could be ma=
de=20
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=
r
> 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=
d
> 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=
e
> 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=
hat=20
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=
so=20
considered to use a row/column vector to store the pixels coordinates, bu=
t=20
abandomned it when implementing rotations.

As for your large 2000x2000 images, it could be possible to accelerate th=
e=20
driver, not performing fills and just ploting the point. But at 100dpi yo=
u=20
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
PLESC_IMAGEOPS?

To the list: should we consider plimage() so specific to not implement=20
difilt() rotations/translations on it? Remember that plimage() can be use=
d in=20
place of plshade() for big arrays.

Joao

>
> Regards,
>
> Olof
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel