plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] x20c.c

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

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.

 > Directory and file names are always a pain to change in CVS so I will give
 > you a chance to think about the name I have proposed and the flat directory
 > structure below it before I commit anything to CVS tomorrow.

Good idea.

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

Re: [Plplot-devel] x20c.c

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

On Fri, 30 Nov 2001, Joao Cardoso wrote:

> On Friday 30 November 2001 17:02, Geoffrey Furnish wrote:

> | I also believe "demos" should be minimalist in their linkage
> | requirements.  But I also believe more extended examples could be
> | valuable.
> |
> | [snip] In my former case mentioned above, I had always
> | sort of wanted to set up something else, a new class of demos or
> | something.  In other words, not call it a demo, but call it a
> | contrib/example/XYZ, or something.
>
> Yes, of course! I think that this is the solution!
>

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.

Directory and file names are always a pain to change in CVS so I will give
you a chance to think about the name I have proposed and the flat directory
structure below it before I commit anything to CVS tomorrow.

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

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

On Friday 30 November 2001 17:02, Geoffrey Furnish wrote:
| Jo=E3o Cardoso writes:
|  > You want to write a tutorial; I just want to show that it can be
|  > done. You want to write code that users can modify to theirs needs; =
I
|  > just want to show them that it can be done.
|  >
|  > I profoundly disagree (as you said) on puting library dependencies o=
n
|  > demos. It is not a question of being nice to have color images, but =
a
|  > question of software development.
|  >
|  > What do others think?
|
| I want to steer clear of any headstrong stance here myself, but I do
| have some thoughts.
|
| I also believe "demos" should be minimalist in their linkage
| requirements.  But I also believe more extended examples could be
| valuable.
|
| I duno if anyone remembers, but long ages ago, I once mentioned that I
| had hacked a raster capability into a development copy of plplot,
| using a new plescape hook in xwin.c.  I never got around to committing
| that.  The reason (well, among a host of others, including the whole
| business of finding a hosting arrangement for PLplot) was that that
| particular program was not only an example of an image display
| capability, but it was also parallelized, using either Pthreads or
| MPI.  (It was a parallel mandlebrot calculator, displaying to xwin).
| So it was a /very/ complex example program.  I could not figure out
| how to package an MPI example program into a suitable state for
| distribution with PLplot.  Then the pressures of work diverted my
| attention until it was effectively abandonded.
|
| In general, I guess I favor having some mechanism to exhibit
| "extensive examples" (potentially with substantial external linking
| requirements), but I just don't think the "demos" is the right medium
| for such expositions.  In my former case mentioned above, I had always
| sort of wanted to set up something else, a new class of demos or
| something.  In other words, not call it a demo, but call it a
| contrib/example/XYZ, or something.

Yes, of course! I think that this is the solution!

| So, it seems to me that something similar is waranted in this case
| too.  I agree with both of you.  There is a need for demos to be
| simple, and a need for extensive examples to be exhibited.  My
| suggestion is to somehow think of a packaging technique that puts the
| extensive, external dependency laden examples, into a seperate
| collection.  Probably each of those has to be separately configured,
| based on the availability of various --enable-xyz options, drivers,
| libraries, etc.
|
| Because its so much work to set something like that up, that's why
| I've never done it.
|
| Gotta run.

Re: [Plplot-devel] dyn-drivers linking -- again!

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

On Friday 30 November 2001 16:52, Geoffrey Furnish wrote:
| Jo=E3o Cardoso writes:
|  > Sorry, I meant, using
|  >
|  > =09driverlibs :=3D -L. -l$(PLLIB_NAME)$(LIB_TAG)
|  >
|  > Well, I followed your recipe and build java (jdk-1.1.8). Python
|  > demos, Java demos and Octave demos all run OK with the png device (a=
s
|  > well as other fiole devices), using only the above driverslibs.
|
| Hi all,
|
| Sorry for my unresponsiveness.  I'm totally overwhelmed with other
| stuff.
|
| A quick comment on this business.  I have not been confused by the
| behavior that has been reported.  I think a sufficiently careful study
| of the emails that were exchanged earlier this fall, would make it all
| make sense.  But it is certainly frustrating, no argument there.
|
| The fix mentioned above should work.  Drivers should only depend on
| libplplot.so, plus whatever driver specific support libs they might
| need.  The dyndrv.in currently makes no effort to figure out exactly
| and only which libs are appropriate to each driver.  It would be great
| to fix that, although also laborious, which is why I never did it.

Well, I have already make it. E.g.

drivers/gd.drv : shared/gd$O
        $(SHLIB_BUILD) $@ $< @GDLIBS@ $(driverlibs)

Where GDLIBS are the libs "configure" found necessary. The other drivers =
that=20
have special libs are the gnome driver, with GNOMELIBS, and the ntk drive=
r,=20
with TKLIBS. All the other drivers only link against libplplot. Of course=
 the=20
xwin and tk drivers are static.

| The best fix, however, is to do some code development to break even
| the dependence upon libplplot.so, leaving only the (potential)
| dependence of a driver upon some external libs (gd, X11, whatever).
|
| The way to do this is to embellish the driver interface so that when a
| driver is inited, you pass in a struct, which contains members that
| are function pointers:
|
| struct plenv {
|
|     void (*plapi_xyzcall)( PLINT x, ... );
|     ...
|  };
|
| So, plcore would make one of thiese, fill in the function pointers
| with the values of (addresses of) the various PLplot API function
| entry points that might be conceivably needed by drivers,

I dont think this is practical.

| and then
| pass this struct into the driver when init'ing it.  Then the drivers
| store this, and make all their calls to the PLplot API via:
|
|     plenv->plapi_xyzcall( x, ... );
|
| etc.
|
| This breaks the linkage requirement of drivers upon libplplot.so.
|
| Doing it this way would follow in the footsteps of the Java Native
| Interface, and, I think Vince said earlier, the TEA model.
|
| At this point I can only offer this sketch, I cannot commit to
| implement anytime soon.

I think that the current scheme is reasonable, so you can spend your=20
available time improving the library itself. Have you noticed that in the=
=20
last few years only configure issues have been addressed? No significant=20
improvements to the library itself have been made?

Joao

Re: [Plplot-devel] x20c.c

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

Jo=E3o Cardoso writes:
 > You want to write a tutorial; I just want to show that it can be=20
 > done. You want to write code that users can modify to theirs needs; =
I=20
 > just want to show them that it can be done.
 >=20
 > I profoundly disagree (as you said) on puting library dependencies o=
n=20
 > demos. It is not a question of being nice to have color images, but =
a=20
 > question of software development.
 >=20
 > What do others think?

I want to steer clear of any headstrong stance here myself, but I do
have some thoughts.

I also believe "demos" should be minimalist in their linkage
requirements.  But I also believe more extended examples could be
valuable.

I duno if anyone remembers, but long ages ago, I once mentioned that I
had hacked a raster capability into a development copy of plplot,
using a new plescape hook in xwin.c.  I never got around to committing
that.  The reason (well, among a host of others, including the whole
business of finding a hosting arrangement for PLplot) was that that
particular program was not only an example of an image display
capability, but it was also parallelized, using either Pthreads or
MPI.  (It was a parallel mandlebrot calculator, displaying to xwin).
So it was a /very/ complex example program.  I could not figure out
how to package an MPI example program into a suitable state for
distribution with PLplot.  Then the pressures of work diverted my
attention until it was effectively abandonded.

In general, I guess I favor having some mechanism to exhibit
"extensive examples" (potentially with substantial external linking
requirements), but I just don't think the "demos" is the right medium
for such expositions.  In my former case mentioned above, I had always
sort of wanted to set up something else, a new class of demos or
something.  In other words, not call it a demo, but call it a
contrib/example/XYZ, or something.

So, it seems to me that something similar is waranted in this case
too.  I agree with both of you.  There is a need for demos to be
simple, and a need for extensive examples to be exhibited.  My
suggestion is to somehow think of a packaging technique that puts the
extensive, external dependency laden examples, into a seperate
collection.  Probably each of those has to be separately configured,
based on the availability of various --enable-xyz options, drivers,
libraries, etc.=20

Because its so much work to set something like that up, that's why
I've never done it. =20

Gotta run.

--=20
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] dyn-drivers linking -- again!

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

Jo=E3o Cardoso writes:
 > Sorry, I meant, using=20
 >=20
 > =09driverlibs :=3D -L. -l$(PLLIB_NAME)$(LIB_TAG)
 >=20
 > Well, I followed your recipe and build java (jdk-1.1.8). Python=20
 > demos, Java demos and Octave demos all run OK with the png device (a=
s=20
 > well as other fiole devices), using only the above driverslibs.

Hi all,

Sorry for my unresponsiveness.  I'm totally overwhelmed with other
stuff.

A quick comment on this business.  I have not been confused by the
behavior that has been reported.  I think a sufficiently careful study
of the emails that were exchanged earlier this fall, would make it all
make sense.  But it is certainly frustrating, no argument there.

The fix mentioned above should work.  Drivers should only depend on
libplplot.so, plus whatever driver specific support libs they might
need.  The dyndrv.in currently makes no effort to figure out exactly
and only which libs are appropriate to each driver.  It would be great
to fix that, although also laborious, which is why I never did it.

The best fix, however, is to do some code development to break even
the dependence upon libplplot.so, leaving only the (potential)
dependence of a driver upon some external libs (gd, X11, whatever). =20=


The way to do this is to embellish the driver interface so that when a
driver is inited, you pass in a struct, which contains members that
are function pointers:

struct plenv {

    void (*plapi_xyzcall)( PLINT x, ... );
    ...
 };

So, plcore would make one of thiese, fill in the function pointers
with the values of (addresses of) the various PLplot API function
entry points that might be conceivably needed by drivers, and then
pass this struct into the driver when init'ing it.  Then the drivers
store this, and make all their calls to the PLplot API via:

    plenv->plapi_xyzcall( x, ... );

etc.

This breaks the linkage requirement of drivers upon libplplot.so. =20

Doing it this way would follow in the footsteps of the Java Native
Interface, and, I think Vince said earlier, the TEA model.

At this point I can only offer this sketch, I cannot commit to
implement anytime soon.

--=20
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] Small API compatibility break.

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

Jo=E3o Cardoso writes:
 >=20
 > Hi,
 >=20
 > While working on x20c.c, I noticed that plxormod() should return a=20=

 > status, saying that the device is or is not capable of such=20
 > operation. The user code would then conditionaly execute code that=20=

 > uses or not xor mode.
 > The change, to be usefull, would imply also minor changes in xwin.c=20=

 > and tk.c, adding a device option has_xormod, but this is transparent=
=20
 > to the user (all is ready for commit).
 >=20
 > This will break compatibility with previous releases of plplot. What=
=20
 > do you think? I think that plxormod() is not widely used, so there=20=

 > should be no problems for most users.

Go for it.

--=20
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Small API compatibility break.

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

Sounds good to me.  Does this new functionality affect x01c.c as well?

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
__________________________

On Fri, 30 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:

>
> Hi,
>
> While working on x20c.c, I noticed that plxormod() should return a
> status, saying that the device is or is not capable of such
> operation. The user code would then conditionaly execute code that
> uses or not xor mode.
> The change, to be usefull, would imply also minor changes in xwin.c
> and tk.c, adding a device option has_xormod, but this is transparent
> to the user (all is ready for commit).
>
> This will break compatibility with previous releases of plplot. What
> do you think? I think that plxormod() is not widely used, so there
> should be no problems for most users.
>
> Joao
>
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] Small API compatibility break.

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

Hi,

While working on x20c.c, I noticed that plxormod() should return a=20
status, saying that the device is or is not capable of such=20
operation. The user code would then conditionaly execute code that=20
uses or not xor mode.
The change, to be usefull, would imply also minor changes in xwin.c=20
and tk.c, adding a device option has_xormod, but this is transparent=20
to the user (all is ready for commit).

This will break compatibility with previous releases of plplot. What=20
do you think? I think that plxormod() is not widely used, so there=20
should be no problems for most users.

Joao

Re: [Plplot-devel] plstrm.h and PLINTs

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

Andrew Roach writes:
 > While trying to track down the problem with X20C and DJGPP I noticed that
 > there were several warnings for incompatible pointers being passed. Not a
 > real issue, it was just PLINT being passed to int and vice versa. Since
 > PLINT and int are usually the same it should not have made a real
 > difference to my problem, but it does present an ascetic situation for
 > compiling without warnings.
 > 
 > One thing I did find was that most of the new plimage commands expect
 > *dev_ix and *dev_iy in the PLStream structure to be defined as PLINT while
 > the PLStream structure defines them as type int. I know that is a simple
 > fix, but this is not really the reason I am writing the email. There are
 > many other variables of type "int" in PLStream, while the vast majority are
 > of type "PLINT". Is there any particular reason for this ? 

Any pointer should be a (PLINT *), without fail, else bad things can happen.
But for vanilla integers it doesn't matter so much.  For local temporary
variables I think it's preferable to just use int or long as appropriate.
The only negative is if you assign a PLINT to an int you might get compiler
warnings about possible overflow.

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

Re: [Plplot-devel] X20C.C bug fixed - problem with "plAlloc2dGrid"

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

Andrew Roach writes:
 > I finally found the error in X20C that was causing SIGFP errors. The error
 > was being tripped by a floating point exception in "plMinMax2dGrid", which
 > in turn was being caused by a miss-allocation in "plAlloc2dGrid".
 > "plAlloc2dGrid" has always worked in the past with DJGPP so why it stopped
 > working now, and only with X20C.C, I don't know. Any clues ? 

Luck? :)  Probably calloc should always be used rather than malloc.  If
using unitialized data *consistently* produced a segv then the malloc would be
better in theory to help find logic errors, in user code at least.  In a
library it's iffier, so the calloc is fine with me.

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

[Plplot-devel] X20C.C bug fixed - problem with "plAlloc2dGrid"

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

I finally found the error in X20C that was causing SIGFP errors. The error
was being tripped by a floating point exception in "plMinMax2dGrid", which
in turn was being caused by a miss-allocation in "plAlloc2dGrid".
"plAlloc2dGrid" has always worked in the past with DJGPP so why it stopped
working now, and only with X20C.C, I don't know. Any clues ? 

I changed the memory allocation from malloc to calloc, ensuring the buffer
was zeroed, and at the same time put in a quick memory checking routine.
That should not effect "plAlloc2dGrid" at all by my reading, but it does
somehow, at least for DJGPP. So all now seems fine on the DJGPP front... I
hope I have not upset anything for you linux guys with my change. If so, I
am sure you will let me know ;-)

- Andrew

[Plplot-devel] plstrm.h and PLINTs

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

While trying to track down the problem with X20C and DJGPP I noticed that
there were several warnings for incompatible pointers being passed. Not a
real issue, it was just PLINT being passed to int and vice versa. Since
PLINT and int are usually the same it should not have made a real
difference to my problem, but it does present an ascetic situation for
compiling without warnings.

One thing I did find was that most of the new plimage commands expect
*dev_ix and *dev_iy in the PLStream structure to be defined as PLINT while
the PLStream structure defines them as type int. I know that is a simple
fix, but this is not really the reason I am writing the email. There are
many other variables of type "int" in PLStream, while the vast majority are
of type "PLINT". Is there any particular reason for this ? 

Should we consider coding all variables of type "int" to "PLINT" for
consistency as was done with "float" to "PLFLOAT" months ago ? 

I can't see any harm in it, but perhaps other people might have objections
or reasons for keeping some variables as "int" and others as "PLINT".
Changing them will also probably mean making the changes in the functions
that manipulate these variables to get rid of warnings as well of course.

- Andrew

Re: [Plplot-devel] Segfault problems solved (sort of) [was X20c.c]

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

Hello,

First, back to the original SEGFP errors I was getting with X20c. I have
compiled x20c WITHOUT any GD driver at all, and I still get the same SEGFP
errors, so it isn't anything new introduced in the GD driver changed. I
know it is related to the plimage command, but where in it I don't know. 

>> I only actually added about 8 new lines to the driver, so the differences
>> are minimal, and there would seem to be little to go wrong there.
>
>Hmmm.  I just tried a test with the old version of gd.c, and all the
>segfaults go away.  With the new gd.c I also overrode GD2_VERS to be 1 and
>the result was no segfaults.  However, if I left it at 2 (i.e., actually
>compile your 3 calls to gdImageSetThickness(dev->im_out, pls->width)), the
>segfaults come back. Either there is something wrong with libgd 2.0.1 or more
>likely dev->im_out or pls->width are not properly set when you make these
>calls. 

pls->width should be set from plplot, and is ok. I don't think the problem
can be there. dev->im_out could have a problem, but that will sadly go back
to GD somewhere. I think something is wrong with libgd 2.0.1 - it is listed
on the gd web site as an "unstable beta", and there is a warning in the
makefile that linking order can be significant. We knew that from the very
first incarnation of the GD driver anyway, but at least for DJGPP, the
linking order has changed AGAIN *sigh*. The last STABLE version of GD is
1.8.4. I strongly suspect the problem is in GD.

>Until you can find the answer, I have overriden GD2_VERS in the interest of
>keeping -dev png operational on CVS head.

Probably a good idea, but there is sadly little I can do, because
unfortunately (fortunately?) it works on my machine and I can't replicate
your problem :-( Wekl actually I CAN replicate it, but I can also FIX it by
changing the linking order, and making sure the maths library links AFTER
libgd.a, libpng.a, and libjpeg.a . Did you try reordering the linking ? 

One other thought. Are you 100% sure that you are linking against the 2.0.1
library and not the 1.8.? library ? You might have the headers for GD 2 but
the library for GD 1 - that would probably cause an error like this.

- Andrew

[Plplot-devel] Segfault problems solved (sort of) [was X20c.c]

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

iOn Wed, 28 Nov 2001, Andrew Roach wrote:

> I only actually added about 8 new lines to the driver, so the differences
> are minimal, and there would seem to be little to go wrong there.

Hmmm.  I just tried a test with the old version of gd.c, and all the
segfaults go away.  With the new gd.c I also overrode GD2_VERS to be 1 and
the result was no segfaults.  However, if I left it at 2 (i.e., actually
compile your 3 calls to gdImageSetThickness(dev->im_out, pls->width)), the
segfaults come back.  Either there is something wrong with libgd 2.0.1 or more
likely dev->im_out or pls->width are not properly set when you make these
calls. (Recall our previous Linux segfault problem with gd was caused by a
subtle undefined argument problem.)

Until you can find the answer, I have overriden GD2_VERS in the interest of
keeping -dev png operational on CVS head.

Alan

Re: [Plplot-devel] X20c.c

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

>In short, everything with xwin and psc seems to work,
>but now there is trouble for the gd driver so that (e.g.) every
>x??c example I tried with -dev png produces a segfault.
>So I suggest you review your recent gd changes to see if that is the
>
>Good night for now, and I will do some more testing of gd tomorrow if
>you haven't found the solution by then.

I only actually added about 8 new lines to the driver, so the differences
are minimal, and there would seem to be little to go wrong there. 

On DJGPP I had to change the linking order from the earlier versions of GD
(ie 1.8.4) to get GD 2.0.1 to work with anything without crashing. That
happened with or without my changes to gd.c (ie the older version of gd.c
linked against the libgd.a 2.0.1 caused the same problems with crashes). 

Try linking the maths library AFTER all the GD and GD dependent libraries.
At present I believe it is linked in before them. This change made a big
difference for my build, though logic and good coding suggests it should
not have. Perhaps it might fix yours ? 

- Andrew

Re: [Plplot-devel] X20c.c

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

Andrew, I haven't committed any of my x20c changes to CVS yet. However,
because of your problems with the latest CVS version, I just did a fresh
checkout, configure, and build of that version to make sure Joao's very
recent changes (mostly from Allesandro) and your recent gd driver changes
work on my machine.  In short, everything with xwin and psc seems to work,
but now there is trouble for the gd driver so that (e.g.) every
x??c example I tried with -dev png produces a segfault.

So I suggest you review your recent gd changes to see if that is the
source of our common trouble.

Good night for now, and I will do some more testing of gd tomorrow if
you haven't found the solution by then.

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
__________________________

On Wed, 28 Nov 2001, Andrew Roach wrote:

> For Jo=E3o and Alan in particular,
>    In the last snapshot I took from the CVS I found X20C is now totally
> broken. I get SIGFP errors (ie floating point of some sort). It does not
> matter which driver I use either. Is this also visiting the linux version=
s,
> or just my DJGPP build ?
>
>   Also, I got a lot of minor conflicts between plcore.c, plimage.c and
> definitions in plplotp.h. I did my own patch to plplotp.h to try and
> circumvent it and let me compile, but not knowing which is correct (ie
> plcore.c or plplotp.h) i didn't want to commit my changes.
>
>
> Oh, Alan, in case you are interested, I just added support for different
> line widths in the GD driver !
>
> - Andrew
>
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] X20c.c

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

For Jo=E3o and Alan in particular,
   In the last snapshot I took from the CVS I found X20C is now totally
broken. I get SIGFP errors (ie floating point of some sort). It does not
matter which driver I use either. Is this also visiting the linux versions,
or just my DJGPP build ?

  Also, I got a lot of minor conflicts between plcore.c, plimage.c and
definitions in plplotp.h. I did my own patch to plplotp.h to try and
circumvent it and let me compile, but not knowing which is correct (ie
plcore.c or plplotp.h) i didn't want to commit my changes.


Oh, Alan, in case you are interested, I just added support for different
line widths in the GD driver !

- Andrew

Re: [Plplot-devel] x20c.c

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

On Wed, 28 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:

> You want to write a tutorial; I just want to show that it can be
> done. You want to write code that users can modify to theirs needs; I
> just want to show them that it can be done.
>
> I profoundly disagree (as you said) on puting library dependencies on
> demos. It is not a question of being nice to have color images, but a
> question of software development.

Note, I am leaving in your gray-scale image reading since it now works, and
I am simply adding another page for a colour image.  We can
straightforwardly configure out the colour image reading in x20c.c for the
case where the user does not have libgd installed.  Thus, I don't believe
there is any cause for your concern here since your work is essentially
left unaffected.

> ....(lots of example code from octave deleted)
> To continue, reducing the palete to 256 colors, I need a definition
> of what a "near color" to other color is.

I am running into a problem with the plimage colour image that may be
relevant to your question.  The problem is the index range is effectively
stored as a floating point number and converted inside plimage to the range
0. --> 1, then a call to plcol1 is made. That is all well and good, but I a=
m
just starting to review the plcol1 code now to see how the 0. to 1. range i=
s
mapped to the colour palette index range. For colour images that index
mapping has to be exact. If there is an off-by-one error in the resulting
index it makes very little difference to gray-scale images since the colour
palette is continuous in that case. However, such an error would make a hug=
e
mess for non-continuous colour palettes that occur for most colour images. =
I
am getting such a colour mess at the moment (poor Lena has surreal colours!=
)
while the identical set of calls to libgd and plimage work fine if the
lena.png image is gray-scale. That is why I am looking for off-by-one error=
s
in plcol1.

Alan

Re: [Plplot-devel] x20c.c

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

On Wed, 28 Nov 2001, Andrew Roach wrote:

> >whatever).  Now in order to work with colour images in plplot you do need
> >the appropriate colour pallette defined for cmap1, but the png format, for
> >example, does allow for up to 256 different colours in a pallette.  (png
> >format also has the truecolour alternative, but we must avoid that because
> >plplot would not be able to work with it.)
>
> Is that /really/ true ? I must confess I have not looked at the code yet
> (or for months), but I didn't think that plplot /was/ limited to 256
> colours. my last look at the colourmap stuff made me think it could easily
> cope with more than that. The current PNG driver is limited to 256 because
> the 1.? versions of GD didn't support truecolour, but unless I am mistaken
> plplot should be "open" enough to support more than 256 colours already.
> 16.5 million might be pushing it, but all the same...  Someone please
> correct me if I am wrong.

I agree plplot can cope with almost arbitrary numbers of colours in cmap1 so
it is possible to get rid of the 256 limit in the png driver.  However, I
was talking about the png format palette limit above and not libgd or cmap1.
Sorry for that misunderstanding. For a reference on this 8-bit limit for the
png palette, see http://www.w3.org/TR/PNG-Chunks.html#C.IHDR.

Later, in an update I did talk about libgd where there is a function called
gdImageTrueColorToPalette to convert from truecolor to palette.  It is
largely undocumented except for the header file so I don't know what the
limitations are there on the number of palette indices, but I assume it
is pretty likely it conforms to the 256 png limit above.

> I was sleeping while most of these discussions were going on - you forget,
> I am on the other side of the world from most of you guys :-) I was going
> to have a look at it today and see what was to be done. Let me know what
> progress you're making and let see what happens.

Excellent progress.  It truly is just a small number of lines of code. Gray
scale works fine and I am close on the colour image as well.  See comment I
will make to Joao's question about colour images.

Alan

Re: [Plplot-devel] Opened bugs and patches

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

On Wed, 28 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:

>
>
> Hi,
>
> At http://sourceforge.net/projects/plplot/, bugs and patches, the
> following must be closed:
>
> Bug 437824 was corrected by Alan
> Patch 475952 was applied by Alan and me.
> Patch 482318 was applied by Alan? (not shure)

Done!  Thanks for pointing those out.

Alan

Re: [Plplot-devel] x20c.c

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

On Tuesday 27 November 2001 20:29, Alan W. Irwin wrote:
| On Tue, 27 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:
| > On Tuesday 27 November 2001 07:35, Alan W. Irwin wrote:
=2E..
| > x20c.c uses a fast and crude way of reading an image, with the
| > purpose of demonstrate a libplplot API. "lena" is generaly
| > available as jpeg. As I *didn't* want to use libgd to read jpeg,
| > I converted it to ppm, which is simple to read.
|
| I acknowledge your approach seems to work now (from your subsequent
| e-mail although you haven't checked it in so I cannot see for
| myself, yet), and also it does have the great advantage of
| simplicity.  Nevertheless, in my view it is too limited an
| approach. IMHO, part of the point of demos is to allow our users to
| relate plplot with other work. Thus, I would profoundly disagree
| with the notion that no special libraries are allowed to be used by
| our examples other than libplplot and friends.  Here with x20c we
| have an outstanding chance to do something really interesting so
| let us take advantage of the opportunity rather than limiting
| ourselves.

You want to write a tutorial; I just want to show that it can be=20
done. You want to write code that users can modify to theirs needs; I=20
just want to show them that it can be done.

I profoundly disagree (as you said) on puting library dependencies on=20
demos. It is not a question of being nice to have color images, but a=20
question of software development.

What do others think?

| To be specific, right now you limit the x20c demonstration to false
| colour (using default cmap1) and gray-scale images.  With the png
| approach we can have the demonstration of actual colour images
| (i.e., scanned photographs or whatever).  Now in order to work with
| colour images in plplot you do need the appropriate colour pallette
| defined for cmap1, but the png format, for example, does allow for
| up to 256 different colours in a pallette.  (png format also has
| the truecolour alternative, but we must avoid that because plplot
| would not be able to work with it.) I have just found that the
| combination of pnmquant and pnmtopng does produce the
| colour-pallete style png format.  Now I have done little coding
| yet, but from the documentation it looks like the colour pallette
| is accessible using the libgd library so that for the cost of ~15
| extra lines of code in x20c we can demonstrate processing a colour
| image.  With a few lines of commentary in x20c.c we can also advise
| all our Linux users how to use the netpbm utilities to transform
| *any* of their favorite colour images into a png image with colour
| palette that the ~15 lines of libgd-related code in x20c.c could
| understand.
|
| Joao, instead of more discussion about this *before the fact*, let
| me try to implement colour images for x20c in the way I have
| outlined as a basis for further discussion. If I am successful with
| the code, and there are no other nasty issues that arise, I hope to
| convince you that a colour picture of Lena will look better....;-)
| I have already found a colour version of this test image at
| http://www.dcs.gla.ac.uk/~wpc/gmm3/web/lena.jpg.

In octave: (pplimage not yet cvs commited)

file =3D"color-lena.ppm";
fp =3D fopen(file, "r");
ver =3D fscanf(fp, "%s%*c", "C");
a =3D '#';
while (a(1,1) =3D=3D '#')
   pos =3D ftell(fp);
   a =3D fgetl(fp);
endwhile;
fseek(fp, pos);
[xx yy max_c] =3D fscanf(fp, "%d%d%d", "C");
img =3D fread(fp, [xx*3 yy], "uchar");
fclose(fp);

red =3D reshape (img(1:3:xx*3, :)', xx*yy, 1);
green =3D reshape (img(2:3:xx*3,:)', xx*yy, 1);
blue =3D reshape (img(2:3:xx*3,:)', xx*yy, 1);

plenv(-1,1,-1,1,1,-1);
pplimage(red, xx, yy, -1,1,-1,1,-1,1,-1,1)
pplimage(green, xx, yy, -1,1,-1,1,-1,1,-1,1)
pplimage(blue, xx, yy, -1,1,-1,1,-1,1,-1,1)

palette =3D [reshape (red, xx*yy, 1) \
               reshape (green, xx*yy, 1) \
               reshape (blue, xx*yy, 1) ];

To continue, reducing the palete to 256 colors, I need a definition=20
of what a "near color" to other color is.

Joao

Re: [Plplot-devel] x20c.c

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

On Tuesday 27 November 2001 21:23, Alan W. Irwin wrote:
| On Tue, 27 Nov 2001, Alan W. Irwin wrote:
| > (png
| > format also has the truecolour alternative, but we must avoid
| > that because plplot would not be able to work with it.) I have
| > just found that the combination of pnmquant and pnmtopng does
| > produce the colour-pallete style png format.  Now I have done
| > little coding yet, but from the documentation it looks like the
| > colour pallette is accessible using the libgd library so that for
| > the cost of ~15 extra lines of code in x20c we can demonstrate
| > processing a colour image.  With a few lines of commentary in
| > x20c.c we can also advise all our Linux users how to use the
| > netpbm utilities to transform *any* of their favorite colour
| > images into a png image with colour palette that the ~15 lines of
| > libgd-related code in x20c.c could understand.
|
| Correction: I have just discovered the gdImageTrueColorToPalette
| function in libgd which translates an image from truecolour to
| palette.  So strike my comments about netpbm.  Everything we need
| to process colour png images of any type is already in libgd.

But I had to compile my libgd, because Suse-7.0 didn't have it!
We have irreconciliable opinions in this respect.

Joao

Re: [Plplot-devel] x20c.c

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

>whatever).  Now in order to work with colour images in plplot you do need
>the appropriate colour pallette defined for cmap1, but the png format, for
>example, does allow for up to 256 different colours in a pallette.  (png
>format also has the truecolour alternative, but we must avoid that because
>plplot would not be able to work with it.) 

Is that /really/ true ? I must confess I have not looked at the code yet
(or for months), but I didn't think that plplot /was/ limited to 256
colours. my last look at the colourmap stuff made me think it could easily
cope with more than that. The current PNG driver is limited to 256 because
the 1.? versions of GD didn't support truecolour, but unless I am mistaken
plplot should be "open" enough to support more than 256 colours already.
16.5 million might be pushing it, but all the same...  Someone please
correct me if I am wrong.

>Andrew, I assume you haven't yet had a chance to implement a libgd-based
>image reading routine for x20c so I am just going to go ahead on my own.

I was sleeping while most of these discussions were going on - you forget,
I am on the other side of the world from most of you guys :-) I was going
to have a look at it today and see what was to be done. Let me know what
progress you're making and let see what happens. 

Apart from anything else, I have to build GD 2.0.1. I downloaded it last
night, and tried a build but ran into problems. Since GD 1.8.? they
clobbered the 8.3 naming conventions, so I had to remake the make file
fixing up the problems, then to slow things down even more, I discovered
that somehow (how or why it happened, I have NO idea) I no longer have
libpng's header files so could not recompile the new GD. Once I get those
headers back I will have another go at rebuilding the library. 

- Andrew

[Plplot-devel] Opened bugs and patches

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

Hi,

At http://sourceforge.net/projects/plplot/, bugs and patches, the=20
following must be closed:

Bug 437824 was corrected by Alan
Patch 475952 was applied by Alan and me.
Patch 482318 was applied by Alan? (not shure)

Could someone (Alan) with admin previleges close these?

Thanks,
Joao