Menu
▾
▴
plplot-devel
|
From: Olof S. <sve...@es...> - 2002-01-08 09:20:24
|
Hi João, thanks for you answer! Now I understand better why you you need the pixel co-ordinates and I think your planned improvements of plimage sound great. I had a discussion with Alessandro this morning and we agreed on the following points: The best solution is probably to create a second entry point for passing an image as a PLFLT * pointer. There are two possibilities, either by using a flag telling plimage which type of pointer is passed (to avoid creation of unused arrays in the case of rectangular images) or by creating a new plplot image command. Concerning plxormod, I made some tests with the xwin and win3 devices and found that everything works fine unless you resize the window between two selections. What happens is that since plxormod is turning the plbuf_write off the selection rectangle is not redisplayed when resizing the window, and when you make a new selection the program (x20c) retraces the old rectangle and it becomes visible. (In fact, with the xwin device the resizing of the window makes the image disappear completely, however the old selection reappears as on the win3 device). Maybe it is not a very important problem, but for some applications that we plan to do in the future we would like to keep the possibility to keep the PLESC commands. Regards, Olof |
|
From: Joao C. <jc...@fe...> - 2002-01-08 18:56:20
|
On Tuesday 08 January 2002 9:22 am, Olof Svensson wrote: > Hi Jo=E3o, > > thanks for you answer! Now I understand better why you you need the > pixel co-ordinates and I think your planned improvements of plimage > sound great. I had a discussion with Alessandro this morning and we > agreed on the following points: > > The best solution is probably to create a second entry point for passin= g > an image as a PLFLT * pointer. There are two possibilities, either by > using a flag telling plimage which type of pointer is passed (to avoid > creation of unused arrays in the case of rectangular images) or by > creating a new plplot image command. Perhaps the latter will be more user understandable. It could just set a=20 variable in plstrm.h (that could be used also by drivers), and call the=20 standard plimage(). > Concerning plxormod, I made some tests with the xwin and win3 devices > and found that everything works fine unless you resize the window > between two selections. What happens is that since plxormod is turning > the plbuf_write off the selection rectangle is not redisplayed when > resizing the window, and when you make a new selection the program > (x20c) retraces the old rectangle and it becomes visible. (In fact, wit= h > the xwin device the resizing of the window makes the image disappear > completely, however the old selection reappears as on the win3 device). There are other resize/redraw issues in the new xwin plimage implementati= on.=20 The worse being that, as I now use XGetImage(), it fails if the plot wind= ow=20 is not completely visible! > Maybe it is not a very important problem, but for some applications tha= t > we plan to do in the future we would like to keep the possibility to > keep the PLESC commands. OK, but probably I will changes their names, as I found the current ones = too=20 cryptic. Jo=E3o > > Regards, > > Olof |
|
From: Olof S. <sve...@es...> - 2002-01-10 15:49:46
|
Joao Cardoso wrote: > > > The best solution is probably to create a second entry point for passing > > an image as a PLFLT * pointer. There are two possibilities, either by > > using a flag telling plimage which type of pointer is passed (to avoid > > creation of unused arrays in the case of rectangular images) or by > > creating a new plplot image command. > > Perhaps the latter will be more user understandable. It could just set a > variable in plstrm.h (that could be used also by drivers), and call the > standard plimage(). This sounds to us as a good idea - however, just a thought, since PLFLT * is used internally by plimage, wouldn't it be better to let the current version of plimage call the new function? (In fact, to be more compatible with PGPLOT the new function should be called plimage and the existing one should be renamed, however we have nothing against keeping the current version as plimage). Could you suggest a name for the new plimage function? > > Maybe it is not a very important problem, but for some applications that > > we plan to do in the future we would like to keep the possibility to > > keep the PLESC commands. > > OK, but probably I will changes their names, as I found the current ones too > cryptic. Fine with us! Regards, Olof |
|
From: Joao C. <jc...@fe...> - 2002-01-10 17:01:43
|
On Thursday 10 January 2002 3:49 pm, Olof Svensson wrote: > Joao Cardoso wrote: > > > The best solution is probably to create a second entry point for > > > passing an image as a PLFLT * pointer. There are two possibilities, > > > either by using a flag telling plimage which type of pointer is pas= sed > > > (to avoid creation of unused arrays in the case of rectangular imag= es) > > > or by creating a new plplot image command. > > > > Perhaps the latter will be more user understandable. It could just se= t a > > variable in plstrm.h (that could be used also by drivers), and call = the > > standard plimage(). > > This sounds to us as a good idea - however, just a thought, since > PLFLT * is used internally by plimage, wouldn't it be better to let the > current version of plimage call the new function? Yes, of course. > (In fact, to be more compatible with PGPLOT Is PLplot API compatible with PGPLOT? I didn't knew that. I knew that PLp= lot=20 start after, or was inspired by, PGPLOT. > the new function should be called plimage and the > existing one should be renamed, however we have nothing against keeping > the current version as plimage). Could you suggest a name for the new > plimage function? What about "plimage" for the new function and "plimagefe" (front end) for= the=20 current one? Or, if compatibility with PGPLOT is not mandatory, "plimages= "=20 (straight) for the new function? hum, this could be misleading, Pick your= own=20 names, I'm not concerned with that. Yesterday I though that plimage() structure was steady, but today I'm not= =20 certain of that. It looks like that it is not possible to save a displaye= d=20 image in another format, opening another device and replaying the plot=20 buffer. (Using the standard plmkstrm/plcpstrm/plreplot/plend1 way of savi= ng=20 plots). But the modifications should be minor, so you can start to code your=20 modifications and send a patch. Bye, Joao PS-Did you see the current know bugs of plimage, described in a comment i= n=20 x20c.c? |
|
From: Olof S. <sve...@es...> - 2002-01-11 16:42:45
|
Joao Cardoso wrote:
>
> What about "plimage" for the new function and "plimagefe" (front end) for the
> current one? Or, if compatibility with PGPLOT is not mandatory, "plimages"
> (straight) for the new function? hum, this could be misleading, Pick your own
> names, I'm not concerned with that.
How about calling the existing function "plgridimage" and the new
function "plimage"? You could even think of make it possible to pass
the list of co-ordinates for the pixels (however I have no idea
if this would be useful or not...):
plimage(PLFLT *idata, PLINT nx, PLINT ny,
PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax,
PLFLT Dxmin, PLFLT Dxmax, PLFLT Dymin, PLFLT Dymax)
plgridimage(PLFLT **idata, PLFLT *x, PLFLT *y, PLINT nx, PLINT ny,
PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax,
PLFLT Dxmin, PLFLT Dxmax, PLFLT Dymin, PLFLT Dymax)
> Yesterday I though that plimage() structure was steady, but today I'm not
> certain of that. It looks like that it is not possible to save a displayed
> image in another format, opening another device and replaying the plot
> buffer. (Using the standard plmkstrm/plcpstrm/plreplot/plend1 way of saving
> plots).
I noticed a problem when resizing a plot with several subplots
containing images - Alessandro and I solved this problem by saving
and restoring the Dxmin etc parameters in plbuf_image and rdbuf_image.
Here's the patch:
--- plplot/drivers/plbuf.c Thu Jan 10 06:39:36 2002
+++ plplot_new/drivers/plbuf.c Fri Jan 11 17:27:18 2002
@@ -230,6 +230,10 @@
fwrite(pls->dev_ix, sizeof(PLINT), (pls->dev_nptsX)*(pls->dev_nptsY), pls->plbufFile);
fwrite(pls->dev_iy, sizeof(PLINT), (pls->dev_nptsX)*(pls->dev_nptsY), pls->plbufFile);
fwrite(pls->dev_z, sizeof(PLFLT), (pls->dev_nptsX-1)*(pls->dev_nptsY-1), pls->plbufFile);
+ fwrite(&pls->Dxmin, sizeof(PLINT), 1, pls->plbufFile);
+ fwrite(&pls->Dxmax, sizeof(PLINT), 1, pls->plbufFile);
+ fwrite(&pls->Dymin, sizeof(PLINT), 1, pls->plbufFile);
+ fwrite(&pls->Dymax, sizeof(PLINT), 1, pls->plbufFile);
}
/*--------------------------------------------------------------------------*\
@@ -553,6 +557,11 @@
fread(dev_ix, sizeof(PLINT), npts, pls->plbufFile);
fread(dev_iy, sizeof(PLINT), npts, pls->plbufFile);
fread(dev_z, sizeof(PLFLT), (nptsX-1)*(nptsY-1), pls->plbufFile);
+
+ fread(&pls->Dxmin, sizeof(PLINT), 1, pls->plbufFile);
+ fread(&pls->Dxmax, sizeof(PLINT), 1, pls->plbufFile);
+ fread(&pls->Dymin, sizeof(PLINT), 1, pls->plbufFile);
+ fread(&pls->Dymax, sizeof(PLINT), 1, pls->plbufFile);
plP_image(dev_ix, dev_iy, dev_z, nptsX, nptsY);
Maybe the problem you site above can be solved by the same patch.
> But the modifications should be minor, so you can start to code your
> modifications and send a patch.
Ok, if you agree on the naming and argument scheme above I'll start making a patch.
> PS-Did you see the current know bugs of plimage, described in a comment in
> x20c.c?
Well, (* blush *) I must admit that I read the code of x20c but skipped the
comments (like a compiler). I'll look more carefully on the comments next time!
Regards,
Olof
|
|
From: Joao C. <jc...@fe...> - 2002-01-11 20:52:20
|
On Friday 11 January 2002 4:42 pm, Olof Svensson wrote: > Joao Cardoso wrote: > > What about "plimage" for the new function and "plimagefe" (front end)= for > > the current one? Or, if compatibility with PGPLOT is not mandatory, > > "plimages" (straight) for the new function? hum, this could be > > misleading, Pick your own names, I'm not concerned with that. > > How about calling the existing function "plgridimage" and the new > function "plimage"? You could even think of make it possible to pass > the list of co-ordinates for the pixels (however I have no idea > if this would be useful or not...): Neither me. I would be nice if all 2D plplot functions have the same interface, but o= nly=20 c_plmesh(PLFLT *x, PLFLT *y, PLFLT **z, PLINT nx, PLINT ny, PLINT opt) takes this approach. Neither plcont() nor plshade() , nor PGPLOT cpgima() (void cpgimag(const float *a, int idim, int jdim, int i1, int i2, int = j1, int j2, float a1, float a2, const float *tr)), does, so lets keep the current definition. > plimage(PLFLT *idata, PLINT nx, PLINT ny, > PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax, > PLFLT Dxmin, PLFLT Dxmax, PLFLT Dymin, PLFLT Dymax) > > plgridimage(PLFLT **idata, PLFLT *x, PLFLT *y, PLINT nx, PLINT ny, > PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax, > PLFLT Dxmin, PLFLT Dxmax, PLFLT Dymin, PLFLT Dymax) OK, as you at sfr.fr start it, you have the right to choose :). You use=20 plimage(PLFLT *data, ...) and I will use plimage1(PLFLT **z, ...). > > Yesterday I though that plimage() structure was steady, but today I'm= not > > certain of that. It looks like that it is not possible to save a > > displayed image in another format, opening another device and replayi= ng > > the plot buffer. (Using the standard plmkstrm/plcpstrm/plreplot/plend= 1 > > way of saving plots). > > I noticed a problem when resizing a plot with several subplots > containing images I have just now tried it using the current CVS version, and detected no=20 problem... > - Alessandro and I solved this problem by saving > and restoring the Dxmin etc parameters in plbuf_image and rdbuf_image. I can't see how this patch could correct it, as Dxmin etc are not anymore= in=20 the pls structure... you have been mixing versions. =2E.. > Maybe the problem you site above can be solved by the same patch. No, the solution to "my" problem is to change the block=20 if( plsc->dev_fastimg =3D=3D 0) { from plimage() to plP_image(), so that when replaying the plot buffer it = will=20 be replayed to the other device, even if it is a "slow" one. =2E.. > > But the modifications should be minor, so you can start to code your > > modifications and send a patch. > > Ok, if you agree on the naming and argument scheme above I'll start mak= ing > a patch. Lets wait till I move the "if( plsc->dev_fastimg =3D=3D 0) {" block fro= m=20 limage() to plP_image(), OK? I must admit that I'm not in the mood for this, but I will make a try=20 tomorrow. Thanks, Joao |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X