plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Wish list for the release

[Joao C. <jca...@in...>]

On Tuesday 11 December 2001 23:50, Alan W. Irwin wrote:
| I haven't been able to spend as much time as I wanted to on Plplot so t=
here
| is still a lot for me to do before the release.  Thus, I am backing awa=
y
| from a release within a few days.  I won't put it off for a long time, =
but
| this should give all of you a chance to do a bit more before the releas=
e.
|
| Here is my wish list for the release.  Feel free to modify it, but let'=
s

=2E..

| (9) Get command-line parameter parsing to work for octave x examples.
| (Joao).  This is needed so that, for example, the -fam and -fnum parame=
ters
| work for the drivers that require familying, but it would also be nice =
to
| see this work for all parameters (like it does for the p octave example=
s).


I can try this, but now I'm too busy.

=2E..
| (12) IMO, the most egregious bug for the plplot library shows up for x0=
8c
| with the non-smooth edges (missing triangles) to the hidden parts of th=
e
| plot for pages 5 through 8 (the 3D shade plot demonstration). If a C ex=
pert
| here is wondering how they can chip in, it would be *wonderful* to fina=
lly
| get rid of this bug.


Yes, this worries me too, but it is not a matter of C expertise. I think =
that=20
Geoffrey has already tried to correct it, and if I remember correctly he =
said=20
"better to write it from the begining"
|
| (13) dynamic tk and xwin driver.  (probably Joao).  My impression from
| commented out parts of the code that I reviewed for the cgm driver is t=
his
| might be ready to go now that we understand exactly what is required in
| the gd and cgm cases.  Every dynamic driver requires a link to libplplo=
t
| and some require additional links to their own special libraries.  Woul=
dn't
| those special libraries just be the Tk library for the tk driver and th=
e X
| libraries for the xwin driver?


The xwin and tk drivers can't be made dynamic.

There is no problem with the xwin driver alone, but the tk driver (either=
=20
static or dynamic) won't work with a dynamic xwin driver. The tk driver n=
eeds=20
some functions that are in the xwin driver.

The only solution, which is not elegant, would be to link tk.o and xwin.o=
 to=20
make tk.drv.

| (14) Joao also mentioned in his last e-mail that he wanted to play with
| plimage a bit more.


Yes, but I had not the time.

| I have probably forgotten some things so feel free to add to this list =
so
| long as the project is reasonably short (a few days or less).


This is an issue that worries me. You make a beatifull job testing plplot=
=20
regularly, and you post your conclusions/bugs/requests. But we might be b=
usy=20
at the time, and your conclusions/requests becomes lost. I always archive=
=20
your testing requests for latter usage, but most of the time I just forgo=
t to=20
use them.

I think that we should start using some mechanism to correct this. A=20
possibility will be using the "tasks manager",=20
http://sourceforge.net/pm/?group_id=3D2915 , creating an entry for each d=
river=20
and language binding. What do you think?

Joao

[Plplot-devel] for the wish list

[Alessandro M. <ale...@wa...>]

Hi all,
 I have posted a patch on sf.net containing my answer
to the wishes for pyqtplplot :
  - page control has been implemented through the very powerful
    signal and slot mechanism :
        before processing the example-string,
        the occurrences of pladv in this string are replaced by
"controlobject.waitRelease()".
        It is a method that loops with the mainloop.
        Then a connection between a PYSIGNAL that is emitted when the
        right button is pressed in the plplot widget and the method
controlobject.release()
        lets you pass to the following example with a click.
  - debugging messages have been removed

For Alan:
 The __attr method that is now commented was used in order to
manipolated plplot widget as if they were object:
   if plw is a qplplot widget , the call to plw.line() was wrapped by
method __getattr__. 
 The plline was stored in self.__attr and called later by the returned
wrap method.

I also have a small wish list :
 I would like to do all interactive processing using qt facilities. To
do this I would like
 to bypass the gin.x, gin.y mechanism by intercepting event in the
eventFilter.
 So I need a method ( that I could eventually export to python) that
given (x,y)
 in the device coordinates ( those known by qt) return me the
coordinates of the point
  Can somebody suggest me the best method to do this?

best wishes
    Alessandro Mirone

[Plplot-devel] Wish list for the release

[Alan W. I. <ir...@be...>]

I haven't been able to spend as much time as I wanted to on Plplot so there
is still a lot for me to do before the release.  Thus, I am backing away
from a release within a few days.  I won't put it off for a long time, but
this should give all of you a chance to do a bit more before the release.

Here is my wish list for the release.  Feel free to modify it, but let's
take as read that none of us really has a lot of time right now so I would
prefer you not waste too many key strokes on that topic....;-) Just do what
you can from this list of possibilities below the line when you can squeeze
it in.  The topics above the line are my responsibility.

(1) Solve the python 2.1 segfault bug for example 9.  Probably release
critical.

(2) Get documentation to build on my new Debian system.  Release critical.

(3) Document what I did recently for the cgm driver configuration.
Hopefully, this will be the start of a new cookbook for the dynamic drivers.

(4) Finish python examples and modify them to be exact replicas of the
C examples as a consistency check on the python front end.

(4a) Do the same for the tcl examples.

(5) gdimage extended example including all the things to make a colour image
work.

(6) Finish Java examples (with commented out API when that is not available).

Everything above this line is my responsibility.  Everything below is someone
else's responsibility, but I am willing to help with testing.
****************************************

(7) Perfect cgm driver (Andrew).

(8) Finish W2000 changes (except for contemplated win driver changes
which will take considerably longer) (Olof).

(9) Get command-line parameter parsing to work for octave x examples.
(Joao).  This is needed so that, for example, the -fam and -fnum parameters
work for the drivers that require familying, but it would also be nice to
see this work for all parameters (like it does for the p octave examples).

(10) Java API (Geoffrey, once I get some more examples ready for him).

(11) Some refinement of the pyqt GUI.  (Allesandro).  In particular I would
like to see the debugging messages disappear, and some paging scheme (have a
look at the ntk GUI or the gnome GUI for examples of this, although probably
something even better could be done). I am sure Allesandro has additional
things in mind as well.

(12) IMO, the most egregious bug for the plplot library shows up for x08c
with the non-smooth edges (missing triangles) to the hidden parts of the
plot for pages 5 through 8 (the 3D shade plot demonstration). If a C expert
here is wondering how they can chip in, it would be *wonderful* to finally
get rid of this bug.

(13) dynamic tk and xwin driver.  (probably Joao).  My impression from
commented out parts of the code that I reviewed for the cgm driver is this
might be ready to go now that we understand exactly what is required in
the gd and cgm cases.  Every dynamic driver requires a link to libplplot and
some require additional links to their own special libraries.  Wouldn't those
special libraries just be the Tk library for the tk driver and the X libraries
for the xwin driver?

(14) Joao also mentioned in his last e-mail that he wanted to play with
plimage a bit more.

I have probably forgotten some things so feel free to add to this list so
long as the project is reasonably short (a few days or less).  I don't view
anything except the first two as release critical, but I did want to write
down these works in progress and other short project possibilities to focus
our efforts before the release.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] New cgm driver

[Andrew R. <ar...@ge...>]

>These test results did indicate some colour problems. For example for the
>5th page of x08c there were lots of error messages about:
>
>Problem setting cmap1 in CGM driver
>Problem setting cmap0 in CGM driver.
>
>Also, the gray shading on the 3D shaded plot result seems to be more
>non-uniform (more missing triangles) than usual.  I assume it has something
>to do with the large number of different grey scales in this example.

Actually, I think it has to do with the fact there is no "black" background
yet.

>Andrew, will you try x08c -dev cgm -fam on your system to see if you get the
>same errors for the fifth page?

Yes, I am still to look into that. The PNG driver also trips those errors
for what it is worth, but silently. I don't think it effects the results
though.

>I also noticed background colour problems.

The problem stems from the fact that with CGM files, there is no background
colour as such. It is sort of treated like plotter in effect. Whatever the
background colour on the default viewer is will be the background colour.
There is work-around for this I believe will fix the problem. Basically you
have to put a rectangle of the desired background colour down before you
start any drawing. I will add that feature in my next update.

[Plplot-devel] New cgm driver

[Alan W. I. <ir...@be...>]

Andrew has recently contributed a cgm driver to plplot.  Frankly, I had
never heard of cgm so I checked it out with google and apparently that
graphics format is used quite a bit by the military and in the oil
business.  Also, it is a vector format rather than bitmapped.  Thus,
for those two reasons I am glad he added this capability to plplot.

The downside of the cgm format is its weak support under Linux.  (Wild
speculation: perhaps the "throw-money-at-it" style of software development
for oil businesses and the military reduced or delayed the pressure to
develop free software that works with the cgm format.) Andrew did manage to
find libcd (see cgm.c for a reference), an unmaintained but working free
library upon which he based his driver.  (This is also available from the
cgmdraw rpm from SuSe, and to be absolutely sure this library does not
disappear on us, I have put a copy of the tarball into our file release
area.)

Another aspect of the weak support for cgm under Linux is the lack of tools
to display cgm results. The only free package I could find to do this is
ralcgm.  Again, this package is unmaintained. Furthermore, in its raw (1995)
form it does not configure under Linux. Fortunately, I was able to get a
linux patch by deconstructing a Linux source rpm that has been made of this
package.  With that patch applied and one workaround, ralcgm configured and
built on Linux.  If anybody else here wants to use this package to view the
cgm results, I can give you the necessary cookbook to make it work.

I have just now put changes into cvs so that Andrew's cgm driver can be built
either dynamically or statically under Linux.  I have run plplot-test.sh
with the cgm driver both for the dynamic and static version of the cgm
driver, and there are no segfaults or other fatal errors.  Furthermore,
identical files are produced in both cases.

These test results did indicate some colour problems. For example for the
5th page of x08c there were lots of error messages about:

Problem setting cmap1 in CGM driver
Problem setting cmap0 in CGM driver.

Also, the gray shading on the 3D shaded plot result seems to be more
non-uniform (more missing triangles) than usual.  I assume it has something
to do with the large number of different grey scales in this example.
Andrew, will you try x08c -dev cgm -fam on your system to see if you get the
same errors for the fifth page?

I also noticed background colour problems.  The X driver output from ralcgm
was OK (i.e., had the black background), but the postscript results from
ralcgm had a white background.  I looked further into this with the
particularly simple x02c example.  I used ralcgm to produce a clear text
version of the x02c cgm, and that had no mention of background colour or
filling.  Andrew, if you have tools to convert from cgm to other formats
such as the clear text version of cgm or postscript, I would appreciate your
confirmation of this problem.  I notice you have done something special with
the background colours in cgm.c, and there may be some logic you need to
change there.

Once these colour problems are sorted out, I should be able to look a bit
closer at the remaining large number of results produced by plplot-test.sh
for the cgm driver.  But so far it looks promising (i.e., no segfaults which
is a big plus as far as I am concerned!)

Andrew, please give my changes a try (if they have any affect in your
environment) and also please run the bug confirmations I have asked for.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Help with plD_dispatch_init_win3 needed

[Geoffrey F. <fu...@ga...>]

Joao Cardoso writes:
 > | From plcore.h, I find that the old seq # for the win3 driver was 10.
 > | I would preserve that one on the assumption that it made sense, unless
 > | you have a particular reason to push it down the stack.  In general I
 > | think the rule is to get the sequence number of the drivers ordered so
 > | that the default interactive driver for each platfrom will be the top
 > | one listed in the display.  Dunno if that's strictly possible since
 > | there are numerous possible interactive drivers on some platforms, and
 > | whose to say which one is the best default, but that's at least the
 > | general idea.
 > 
 > This implies that the most recent drivers should appear after the old ones, 
 > for a given platform, preserving the order that users are used to. The gnome 
 > driver violates this, as it appears before the tk driver, which is older. 
 > This has always puzzled me, but I didn't change it, as I thought that the 
 > question had already been discussed.

Yes, I noticed that too.  It was not discussed that I know of.
However, I don't feel strongly about it.  I usually just type "tk",
since xwin is the top choice, and you have to type /something/ if you
want other than xwin.  So because of this, the order isn't
extraordinarily important.  Changing xwin to not be the default top
choice on Unix, would raise my eyebrows.

I think the way to go after this, would be to formalize the concept of
the driver sequence registry, and write some documentation for it.
Without such effort, we are just winging it, and that is okay with me
since we have plenty to attend to that is of genuinely higher
priority. 

 > |  The file oriented drivers show up lower on the list.
 > |
 > | The master registry of seq numbers is not at all clear right now,
 > | sorry.  We should somehow formalize this better.  Maybe an enum for
 > | the driver sequencing id defined somewhere, I'm not sure what's best.
 > | Anyway, there's an "#if 0/#endif" block in plcore.h, which I left
 > | there so we can refer to it as we update all the driver code.  Someday
 > | that should be summarily expunged, but I think someone should dump a
 > | little effort into formalizing the device sequencing registry before
 > | we take that final step.
 > |
 > | I am not volunteering, so if anyone is inclined, go ahead.

Re: [Plplot-devel] Help with plD_dispatch_init_win3 needed

[Joao C. <jca...@in...>]

On Friday 07 December 2001 16:19, Geoffrey Furnish wrote:
| Olof Svensson writes:
|  > Hi plplot developers,
|  >
|  > as you have noticed I'm working on getting the Win32 port of plplot
|  > working again. I noticed that since the 5.0.4 release a new function=
 is
|  > needed for the win3 device, i.e. the "plD_dispatch_init_win3" functi=
on.
|  > I copied the one I found in "ps.c" and I got the win3 device working
|  > however I have no idea if I'm using the correct values:
|  >
|  > win3_dispatch_init_helper( pdt,
|  >                            "PlPlot Win32 Window",
|  >                            "win3",
|  >                            plDevType_FileOriented,
|  >                            29,
|  >                            (plD_init_fp) plD_init_win3 );
|  >
|  > For example, is it right to use "plDevType_FileOriented" and the pl_=
seq
|  > number 29?
|
| Thanks for working on updating the Win32 port.
|
| The available driver types are shown in disptab.h:
|
| enum {
|     plDevType_FileOriented =3D 0,
|     plDevType_Interactive =3D 1,
|     plDevType_Null =3D -1
| };
|
| I /assume/ you want plDevType_Interactive, but I've never looked into
| using PLplot on windows, so I can't be certain.
|
| From plcore.h, I find that the old seq # for the win3 driver was 10.
| I would preserve that one on the assumption that it made sense, unless
| you have a particular reason to push it down the stack.  In general I
| think the rule is to get the sequence number of the drivers ordered so
| that the default interactive driver for each platfrom will be the top
| one listed in the display.  Dunno if that's strictly possible since
| there are numerous possible interactive drivers on some platforms, and
| whose to say which one is the best default, but that's at least the
| general idea.

This implies that the most recent drivers should appear after the old one=
s,=20
for a given platform, preserving the order that users are used to. The gn=
ome=20
driver violates this, as it appears before the tk driver, which is older.=
=20
This has always puzzled me, but I didn't change it, as I thought that the=
=20
question had already been discussed.

Joao

|  The file oriented drivers show up lower on the list.
|
| The master registry of seq numbers is not at all clear right now,
| sorry.  We should somehow formalize this better.  Maybe an enum for
| the driver sequencing id defined somewhere, I'm not sure what's best.
| Anyway, there's an "#if 0/#endif" block in plcore.h, which I left
| there so we can refer to it as we update all the driver code.  Someday
| that should be summarily expunged, but I think someone should dump a
| little effort into formalizing the device sequencing registry before
| we take that final step.
|
| I am not volunteering, so if anyone is inclined, go ahead.

RE: [Plplot-devel] Help with plD_dispatch_init_win3 needed

[Geoffrey F. <fu...@ga...>]

Olof Svensson writes:
 > Hi plplot developers,
 > 
 > as you have noticed I'm working on getting the Win32 port of plplot
 > working again. I noticed that since the 5.0.4 release a new function is
 > needed for the win3 device, i.e. the "plD_dispatch_init_win3" function.
 > I copied the one I found in "ps.c" and I got the win3 device working
 > however I have no idea if I'm using the correct values:
 > 
 > win3_dispatch_init_helper( pdt,
 >                            "PlPlot Win32 Window", 
 >                            "win3",
 >                            plDevType_FileOriented, 
 >                            29,
 >                            (plD_init_fp) plD_init_win3 );
 > 
 > For example, is it right to use "plDevType_FileOriented" and the pl_seq
 > number 29?

Thanks for working on updating the Win32 port.

The available driver types are shown in disptab.h:

enum {
    plDevType_FileOriented = 0,
    plDevType_Interactive = 1,
    plDevType_Null = -1
};

I /assume/ you want plDevType_Interactive, but I've never looked into
using PLplot on windows, so I can't be certain.

From plcore.h, I find that the old seq # for the win3 driver was 10.
I would preserve that one on the assumption that it made sense, unless
you have a particular reason to push it down the stack.  In general I
think the rule is to get the sequence number of the drivers ordered so
that the default interactive driver for each platfrom will be the top
one listed in the display.  Dunno if that's strictly possible since
there are numerous possible interactive drivers on some platforms, and
whose to say which one is the best default, but that's at least the
general idea.  The file oriented drivers show up lower on the list.

The master registry of seq numbers is not at all clear right now,
sorry.  We should somehow formalize this better.  Maybe an enum for
the driver sequencing id defined somewhere, I'm not sure what's best.
Anyway, there's an "#if 0/#endif" block in plcore.h, which I left
there so we can refer to it as we update all the driver code.  Someday
that should be summarily expunged, but I think someone should dump a
little effort into formalizing the device sequencing registry before
we take that final step.

I am not volunteering, so if anyone is inclined, go ahead.

-- 
Geoffrey Furnish         fu...@ga...

[Plplot-devel] Help with plD_dispatch_init_win3 needed

[Olof S. <sve...@es...>]

Hi plplot developers,

as you have noticed I'm working on getting the Win32 port of plplot
working again. I noticed that since the 5.0.4 release a new function is
needed for the win3 device, i.e. the "plD_dispatch_init_win3" function.
I copied the one I found in "ps.c" and I got the win3 device working
however I have no idea if I'm using the correct values:

win3_dispatch_init_helper( pdt,
                           "PlPlot Win32 Window", 
                           "win3",
                           plDevType_FileOriented, 
                           29,
                           (plD_init_fp) plD_init_win3 );

For example, is it right to use "plDevType_FileOriented" and the pl_seq
number 29?

Best regards,

Olof


-----------------------
Olof Svensson
ESRF
BP 220
38043 Grenoble Cedex
FRANCE
Tel: +33 4 76 88 24 95
Fax: +33 4 76 88 25 42
email: sve...@es...
-----------------------

Re: [Plplot-devel] Win32 port of plplot

[Alan W. I. <ir...@be...>]

I have just made two cvs commits (one for minor changes to core programmes
to cast mallocs so the Olof's compiler doesn't choke, and one for some
changes to win32 so that plplot.lib can be created under windows2000). These
commits correspond to the patch Olof just sent me.  The casting of the
mallocs in the core of plplot seemed fine by visual inspection, and I also
checked them by compiling on my Linux box, and running some examples.  The
win32 stuff is Olof's responsibility.  That part is only partially done, and
Olof plans to send me at least one more patch for the win32 part.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Tue, 4 Dec 2001, Olof Svensson wrote:

> Hi Alan,
>
> I have managed to check out the CVS version of plplot (as of November
> 27) and I have today managed to run all the C examples on my Windows
> 2000 laptop. I just wanted to check with you how we can proceed - would
> you like me to send you the patches or the complete modified files?

Re: [Plplot-devel] x20c.c

[Alan W. I. <ir...@be...>]

On Sun, 2 Dec 2001, [iso-8859-1] Jo=E3o Cardoso wrote:

> I have been looking more closely at the plimage() code. I already
> knew that it didn't support the standard difilt() transformations for
> the xwin driver, so I start implementing them. They imply some
> significant changes to xwin.c! I have them kind of half-baked (!) but
> still far from ready to commit. x20c can now use the -ori and -wplt
> command line options, but with some segmentation faults and rough
> aspect. Thus, as I don't have available time next week, that's better
> for nobody to start working in xwin.c, DrawImage(), as severe
> conflits will arise.

For some reason sourceforge delayed your message until today so that is
why my reply is also today....;-)

Anyhow, just to repeat the gist of my previous post, I have no plans to
change xwin.c or any other plplot code for image index swaps so xwin.c, etc=
=2E
are all yours for now as far as I am concerned.  Instead, I will be working
on finishing the extended example for a colour image which got delayed over
the last two days....

Good luck with the final polishing of your difilt transformation stuff
for images.

Alan

email: ir...@be...
phone: 250-727-2902=09FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] x20c.c

[<jca...@in...>]

On Friday 30 November 2001 20:23, Maurice LeBrun wrote:
| Joao Cardoso writes:
|  > On Friday 30 November 2001 20:12, Maurice LeBrun wrote:
|  > | Alan W. Irwin writes:
=2E..
|  > Of course, if the directory becomes crowed, what I don't think
|  > will happen, it is always possible to move files to
|  > subdirectories, as long as the cvs history is not important,
|  > which I don't think will be the case with this kind of source
|  > code.
|
| I envision one subdirectory for each extended (complex) example,
| since it may be comprised of multiple files: script code, compiled
| code, its own makefile, data files, a readme file, etc.

I agree. Whow, shall we have an extended Lena example with a=20
magnifying lens for close (scientific!) inspection? :)

Another subject, x20c.c related.

I have been looking more closely at the plimage() code. I already=20
knew that it didn't support the standard difilt() transformations for=20
the xwin driver, so I start implementing them. They imply some=20
significant changes to xwin.c! I have them kind of half-baked (!) but=20
still far from ready to commit. x20c can now use the -ori and -wplt=20
command line options, but with some segmentation faults and rough=20
aspect. Thus, as I don't have available time next week, that's better=20
for nobody to start working in xwin.c, DrawImage(), as severe=20
conflits will arise.

Joao

Re: [Plplot-devel] Win32 port of plplot

[Alan W. I. <ir...@be...>]

On Tue, 4 Dec 2001, Olof Svensson wrote:

> Hi Alan,
>
> I have managed to check out the CVS version of plplot (as of November
> 27) and I have today managed to run all the C examples on my Windows
> 2000 laptop. I just wanted to check with you how we can proceed - would
> you like me to send you the patches or the complete modified files?

Let's try a patch first.  I will send you separate instructions.

Thanks very much for this effort.

Alan

[Plplot-devel] Win32 port of plplot

[Olof S. <sve...@es...>]

Hi Alan,

I have managed to check out the CVS version of plplot (as of November
27) and I have today managed to run all the C examples on my Windows
2000 laptop. I just wanted to check with you how we can proceed - would
you like me to send you the patches or the complete modified files? 

Here's a list of problems that I noticed (I'll try to fix them):

* The colours of the win3 device are inverted as compared with X11 or
colour postscript.

* To quit a window one have to click with the left button, to quit an
X11 window one clicks with the right button. 

* The plot window is not square when first opened.

* In example x08c, instead of producing a grey-scale shaded plot it
produces a blue-red shaded plot.

* In example x10c a very small box is plotted in the lower left corner
without any text in it.

* In example x13c there's only one sector coloured - "Maurice" is black
and all the rest of the circle is blue. If the window is resized white
pixels appear in the coloured sectors.

* In example x15c the fill of colour in the different regions doesn't
work at all.

* Example x16c works correctly however is rather slow.

Best regards,

Olof Svensson

Re: [Plplot-devel] Re: Progress on colour images for plimage

[Alan W. I. <ir...@be...>]

First to clarify, the current plimage has a first argument that is addressed
as

z(iy, ix) in fortran or z[ix][iy] in C.  i.e., the row index iy is changing
the most rapidly in both cases for a slower-changing column-index ix.  So
the current memory layout for images, whether fortran or C, corresponds to
scanning the image along the columns (i.e., with the row index changing the
most rapidly).

I was (see below) proposing to change that to z(ix, iy) in fortran or
z[iy][ix] in C so the memory layout would correspond to scanning the image
along the rows (i.e., with column index changing the most rapidly) to be
consistent with the way external libraries organize their images within
memory.

But you have brought up a good point.  Apparently, for other two-dimensional
arrays (see, e.g., the documentation for plshades, plcont, or plot3d) the
array is organized like z[ix][iy] in C and z(iy,ix) in Fortran.  I agree
this organization seems a little more logical from the Fortran perspective
and the way an array z_i_j is layed out in most textbooks with the first
index corresponding to moving along a column (although I have seen a textbook
with the opposite convention!).

Thus, if the first argument of plimage is reordered in the way I was
advocating, the array would have to be reordered (with page faults and cache
faults) to process it with any other plplot function.  Thus, you are moving
from a medium problem to a much larger one with internal inconsistencies.

Thus, I withdraw the proposal.

The other alternative is to swap indices for *every* two-dimensional array
in plplot, but that is an enormous task and changes the API for all our
external users as well.  I expect that will never happen so we will have to
continue to live with the present arrangement of indices (which is probably
a bit of a shock to our C users).

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Mon, 3 Dec 2001, [iso-8859-1] T C wrote:

> Dear Alan,
>
> I suspect that the indexing maybe a hangover from the
> original plplot fortran code where arrays are stored
> in column major order as opposed to C where arrays
> are row major.
>
> Regards
>
> Terrence
>
> ps the offset problems may also come from old fortran
>    code where arrays indices start from 1
>
>
> ________________________________________________________________
> Nokia 5510 looks weird sounds great.
> Go to http://uk.promotions.yahoo.com/nokia/ discover and win it!
> The competition ends 16 th of December 2001.
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] Re: Progress on colour images for plimage

[<apl...@ya...>]

Dear Alan,

I suspect that the indexing maybe a hangover from the
original plplot fortran code where arrays are stored
in column major order as opposed to C where arrays
are row major.

Regards

Terrence

ps the offset problems may also come from old fortran
   code where arrays indices start from 1


________________________________________________________________
Nokia 5510 looks weird sounds great. 
Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! 
The competition ends 16 th of December 2001.

[Plplot-devel] Re: Progress on colour images for plimage

[Alessandro M. <mi...@es...>]

> So it is looking more and more like I will be making the
>      change in index order (although I have yet to hear from Allesandro 
>  on this    question).

Hi Alan,
 I think that it is a very good idea.
I think that keeping the right index ordering is important,
 may be not for performances which are dominated by the transfer rate
 between client and X11 server , but certainly to make programming
easier. It is better to stick to one convention instead of
having  to remember which is which at each step.
Sorry, I did not realise this point previously , but thank you very much 
if you want to correct this error

Ciao
                    Alessandro

[Plplot-devel] Progress on colour images for plimage

[Alan W. I. <ir...@be...>]

I have a nice example of a colour image displayed by plimage, but I haven't
checked anything into cvs yet because some rough programming edges still
need to be smoothed.

One problem is that the cmap1 palette is indexed continously in the range
from 0. to 1, while a colour palette from any typical image is in
pseudo-random order.  (and it is not clear how you would sort it since the
colour palette typically corresponds to points pseudo-randomly scattered on
the colour sphere rather than some line.) Thus, you must be extremely
careful of off-by-one problems when translating internally within the plplot
core back from the 0. to 1. range to indices from 0 to ncol1-1.  Once those
off-by-one problems are solved (and there are plenty of them), then in the
xwin driver (which is the one I have used exclusively because it is the only
fast implementation we have at the moment) there is a further interpolation
from the range 0 to ncol1-1 to the range 0 to 199.  I suppose there is a way
to do that properly, but I haven't found it so it always makes a colour mess
with one exception; ncol1 = 200 works like a charm (since it effectively
bypasses that last interpolation).

Right now I can use the netpbm package to (1) transform any sort of image to
pnm, (2) transform that to an image with 200 colour palette values, (3)
convert that to png, and finally (4) make a nice looking colour result with
plimage.  Combined steps 1-3 are much faster than step 4 (partially due, I
suspect to the index problem I identified for the first part of step 4.) As
I mentioned before, there is a libgd function to translate true-colour png
format to paletted form, but the colorswanted argument is unfortunately
currently a noop with libgd 2.0.1, and it always produces a colour palette
with 256 items rather than the number you specify with colorswanted.  So I
will have to wait for that parameter to start working in say libgd 2.0.2
before I drop step 2 in favour of that method.

Anyhow, that is the status for the moment, and I welcome further discussion
(especially of the 200-point limitation of the X colour palette). I will
probably check all this in under plplot/examples/extended/gdimage tomorrow
or Monday, and at that point you will get a chance to look at the colour
display for plimage yourself.

Alan

P.S. I have looked a bit further into the indexing situation with a lot of
different google searches and to summarize the description of the image
scans that occur for libp[bgm]m and libgd it is stated that they are in the
writing order of most western languages, that is the start at the top left,
scan from left to right for the first scan, then drop down to the next row
and continue scanning.  I found that tiff also has this scan order by
default (but all other possibilities are allowed as well).  bmp is a MS
image "standard" that confirms my sterotype of that company; there is no
public specification written for bmp format!  However, one web site I read
did indicate the bmp scans were along rows in agreement with the Tiff
default and the rest.  Finally, I looked at fits format (beloved by
astronomers). There, it is up to the individual application transforming raw
image data into fits format whether the scans are along rows or columns, and
the guy I talked to knew of each kind of app!

So the score is fits can (and does!) scan along rows or columns, tiff can do
the same although rows are the default, and the rest (that I have looked at)
scan along rows.  So it is looking more and more like I will be making the
change in index order (although I have yet to hear from Allesandro on this
question).

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Index order for our internal images

[Alan W. I. <ir...@be...>]

On Sat, 1 Dec 2001, [iso-8859-1] Jo=E3o Cardoso wrote:

> [snip] You have done a good research, and everything you said implies tha=
t
> we must change plimage internals now. Also because plimage() does not
> yet support any of the difilt() standard transformations, it is
> better to change now (or never!). In the next week I have no time to
> make the changes, so please go ahead.

I am still somewhat concerned there may be image libraries other than
libp[bgp]m and libgd which do not follow the "column-index changes fastest"
"standard".  So everybody here please check your favorite image libraries
now, and let us know the results especially if you find a counter-example. =
I
will also do a lot more checking with my astronomer friends on this issue
for other image libraries, now that there is some tentative approval for th=
e
idea.

>
> Alessandro, are you hearing? What is your opinion?

I also would like to hear from Allesandro.

>
> Have you tried a very large image to notice the page faults? Or are
> you speaking just theoreticaly?

Practical experience long ago with benchmarks for a different project.
Recall that memory access is hierarchical.  So there is not only the
potential page fault problem I mentioned, but also the potential cache faul=
t
problem.  I think reorganizing our indices will make a large difference on
ix86 PC's, for example. The benchmark I did long ago on a pentium-133 was t=
o
determine the Mflop rate for FFT calculations where you know how many flops
there are as a function of the size of the vector you are trying to
transform. There was a sharp factor of three (IIRC) drop in Mflops for
larger N, and that N where that drop occurred corresponded closely to the
size of my L2 cache. Recall, FFT calculations necessarily have very
scattered use of memory so once that overflowed the cache my memory access
times went from cache speeds to memory speeds which of course were 4 times
slower on a pentium-133 (133MHz versus 33 MHz). For fast PC's of today, the
same problem should exist because the ratio of cache speed to memory speed
has stayed roughly the same.

I don't have any practical experience with page fault benchmarks, but the
ratio of memory speed to disk access speed is much higher than cache to
memory speed so the penalty is much worse.  Also, some of the images that
scientist's will want to process with plimage are quite large.  I did a bit
of image processing in the early 90's, and some of the astronomical images
then exceeded 20 MB, and I presume they are even bigger now.

Like you and for the same reasons, I am not keen at all on optimization, bu=
t
I think this time it might be worth what I hope will be the small amount of
trouble involved. Anyhow, I am willing to do the work for the conversion (s=
o
long as nobody finds a substantial number of image library
counter-examples).

Alan

Re: [Plplot-devel] Index order for our internal images

[<jca...@in...>]

On Friday 30 November 2001 21:12, Alan W. Irwin wrote:
| I noticed both for x20c and my modifications to it that the index
| order of the array required for plimage is not the same as either
| lena.pgm or the array produced by libgd.  Thus, such constructs as
|
| for (i=3D0; i<width; i++)
|     for (j=3D0; j<height; j++)
|      =09img_f[i][j] =3D img[(height-j)*width+i];
|
| have to be used to copy from one form to another.  In this case img
| must be stepped through every width pixels for the innermost loop
| which will cause a lot of page faults on low-memory systems.  In
| the interests of minimizing page faults for our users dealing with
| large images (and astronomers and other scientists routinely deal
| with images that are sometimes a lot larger than a 1000 on a side
| and the historical trend on image size is always increasing) I
| would like to see this code fragment (and the equivalent code
| fragment when I am using libgd as input) changed to something like
| the following:
|
| for (j=3D0; j<height; j++)
|     for (i=3D0; i<width; i++)
|      =09img_f[j][i] =3D img[(height-j)*width+i];
|
| Note the two "for" loops have been switched, and now img is stepped
| through one pixel at a time for the innermost loop.  However, to
| also make sure that img_f is stepped through one pixel at a time,
| note that img_f has to be reorganized with swapped indices, and the
| internals of plimage.c and xwin.c also have to be modified the same
| way with swapping of for loops, etc.
|
| Clearly, plimage was put together with the interests of keeping
| page swapping to a minimum for the current internal arrangement of
| images, and it would be a fair amount of work to switch over to the
| opposite scheme. However, for two distinct external image formats
| (pnm [which really stands for pbm, pgm, and ppm] and libgd [which
| stands for both jpeg and png]) we have images organized with the
| the column index changing most rapidly over the width of the image
| while our internal image format used for plimage now is arranged
| with the row index changing most rapidly over the height of the
| image.  This incompatibility forces page faulting, and the only way
| to avoid this is to change our internal format so that the column
| index changes most rapidly.  (I don't care whether a given index is
| accessed in order or reverse as in the above modified example. It
| is the page faults I want to eliminate by making sure the pixel
| step is just one unit for the innermost loop.)
|
| Discussion?  In particular I have only looked at two external
| libraries, and I am interested if anybody has found some external
| image libraries that are *not* organized with the column index of
| the image changing most rapidly. If there is no clear predominance
| we should stick with what we have, but if most are organized the
| way that libpnm and libgd are, then I think we should organize our
| internal images in the same way to avoid the page faults as much as
| possible.
|
| Note if everybody here thinks this index swap is a good idea, I am
| willing to do the necessary conversion work on x20c, plimage.c, and
| xwin.c.  If a change is required it is best to do it now rather
| than later when changing the plimage api will hurt our users.

You have done a good research, and everything you said implies that=20
we must change plimage internals now. Also because plimage() does not=20
yet support any of the difilt() standard transformations, it is=20
better to change now (or never!). In the next week I have no time to=20
make the changes, so please go ahead.

Alessandro, are you hearing? What is your opinion?

Have you tried a very large image to notice the page faults? Or are=20
you speaking just theoreticaly?

I used to have such performance concerns, but with the faster=20
processors and cheap memory I noticed that the time spent improving=20
code was really wasted, as no noticiable difference was noticed in=20
program execution. But of course this is my experience, otherwise=20
ATLAS would not be developed.

Joao

|
| Alan

Re: [Plplot-devel] x20c.c

[Andrew R. <ar...@ge...>]

>
>I greatly prefer plplot/examples/extended or something like that.
>

I like that approach too. Try and keep the name to 8 characters though
please, just for us folk stuck DOS 8.3 file names.

- Andrew

[Plplot-devel] Results from extended testing of octave

[Alan W. I. <ir...@be...>]

Joao, thanks very much for your cvs update (below) which has allowed me to
greatly extend the testing of the octave examples via your updated x??c.m
scripts and my changes to test_octave.sh.

For the usual psc device, everything looked good for the x??c.m examples
(excluding x14, x17, and x19 for obvious reasons) except for a minor problem
with x18 where some lines were missing from pages 6 and 8 of the plot.

I couldn't get very far with the png device because for some reason the
options -fam -fflen 2 which are recognized by the "p" series of examples
seem to be completely ignored by the x??c equivalent examples.  (These
options are also used for the jpeg and xfig driver tests). Without familying
only the first page of each plot is shown for the png driver.  Those looked
fine, and I will look at the remainder of the pages once Joao finds a fix
for the options problem.

Joao, I am most impressed with the wide range of examples the testing script
now exhibits for octave, and it motivates me more than ever to round out
the python and java demos.  Competition is good....;-)

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Wed, 28 Nov 2001, Joao Cardoso wrote:

> Update of /cvsroot/plplot/plplot/bindings/octave/demos
> In directory usw-pr-cvs1:/tmp/cvs-serv407/bindings/octave/demos
>
> Modified Files:
> 	plplot_octave_demo.m x01c.m x02c.m x03c.m x04c.m x05c.m x06c.m
> 	x07c.m x08c.m x09c.m x10c.m x11c.m x12c.m x13c.m x14c.m x15c.m
> 	x16c.m x17c.m x18c.m
> Log Message:
> Now the individual example script files look for the existence of global variables "device" and "file"
> and use them if defined. By default, "xwin" is used.
>
> To use the Octave examples the same way as the pythomdemos or tcldemos, however,
> plinit() and plend() should be conditionaly executed in each script, e.g.,
>
> if (!exist("device"))
>    plinit
> end
>
> The same for plend().
>
> This way, the script files can be used by itself or called from a main octavedemo script file
> that does the plinit() and plend().
>
> _______________________________________________
> Plplot-cvs mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-cvs
>

[Plplot-devel] Index order for our internal images

[Alan W. I. <ir...@be...>]

I noticed both for x20c and my modifications to it that the index
order of the array required for plimage is not the same as either
lena.pgm or the array produced by libgd.  Thus, such constructs as

for (i=0; i<width; i++)
    for (j=0; j<height; j++)
     	img_f[i][j] = img[(height-j)*width+i];

have to be used to copy from one form to another.  In this case img must be
stepped through every width pixels for the innermost loop which will cause a
lot of page faults on low-memory systems.  In the interests of minimizing
page faults for our users dealing with large images (and astronomers and
other scientists routinely deal with images that are sometimes a lot larger
than a 1000 on a side and the historical trend on image size is always
increasing) I would like to see this code fragment (and the equivalent code
fragment when I am using libgd as input) changed to something like the
following:

for (j=0; j<height; j++)
    for (i=0; i<width; i++)
     	img_f[j][i] = img[(height-j)*width+i];

Note the two "for" loops have been switched, and now img is stepped through
one pixel at a time for the innermost loop.  However, to also make sure that
img_f is stepped through one pixel at a time, note that img_f has to be
reorganized with swapped indices, and the internals of plimage.c and xwin.c
also have to be modified the same way with swapping of for loops, etc.

Clearly, plimage was put together with the interests of keeping page
swapping to a minimum for the current internal arrangement of images, and it
would be a fair amount of work to switch over to the opposite scheme.
However, for two distinct external image formats (pnm [which really stands
for pbm, pgm, and ppm] and libgd [which stands for both jpeg and png]) we
have images organized with the the column index changing most rapidly over
the width of the image while our internal image format used for plimage now
is arranged with the row index changing most rapidly over the height of the
image.  This incompatibility forces page faulting, and the only way to avoid
this is to change our internal format so that the column index changes most
rapidly.  (I don't care whether a given index is accessed in order or
reverse as in the above modified example. It is the page faults I want to
eliminate by making sure the pixel step is just one unit for the innermost
loop.)

Discussion?  In particular I have only looked at two external libraries, and
I am interested if anybody has found some external image libraries that are
*not* organized with the column index of the image changing most rapidly. If
there is no clear predominance we should stick with what we have, but if
most are organized the way that libpnm and libgd are, then I think we should
organize our internal images in the same way to avoid the page faults
as much as possible.

Note if everybody here thinks this index swap is a good idea, I am willing
to do the necessary conversion work on x20c, plimage.c, and xwin.c.  If a
change is required it is best to do it now rather than later when changing
the plimage api will hurt our users.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] x20c.c

[Maurice L. <mj...@ga...>]

Joao Cardoso writes:
 > On Friday 30 November 2001 20:12, Maurice LeBrun wrote:
 > | Alan W. Irwin writes:
 > |  > I agree with the important distinction that Geoffrey has drawn between
 > |  > simple demos and extended examples that may include dependencies on
 > |  > non-plplot libraries.  And I agree with having the latter in a separate
 > |  > directory. However, I don't like the name contrib/example because the
 > |  > implication of "contrib" is it was contributed from outside the plplot
 > |  > group, and we don't maintain it or have anything to do with it. So the
 > |  > name I propose is plplot/extended_examples, instead. I don't think we
 > |  > are going to have a lot of extended examples so I propose *not* to
 > |  > divide up plplot/extended_examples into various sub-directories for each
 > |  > of the front-ends like plplot/examples is divided up at the present
 > |  > moment.
 > |
 > | I greatly prefer plplot/examples/extended or something like that.
 > | ...
 > 
 > That's OK for me.  Anyway, it is difficult to antecipate what kind of 
 > subdirectories will be needed.
 > 
 > Of course, if the directory becomes crowed, what I don't think will happen, 
 > it is always possible to move files to subdirectories, as long as the cvs 
 > history is not important, which I don't think will be the case with this kind 
 > of source code.

I envision one subdirectory for each extended (complex) example, since it may
be comprised of multiple files: script code, compiled code, its own makefile,
data files, a readme file, etc.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] x20c.c

[Joao C. <jca...@in...>]

On Friday 30 November 2001 20:12, Maurice LeBrun wrote:
| Alan W. Irwin writes:
|  > I agree with the important distinction that Geoffrey has drawn betwe=
en
|  > simple demos and extended examples that may include dependencies on
|  > non-plplot libraries.  And I agree with having the latter in a separ=
ate
|  > directory. However, I don't like the name contrib/example because th=
e
|  > implication of "contrib" is it was contributed from outside the plpl=
ot
|  > group, and we don't maintain it or have anything to do with it. So t=
he
|  > name I propose is plplot/extended_examples, instead. I don't think w=
e
|  > are going to have a lot of extended examples so I propose *not* to
|  > divide up plplot/extended_examples into various sub-directories for =
each
|  > of the front-ends like plplot/examples is divided up at the present
|  > moment.
|
| I greatly prefer plplot/examples/extended or something like that.
|
|  > Directory and file names are always a pain to change in CVS so I wil=
l
|  > give you a chance to think about the name I have proposed and the fl=
at
|  > directory structure below it before I commit anything to CVS tomorro=
w.
|
| Good idea.

That's OK for me.  Anyway, it is difficult to antecipate what kind of=20
subdirectories will be needed.

Of course, if the directory becomes crowed, what I don't think will happe=
n,=20
it is always possible to move files to subdirectories, as long as the cvs=
=20
history is not important, which I don't think will be the case with this =
kind=20
of source code.

Joao