gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Explicit rgb colors [was Re: historysize]

[<mi...@ph...>]

>> But at some point, the Postscript terminal has to decide for itself how
>> many palette entries it wants. From my reading of the output file, the
>> colours of the dots are determined by a single "gray" value, which has
>> only four digits of precision -- clearly not enough to handle 24 bit
>> colour.

This scheme with 4 digits is enough for continous pm3d maps. It should
stay as is, as for large maps, every byte written to the datafile counts
(nb of points)-times.

An easy fix would be to extend the precision if "set palette maxcolors" is
larger than 1e4.

> So maybe we need to consider one or both of the following changes to
> post.trm
>
> 1) Only some plot styles should use this "optimization".  Color assignment
>    for points, say, could be done by post.trm itself just as it is done by
>    gd.trm
>
> 2) The run-time/print-time optimization choice could be toggled by a
>    suboption to "set term post", but would continue to apply equally to
>    all plot elements.

Or some new call like term->set_palette(be truecolor).
Or term->set_trucolor(rgb_or_cmyk_, r, g, b, k) to bypass the current
set_palette+set_color mechanism.

---
PM

Re: opengl terminal driver (was povray terminal driver)

[Robert H. <en...@no...>]

On Thu, 2005-08-18 at 13:48 -0700, Ethan Merritt wrote:
> On Thursday 18 August 2005 01:28 pm, Ga=EBl Varoquaux wrote:
> >=20
> > > Personally I am in favour of the second option. Freeglut is
> > > standard/available in Debian, Ubuntu, and (as I understand
> > > it) Fedora/Red-hat.
> >=20
> >     How about my objection about library dependancies, if it makes any
> > sense ?
>=20
> I don't think there is a 100% solution to this problem.
> Sadly, freeglut and other glut implementations are not perfectly
> compatible.  If you try transferring a binary linked against,
> say X.org glut, to a machine that has nVidia drivers and glut libs
> you are likely to crash the application, X11 itself, and possibly
> the whole machine.  [As I have learned the hard way].

hmm. I can't say I've had any problems myself. I'm not sure how many of
the opengl apps I have use glut, but certainly things like upgrading
from Xfree86 to X.org haven't caused me any issues.

Anything that crashes X11 is a bug in the server.

Rob

--=20
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Povray terminal driver

[Robert H. <en...@no...>]

On Thu, 2005-08-18 at 22:28 +0200, Ga=EBl Varoquaux wrote:

>     How about my objection about library dependancies, if it makes any
> sense ?

I understand your objection, and I have tried to think of simple ways to
make it work with the more standard glut. Although it would be nice to
run out of the box with whatever glut happens to be installed, I think
the extra complexity of having to deal with writing a whole separate
program and piping the terminal information back and forth, would
seriously outweigh the advantages of the slightly wider audience.

I think the availability/portability of freeglut is sufficient that a
large portion of people who want to try it will be able to, and until it
actually does something that the x11 interface doesn't it wont be a
major loss for anybody who can't.


--=20
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: File based terminal behaviour

[Juergen W. <wie...@fr...>]

Am Donnerstag, 18. August 2005 22:27 schrieb Ethan Merritt:
> That depends on what you want to end up with. If you want
> all of your plots included in the same output file then
> you certainly don't want to close it after each one.
> In fact that will result in the plots over-writing each
> other and only the last plot will be saved in the end.

I had the impression the OP wanted to have single-plot
files---eventually, he uses PNG and SVG.  So I discussed only
"non-multi-page terminals".  I should have been more clear about
it.  Thanks for the clarification.


Juergen

Re: Bug in image code ?

[Ethan M. <merritt@u.washington.edu>]

On Thursday 18 August 2005 10:26 am, Daniel J Sebald wrote:
> 
> You agree that PostScript should be allowed to have negative numbers for 
> an image location then?  

The PostScript language itself allows negative numbers, if that's what you're
asking.  Whether the gnuplot core routines should ever send negative coordinates
to a terminal driver is a rather different question.

> (Or does PostScript always have a greater than zero offset for the origin of the plot area?)  

Zero offset is a legal origin.  The result of zero offset and negative coordinates
is probably device-dependent.  I do not recall ever seeing a printer either crash
or wrap around for this reason, but then again one doesn't normally construct such
cases on purpose.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Bug in image code ?

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 17 August 2005 11:06 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
> > Yes. It's really a nightmare. Although you raise a possible 
> > issue below, my inclination is that we should never be using
> > unsigned coordinates.  Wrapping around to a large positive number
> > is far worse than going negative.
> 
> Not really.  It's the same problem in a different dress.  Terminal
> coordinates are really only valid in some interval.  That interval 
> always has one endpoint at zero, by design, so it makes sense for the 
> coordinates to be unsigned.  It being unsigned even helps generate 
> faster code: a single test for (x < term->xmax) will detect points that 
> are off to the right or the left.

Detect, yes.  But it does not allow you to clip the line segment.
For that you need the "true" negative coordinate so that you
can interpolate the intersections with the plot borders.

> Any case of a coordinate outside that range being passed to the driver 
> is a bug in the core: it's a clear sign that somebody forgot to do 
> proper clipping.  

We are somewhat talking at cross-purposes.
I agree that the core routines should clip before sending to the
drivers. Fine.  The problem is that the core routines *themselves*
use unsigned integers, which they should not.  And once the arithmetic
has started using unsigned ints, clipping becomes much, much harder.

> >>And try to remember that we have at least some drivers 
> >>where
> >>
> >>	INT_MAX < term->xmax < UINT_MAX. 
> > Are you sure?  Which ones?
> 
> All the 16-bit platforms easily have this potential, 32-bit ones can be 
> driven there.

But only if the terminal claims to have > 32768 pixels.
Is that in fact the case?

> Win16 always is close to behaving like that by default during 
> copy-to-clipboard (24000x18000 pixels).  Many others, including 
> postscript, can be made to, if you only 'set size' high enough before 
> 'set term' or use the driver's own 'size' option.

'set size' is itself highly problematic.
I'll make the provocative assertion that size > 1.0 should not
be allowed.  Or allowed only with the caveat "if you set size > 1.0
then do not complain if your terminal overflows or segfaults".
 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Explicit rgb colors [was Re: historysize]

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 17 August 2005 11:43 am, Theo Hopman wrote:
> You are correct. The red dot in the png truecolour terminal disappears 
> with these functions definitions. That said, the png truecolour terminal 
> does not work correctly under all circumstances. Consider the following:
> 
>    set term png truecolor
>    set out 'test1.png'
>    load 'colour-data.gp'
>    set out
>    set term png notruecolor
>    set out 'test2.png'
>    load 'colour-data.gp'
>    set out
>    set term png truecolor
>    set out 'test3.png'
>    load 'colour-data.gp'
>    set out
> 
> One would expect the first and third PNG files to be the same, but 
> they're not. The colours are incorrect in the third.

For me the 1st and 3rd plots are indeed identical.
Possibly I have a newer version of libgd than you do (2.0.33),
but other than that I cannot think why you would see something
different.

 
> But at some point, the Postscript terminal has to decide for itself how 
> many palette entries it wants. From my reading of the output file, the 
> colours of the dots are determined by a single "gray" value, which has 
> only four digits of precision -- clearly not enough to handle 24 bit colour.

Ah. You may be right about that.  The postscript driver tries to offload
the gray->rgb calculation into print-time PostScript code; this makes for
a shorter output file but slower evaluation by the postscript device, and
apparently introduces an opportunity for substantial roundoff error.

So maybe we need to consider one or both of the following changes to
post.trm

1) Only some plot styles should use this "optimization".  Color assignment
   for points, say, could be done by post.trm itself just as it is done by
   gd.trm

2) The run-time/print-time optimization choice could be toggled by a 
   suboption to "set term post", but would continue to apply equally to
   all plot elements.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Povray terminal driver

[V. <gae...@no...>]

On Thu, Aug 18, 2005 at 09:09:11PM +0100, Robert Hart wrote:
> Have you confused the povray terminal and the opengl terminal?

    A, yes, in the title, though, not in my head. :->

> I thought the povray terminal just dumped a povray file that you could
> later render in povray?

    Yes, sorry for the confusion.

> When I wrote the opengl terminal driver I used freeglut, which is the
> default glut on Debian, without even realising I was doing anything
> non-standard.

    Hum, weird then that I can't compile it. I'll look at that after my
holidays.

> The choice is:=20

> a) create a gnuplot_opengl (similar to the X11
> terminal)
> b) require an "enhanced" glut
> c) Use raw OpenGL (without any glut)
> d) multi-threaded

> Personally I am in favour of the second option. Freeglut is
> standard/available in Debian, Ubuntu, and (as I understand
> it) Fedora/Red-hat.

    How about my objection about library dependancies, if it makes any
sense ?

--
    Ga=EBl

Re: File based terminal behaviour

[Ethan M. <merritt@u.washington.edu>]

On Thursday 18 August 2005 01:08 pm, Juergen Wieferink wrote:
> 
> So the savest thing is to do:
> 
>   set ...
>   ...
> 
>   set term ...
>   set output "..."
>   plot ...
>   set output

That depends on what you want to end up with. If you want
all of your plots included in the same output file then
you certainly don't want to close it after each one.
In fact that will result in the plots over-writing each
other and only the last plot will be saved in the end.

The important distinction is whether a particular
output format can contain multiple plots (NB: *not* multiplot)
or not.  A PostScript or PDF document can contain as many
plots as you want, one per page.  A PNG output file can
contain only one plot.  A GIF output file can contain
multiple plots, but only if you describe them as an 
"animation".  The current SVG terminal was not designed to
handle multiple plots in the same output file; whatever
you get in this case is undocumented and may not be
repeatable.

Inconsistent?  I suppose so.  But this is the nature of
the output formats themselves.  gnuplot cannot store
multiple plots in an PNG image because the PNG standard
itself does not provide for it.  (Actually, there is an
extension called MNG that does provide for multiple
plots per file, but let's disregard that for now).



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Bug in image code ?

[Hans-Bernhard B. <br...@ph...>]

Daniel J Sebald wrote:
> Then again, should it be the core's responsibility to deal with boundary 
> checks if ultimately these terminal parameters come from the terminal 
> driver?  

The parameters come from the driver, but the data being plotted don't.
By the time they arrive in the driver, they should be usable by it, i.e. 
within the terminal coordinate range.

 > If yes, then where should the boundary checks be placed?  As
> part of map_x() and map_y()?  

No.  Clipping depends on the primitive being drawn, so it can't be done 
by just clipping individual coordinates.  We already have quite a 
collection of special clipping functions, for that reason:

	cliptorange
	clip_point
	clip_line
	clip_move / clip_vector
	clip_put_text
	clip_put_text_just
	edge_intersect
	edge_intersect_steps
	edge_intersect_fsteps
	two_edge_intersect
	two_edge_intersect_steps
	two_edge_intersect_fsteps
	bound_intersect
	edge3d_intersect
	two_edge3d_intersect

Some of those are misnomers, but they all handle clipping either to the
graph box interior, or to the page, for various primitives or plotting 
styles.

But clipping should indeed typically happen closely before map_x() is 
called, because that's where data get transformed from doubles to 
terminal coordinates.  I.e. searching for calls of map_x() can help 
locate the positions that need to be checked if clipping is being 
handled correctly.  The traditional plot style handlers (plot_lines() & 
friends) handle clipping by checking input data a couple of processing 
steps before they ever reach map_x() --- that's what INRANGE/OUTRANGE 
are about.  plot_image_...() doesn't.

The problem is that different graphical primitives need different 
clipping techniques.

Re: Povray terminal driver

[Robert H. <en...@no...>]

Have you confused the povray terminal and the opengl terminal?

I thought the povray terminal just dumped a povray file that you could
later render in povray?

Anyway the issue with the glut library is as follows:

The "standard" glut, i.e. the one distributed by SGI and in common usage
on many platforms, is written under the assumption that your program
registers a number of event handlers and then pass control over to glut.
This is a limitation that makes it hard to add glut based opengl on to
existing programs, or programs where another toolkit is used for another
part of the interface.

freeglut (and I thought openglut) work around this problem by allowing you
to do a single pass through the glut event loop and then regain
control. This makes it very easy to do glut based opengl in existing
applications.

When I wrote the opengl terminal driver I used freeglut, which is the
default glut on Debian, without even realising I was doing anything
non-standard.

The choice is: 

a) create a gnuplot_opengl (similar to the X11
terminal)
b) require an "enhanced" glut
c) Use raw OpenGL (without any glut)
d) multi-threaded

Personally I am in favour of the second option. Freeglut is
standard/available in Debian, Ubuntu, and (as I understand
it) Fedora/Red-hat.

Rob

-- 
  ______  _____  ______  _______  ______ _______
 |_____/ |     | |_____] |______ |_____/    |   
 |    \_ |_____| |_____] |______ |    \_    |   
                                                
 _     _ _______  ______ _______
 |_____| |_____| |_____/    |   
 |     | |     | |    \_    |   


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: File based terminal behaviour

[Juergen W. <wie...@fr...>]

On Wednesday 17 August 2005 14:21 Gareth Wilson wrote:
> I am relatively new to gnuplot and don't pretend to know anything about its
> internals but some of the behaviour has been perplexing me. I can find very
> little information on the intended behaviour or philospohy of the program.

That's something I'm missing, too.

> In an interactive terminal (x11 in our case) this is of no consequence but
> when attempting to save the output to a file (I have used both png and SVG)
> the ordering is critical as the first plot command encountered outputs to
> the file, not allowing subsequent replots, clearing, adding of titles etc.

Think of it the following way:  There are two kinds of file based
terminals: those which are capable of multi-page output files and
those which are not.  If you do more then one plot/splot/replot
command in a row with a non-multi-page terminal, the result is
undefined.  [If you ask me, gnuplot should issue a warning then.]

And the second point is:  The state of the output file is undefined
as long as it isn't closed yet ("set output").  It may be valid in
advance (png), and it may not (postscript).

> This behaviour is not encountered by multiplots which seem to be
> constructed in a temporary terminal and then output once completed
> (signified by the unset multiplot). I cannot get this behaviour to be
> replicated for single plots however.

So the savest thing is to do:

  set ...
  ...

  set term ...
  set output "..."
  plot ...
  set output

or

  set ...
  ...

  set term ...
  set output "..."
  set multiplot
  set size ...
  plot ...
  set size ...
  plot ...
  unset multiplot
  set output


If you need a valid file while plotting, set output to a temporary
file and rename it after the finishing "set output".

Juergen

Re: Explicit rgb colors [was Re: historysize]

[Theo H. <th...@ph...>]

Ethan Merritt wrote:
> I think your color functions are not quite right.  The color encoding for
> each channel runs from 0->255, not 1->256.  I think you end up with red
> because the green and blue components wrap around to 0 since they 
> cannot be 256.
> 
> Try:
> r(gray)=int(2.**24*gray-1)/65536/256.
> g(gray)=int(2.**24*gray-1)%65536/256/256.
> b(gray)=int(2.**24*gray-1)%256/256.

You are correct. The red dot in the png truecolour terminal disappears 
with these functions definitions. That said, the png truecolour terminal 
does not work correctly under all circumstances. Consider the following:

   set term png truecolor
   set out 'test1.png'
   load 'colour-data.gp'
   set out
   set term png notruecolor
   set out 'test2.png'
   load 'colour-data.gp'
   set out
   set term png truecolor
   set out 'test3.png'
   load 'colour-data.gp'
   set out

One would expect the first and third PNG files to be the same, but 
they're not. The colours are incorrect in the third.

[...]
> This puzzles me, however.  PostScript is paletted in a sense,
> but it reports back to the core that it has an infinite number of 
> palette entries. I would have expected "set term post color" to
> produce essentially the same result as "set term png truecolor".

But at some point, the Postscript terminal has to decide for itself how 
many palette entries it wants. From my reading of the output file, the 
colours of the dots are determined by a single "gray" value, which has 
only four digits of precision -- clearly not enough to handle 24 bit colour.

[...]

THeo

Re: File based terminal behaviour

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 17 August 2005 05:21 am, Gareth Wilson wrote:
> 
> In an interactive terminal (x11 in our case) this is of no consequence but when
> attempting to save the output to a file (I have used both png and SVG) the
> ordering is critical as the first plot command encountered outputs to the file,
> not allowing subsequent replots, clearing, adding of titles etc.

If you are happy with the x11 output, then I would hazard a guess that your
best choice may be to bind a hot-key for x11 that issues a replot command to the
file-based terminal of your choice:
	bind "ctrl-p" "set term png; set output 'myplot.png'; replot; set term x11"

Then you can adjust the plot to your liking in an x window, and hit <control>p
to save it to a file.

For production work you'd need a more complicated binding that incremented the
file name somehow.
 
> This behaviour is not encountered by multiplots which seem to be constructed in
> a temporary terminal and then output once completed (signified by the unset
> multiplot). I cannot get this behaviour to be replicated for single plots 
> however.

I'm afriad I don't recognize the symptoms you describe here.  There is no
temporary terminal involved in multiplot.

 
> From reading the postings here and on Soureforge I gather that the png terminal
> is usually piped to Imagemagick's display

Well, it's the way *I* usually do it, at least if I'm sitting at the terminal.
But primarily I use the png terminal in automated scripts at the back end of
a web form, in which case they are not piped to ImageMagick but are saved as
temporary files and linked back into a dynamically generated web page.

> 
> Would it not therefore make sense to have the option that once a user enters a 
> 'set term png', 'set output foo.png' to construct the plot as multiplot does,
> and then output the completed plot once the 'set output' command closes the 
> file?

That is, in fact, the way they are normally used.
Could you try to describe the probably you are having in more detail?
I can't understand what multiplot has to do with anything.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Bug in image code ?

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
>> Yes. It's really a nightmare. Although you raise a possible issue 
>> below, my inclination is that we should never be using
>> unsigned coordinates.  Wrapping around to a large positive number
>> is far worse than going negative.
> 
> 
> Not really.  It's the same problem in a different dress.  Terminal
> coordinates are really only valid in some interval.  That interval 
> always has one endpoint at zero, by design, so it makes sense for the 
> coordinates to be unsigned.  It being unsigned even helps generate 
> faster code: a single test for (x < term->xmax) will detect points that 
> are off to the right or the left.
> 
> Any case of a coordinate outside that range being passed to the driver 
> is a bug in the core: it's a clear sign that somebody forgot to do 
> proper clipping.

I wouldn't rule out any such oversight on my part.  There could be half a pixel extending past the "wrap-around" border in some circumstances.

Then again, should it be the core's responsibility to deal with boundary checks if ultimately these terminal parameters come from the terminal driver?  If yes, then where should the boundary checks be placed?  As part of map_x() and map_y()?  That would seem to be the logical place for good code reuse.

Dan

Re: Explicit rgb colors [was Re: historysize]

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 17 August 2005 12:03 pm, Ethan Merritt wrote:
> Ah. You may be right about that.  The postscript driver tries to offload
> the gray->rgb calculation into print-time PostScript code; this makes for
> a shorter output file but slower evaluation by the postscript device, and
> apparently introduces an opportunity for substantial roundoff error.

Just to prove the point - 

The small patch below forces the gray->rgb conversion to happen in the
driver, rather than in the PostScript code.  With this patch in place,
the postscript output looks the same as the png truecolor output.

diff -ur gnuplot/term/post.trm gnuplot-cvs/term/post.trm
--- gnuplot/term/post.trm       2005-08-07 18:21:52.000000000 -0700
+++ gnuplot-cvs/term/post.trm   2005-08-17 16:03:53.408922728 -0700
@@ -3371,7 +3371,16 @@
        if (gray >= 1)
            fputs("1 g ", gppsfile);
        else
+#if (0)
            fprintf(gppsfile, "%s g ", save_space(gray));
+#else
+       {
+           rgb_color color;
+           rgb1_from_gray(gray, &color);
+           fprintf(gppsfile, "%5.3f %5.3f %5.3f setrgbcolor ",
+               color.r, color.g, color.b);
+       }
+#endif
     }
     PS_relative_ok = FALSE; /* "M" required because "g" forces stroke (??) */
 }



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Explicit rgb colors [was Re: historysize]

[Theo H. <th...@ph...>]

Theo Hopman wrote:
> I can conceive of a possible workaround: rather than encoding colours as 
> rrrrrrrrggggggggbbbbbbbb, they could be encoded as something like 
> grbgrbgrbgrbgrbgrbgrbgrb, so that the MSBs of the green and blue 
> channels are not lost in palette sampling. I'll give this a shot sometime.

Meh...this doesn't work as well as I think it should. The various 
paletted terminals agree better now, but the colours are still wrong, 
though not as disastrously as before. Oddly, the truecolour png terminal 
no longer gives results as good as before. Perhaps there's some flaw in 
my encoding/decoding logic, but I can't see it, as is usually the case 
with logic flaws. Also, some of the dots are drawn as open circles, 
rather than filled. What the deal with that?

encode(c,n)=(n==1 ? (int(c)&1) : ((int(c)&1) + 8*encode(int(c)/2,n-1)) )
decode(c,n)=(n==1 ? (int(c)&1) : ((int(c)&1) + 2*decode(int(c)/8,n-1)) )
# The encode() and decode() functions use recursion to iterate over n
# bits. encode() replaces each bit with either 000 or 001; decode() does
# the reverse.
# e.g. encode(7,8) == 73 == 001 001 001
#      encode(4,8) == 64 == 001 000 000
#      encode(128,8) == 2097152
#      encode(255,8) == 2396745 == 2^21 + 2^18 + 2^15 + ... + 2^0
#      encode(256,8) == 0
rgb(r,g,b)=4*encode(g,8)+2*encode(r,8)+encode(b,8)
red(gray)=decode(int(gray*2**24)/2,8)/256.
green(gray)=decode(int(gray*2**24)/4,8)/256.
blue(gray)=decode(int(gray*2**24),8)/256.

set palette color model RGB functions red(gray), green(gray), blue(gray)
set cbrange [0:2**24-1]
unset colorbox
set ticslevel 0
splot 'colour-data.txt' using 1:2:3:(log($4)):(rgb($1,$2,$3)) \
         with points pointtype 7 pointsize variable palette

THeo

Re: Bug in image code ?

[V. <gae...@no...>]

On Wed, Aug 17, 2005 at 09:45:38PM +0200, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> >On Wednesday 17 August 2005 11:06 am, Hans-Bernhard Broeker wrote:

> >>Not really.  It's the same problem in a different dress.  Terminal
> >>coordinates are really only valid in some interval.  That interval=20
> >>always has one endpoint at zero, by design, so it makes sense for the=
=20
> >>coordinates to be unsigned.  It being unsigned even helps generate=20
> >>faster code: a single test for (x < term->xmax) will detect points th=
at=20
> >>are off to the right or the left.

> >Detect, yes.  But it does not allow you to clip the line segment.

> That's OK --- clipping should not be done in the terminal driver anyway.

    Hum clipping, for instance, an image involves a certain amount of
work. Should that be done in the terminal driver ?

--
    Ga=EBl

Re: Explicit rgb colors [was Re: historysize]

[Juergen W. <wie...@fr...>]

On Wednesday 17 August 2005 20:08 Ethan Merritt wrote:
> On Wednesday 17 August 2005 10:09 am, Theo Hopman wrote:
> > The non-truecolor option gives erroneous results, which I
> > don't think are related to "nearest colour" approximations: for small
> > values of (x,y,z) = (r,g,b) we should be getting dark dots, not
> > relatively bright green and blue ones, even if a nearest colour was
> > being used.

This is what I understand:

The "nearest colour" approximation is done with the gray value,
not with the colour itself:  The gray value is first rounded and
then mapped to an rgb value.

This is OK as long as it is used as designed:  Show values of one
continuous range.

> The "nearest colour" calculation produces very strange results. I ran
> into this problem before. But never mind that. Clearly if you want to
> specify arbitrary rgb triples, the terminal should be in full rgb mode
> (TrueColor).
>
> > Other paletted terminals (postscript, x11) give similar
> > undesirable results.
>
> This puzzles me, however.  PostScript is paletted in a sense,
> but it reports back to the core that it has an infinite number of
> palette entries. I would have expected "set term post color" to
> produce essentially the same result as "set term png truecolor".

If I remember the postscript colour handling correctly, the
Postscript terminal does the "nearest colour" approximation itself.
At least for "palette rgbformulae": The needed functions are put as
formulaes into the postscript file and evaluated while
displaying/printing the file.  Reporting an infinite number of
palette entries probably means the terminal does the mapping.

This means that the postscript file generally contains the gray
values and a rule how to map this onto colours.  I'd expect "palette
functions" to save an interpolated table into the output file.


Juergen

Re: File based terminal behaviour

[Daniel J S. <dan...@ie...>]

Gareth,

> I am developing a program that uses Octave (and hence gnuplot) to perform
> engineering calculations and display the results in a web broswer.
> 
> To do this I need to output the plots to graphics file. The program is
> attempting to keep MATLAB and Octave compatibility for interactive use of each
> of the scripts, this riases issues of plot command ordering.
> 
> In an interactive terminal (x11 in our case) this is of no consequence but when
> attempting to save the output to a file (I have used both png and SVG) the
> ordering is critical as the first plot command encountered outputs to the file,
> not allowing subsequent replots, clearing, adding of titles etc.

gnuplot/Octave and Matlab is fairly consistent, but it can be frustrating.  The biggest discrepancy I see is that gnuplot syntax changes plot properties (e.g., title) first and then plots.  Matlab wants one to generate a plot first then change the properties.  (Why, I don't know.)  Yes this causes problems with multiplot.

You have to be creative with strategically placed

if exists('OCTAVE_VERSION')
  graw('set term');
  <or whatever other commands to gnuplot that you want>
end

and the like.  Try turning off auto replot in Octave.  Then Matlab/Octave might be good enough if you create a bogus Matlab plot first then issue title(), axis(), etc.  I usually can manage to get what I want with code that will run in both Matlab and Octave.

Be aware that Octave is going through some changes as far as graphics commands, but I've not kept up.  I'm afraid you will have to do what you can until a year or two down the road to see some re-emerging of gnuplot/Octave.

> This behaviour is not encountered by multiplots which seem to be constructed in
> a temporary terminal and then output once completed (signified by the unset
> multiplot). I cannot get this behaviour to be replicated for single plots 
> however.
> 
>>From reading the postings here and on Soureforge I gather that the png terminal
> is usually piped to Imagemagick's display, and that the behaviour of most other
> file based terminals has been derrived from the png terminal's. It would appear
> to me that the strength of a file based terminal is the production of a finished
> plot, saved to a file for publishing, not real time viewing in an alternative
> format. 
> 
> Would it not therefore make sense to have the option that once a user enters a 
> 'set term png', 'set output foo.png' to construct the plot as multiplot does,
> and then output the completed plot once the 'set output' command closes the 
> file?

I'm not following you.  gnuplot is very flexible with screen and file plots.

Dan

Re: Bug in image code ?

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
>> On Wednesday 17 August 2005 11:06 am, Hans-Bernhard Broeker wrote:
> 
> 
>>> Not really.  It's the same problem in a different dress.  Terminal
>>> coordinates are really only valid in some interval.  That interval 
>>> always has one endpoint at zero, by design, so it makes sense for the 
>>> coordinates to be unsigned.  It being unsigned even helps generate 
>>> faster code: a single test for (x < term->xmax) will detect points 
>>> that are off to the right or the left.
> 
> 
>> Detect, yes.  But it does not allow you to clip the line segment.
> 
> 
> That's OK --- clipping should not be done in the terminal driver anyway.
> 
>> For that you need the "true" negative coordinate so that you
>> can interpolate the intersections with the plot borders.
> 
> 
> More to the point, you need the original input, i.e. the floating-point
> numbers that the plot elements are all specified in.
> 
>> I agree that the core routines should clip before sending to the
>> drivers. Fine.  The problem is that the core routines *themselves*
>> use unsigned integers, which they should not.  
> 
> 
> Agreed, up to a point --- the key issue is that they have to clip
> before converting any coordinates to integers, be those signed or 
> unsigned.  For the classic plot styles, it's done by checking the data 
> points' validity flags (INRANGE/OUTRANGE/UNDEFINED).  The 'with image' 
> implementation, in particular, never checks these flags.  Odds are 
> that's exactly the root of the bug the OP found.

The image drawing routine does not use INRANGE.  Originally I intended that.  There is an in range test in a way, however.

Here is the issue.  When we speak of a *point* being in range, that is one thing.  But consider that the pixel of an image has a non-negligible width.  So, there can be pixels for which its centers are just outside the viewable border.  They'd be classified as OUTRANGE, but really a portion of the pixel would be visible.  Agreed?  When pixels are very small, it is not a big deal to leave out a portion of a pixel.  But when resolution is low, it's noticeable.

But, unlike pm3d, there is no easy way for the core to create portions of a pixel because of the nature of image data.  I think that clipping has to be done at the terminal level because every utility has it's own way of handling a portion of an image being viewable.  (For example, the X11 code I wrote has as part of its algorithm something that creates portions of a pixel.)  In summary, the image code tosses out all pixels that are clearly out of the viewable range, but keeps those just on the exterior of the boundary if they exist.

This is why I said a portion of a pixel might be extending off the viewable boundary.  Also it's why I'm asking whether the terminal should take care of boundary checking.  Have I just given an argument why a signed number passed to the terminal driver, as Ethan suggests, would prove better than unsigned?  (Not sure myself.)  That is, this may be a case where it is worth being able to tell in which direction something has gone out of range, rather than being able to test out of range with a single unsigned test?

Dan

Povray terminal driver

[V. <gae...@no...>]

    I had a look a compiling the povray terminal driver and it does not
compile on my box (debian sarge, or ubuntu hoary). I think this is
because I have freeglut, and not openglut. Talking to some people who
know more about glut than I do (not that hard), it seems that freeglut
is more common (and it will be much easier to find on windows, for
instance).

    However... If I understand the problem correctly free/open glut is
required rather than plain glut because plain glut cannot start a
separate thread. Starting a separate process and pipping instructions to
it could be a possible workaround (like what has been done for X11), but
it seems ugly. I am right on these points ?
    On the other hand, compiling gnuplot with opengl requires to link it
with free/open/" " glut. If the libraries are not statically linked in
opengl will not work. What I am not sure about is how a dynamically
linked gnuplot binary will behave if the opengl library it relies on is
not on the system ? Can it work at all. If not that would be a great
impediment on a wide distribution of gnuplot opengl : it would require
to build your own version of gnuplot, or to install a separate gnuplot.
    What if we have a gnuplot_glut binary, and that gnuplot accepts to
"set term opengl" and to start this gnuplot_opengl binary only if it can
work ? That would remove the library dependancy problem.

    In the light of this reasoning (maybe totally flawed, as I cannot
claim that I understand those problems) it seems to me that we could
stick with standard glut and avoid problems.

--
    Ga=EBl

Re: Bug in image code ?

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Thursday 18 August 2005 10:26 am, Daniel J Sebald wrote:
> 
>>You agree that PostScript should be allowed to have negative numbers for 
>>an image location then?  
> 
> 
> The PostScript language itself allows negative numbers, if that's what you're
> asking.

Yeah, I suppose that is why I used a %d rather than a %u in the fprintf() for the PostScript driver.  If the core only sends "small" unsigned numbers, having %d there shouldn't hurt anything.

> Whether the gnuplot core routines should ever send negative coordinates
> to a terminal driver is a rather different question.

Actually it is a rather similar question.  As far as a frame of reference, it seems to me that when laying out a plot (as with drawing on a piece of paper) you want to leave room on all sides to work with.  The following would be equivalent:

1) allow signed coordinates, choose plot area origin near 0
2) allow unsigned coordinates, choose plot area origin way out (halfway?) in the allowable number range

By going with option 2 and then setting axis_array[axis].term_lower to zero in the following formula

#define AXIS_MAP(axis, variable)        \
 (int) ((axis_array[axis].term_lower)        \
     + ((variable) - axis_array[axis].min)    \
     * axis_array[axis].term_scale + 0.5)

it is like starting a drawing on the corner edge of one's piece of paper.

Dan

Re: Bug in image code ?

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Thursday 18 August 2005 09:04 am, Daniel J Sebald wrote:
> 
>>I think it can't, but let's continue to hash this out...  
>>Image data sent to a plotting device, like a PostScript interpretter, 
>>is a rectangular matrix--essentially a uniform sampling of intensity 
>>(light, field strength, temperature, etc.).  
>>There is no way to include in that data individual information about 
>>a pixel, say, pixel 25 should be only 0.67 the size of the uniform 
>>sampling interval.
> 
> 
> Bad example.  PostScript support for explicit clipping is very straightforward.
> You set the clipping boundary first, and then draw your big "pixels" without
> any special processing.  PostScript itself will clip them to fit within the
> requested clipping boundary.
> 
> The real problem comes from the drivers with external libraries that are
> too stupid to clip -- libpdf being the prime offender.

That is my point.  PostScript is very capable of dealing with this, just as you describe.  It effectively draws a portion of a pixel.  And as you point out with libpdf, there appears to be no universal solution to this.

I'm arguing that we should not limit the PostScript or X11 drivers because other less-intelligent drivers have no good solution.  If libpdf is incapable, then it should be at the driver level that a decision is made to toss out some pixels that partially extend outside the viewable range, i.e., further refinement by possible shrinking the image by one pixel per edge.

You agree that PostScript should be allowed to have negative numbers for an image location then?  (Or does PostScript always have a greater than zero offset for the origin of the plot area?)

Dan

Re: Bug in image code ?

[Ethan M. <merritt@u.washington.edu>]

On Thursday 18 August 2005 09:04 am, Daniel J Sebald wrote:
> 
> I think it can't, but let's continue to hash this out...  
> Image data sent to a plotting device, like a PostScript interpretter, 
> is a rectangular matrix--essentially a uniform sampling of intensity 
> (light, field strength, temperature, etc.).  
> There is no way to include in that data individual information about 
> a pixel, say, pixel 25 should be only 0.67 the size of the uniform 
> sampling interval.

Bad example.  PostScript support for explicit clipping is very straightforward.
You set the clipping boundary first, and then draw your big "pixels" without
any special processing.  PostScript itself will clip them to fit within the
requested clipping boundary.

The real problem comes from the drivers with external libraries that are
too stupid to clip -- libpdf being the prime offender.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195