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

Re: Explicit rgb colors

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

On Wednesday 17 August 2005 11:16 am, Theo Hopman wrote:
> Theo Hopman wrote:
> 
> 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, 

After mulling things over in my head last night, I think Theo's
approach, clever as it is, is the wrong way to go.  Drivers which
are capable of rgb output already support a mechanism for requesting
specific rgb triples.
	t_colorspec *color;
	color->type == TC_RGB;
	color->lt =  24_bit_packed_rgb_triple;
	term->set_color(color);

What we are missing is a way to select this method of color generation
rather than the usual pm3d palette functions.

We should expand the syntax for "with" to provide an alternative
in parallel to "with palette".  Something like
  splot <foo> 1:2:3:4 with palette    # Takes gray value from $4
  splot <foo> 1:2:3:4 with rgb        # Takes packed rgb triple from $4

We already have such a keyword for specifying individual line styles,
text styles, etc.  Extending it to the overall plot style seems both
obvious and easy to do.  The input routine in df_readline() should
handle packed hexadecimal values as is, so data files can look like:

#   X   Y   Z   RGB
#=========================
  255   0 255   0xFF00FF
    0 127   0   0x000f00


-- 
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:
> Daniel J Sebald wrote:
> 
>> 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.  
> 
> 
> Well, nobody ever promised doing proper clipping would be easy.  It 
> rather certainly is not --- as you can see by looking at the existing 
> code.  You didn't believe plot_lines() is a 50-line function just for 
> fun, did you?

To quote the Monkees, I'm a believer.

> 
> The fact that it's hard is all the more reason to do it in the core, 
> where we only have to get it right once, instead of re-inventing this 
> for every terminal driver.

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.  Rather, I think the only control is to specify an overall visible range for the image.  The driver can then stop drawing the pixel once outside the viewable range.  This scenario arises when the viewer's resolution is higher than the image data itself, i.e., when an image pixel actually occupies 30 screen pixels, say, in X11.

Dan

Re: Bug in image code ?

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

Daniel J Sebald wrote:
> 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.  

Well, nobody ever promised doing proper clipping would be easy.  It 
rather certainly is not --- as you can see by looking at the existing 
code.  You didn't believe plot_lines() is a 50-line function just for 
fun, did you?

The fact that it's hard is all the more reason to do it in the core, 
where we only have to get it right once, instead of re-inventing this 
for every terminal driver.

 > They'd be classified as OUTRANGE, but really a
> portion of the pixel would be visible.  Agreed?  

If you refer to pixels only by their center (and a globally fixed size), 
then yes, that can be OUTRANGE without the pixel itself being completely 
obscured.   But exactly because it may be quite large, it's dangerous to 
assume you can just plot it and expect the terminal driver to resolve 
this peacefully.  The bug we're discussing demonstrates quite nicely 
just how wrong that can go.

> But, unlike pm3d, there is no easy way for the core to create portions 
> of a pixel because of the nature of image data.  

Then maybe that nature of image data has to be re-thought.

> This is why I said a portion of a pixel might be extending off the 
> viewable boundary.  

That may still be fine.  What's definitely not fine is if the coordinate 
of the pixel that you output to the driver is not just outside the graph 
box, but actually off the page.

Re: Bug in image code ?

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

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.

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

Not by default, but it can be made to be.

>>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.

That's a side issue.  'set term png size 40000,30000' will fail just as 
spectacularly ('test' on that one just crashed this machine) ;->

> 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".

The docs already hint that it may not be the best of all imaginable 
ideas to set size to something larger than 1.0.  But I don't think that 
it should be forbidden.

Re: Explicit rgb colors [was Re: historysize]

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

On Wednesday 17 August 2005 10:09 am, Theo Hopman wrote:
> Ethan Merritt wrote:
> > Could you try your test case for these two output settings:
> > 
> > 	set term png
> > 	set term png truecolor
> > 
> > and see if it makes a difference?
> 
> Done. See the attached files. Notice the truecolor option gives almost 
> correct results, except for the glaringly obvious red dot which should 
> be white. 

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.


> 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.

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".

 
> 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.

Since (I think) truecolor png does work, I think this demonstrates that
your approach is valid.  We may have to tweak the palette code in other
drivers, but since we have a working one to guide us that should be
possible.

-- 
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...>]

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.  An extension to the debug.trm that checks each and 
every coordinate passed to it (plus options that let you change the 
sizes it reports to the core) might be in order, to ease testing of such 
things a bit.

>>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.

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.

Re: Explicit rgb colors [was Re: historysize]

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

Ethan Merritt wrote:
> I would need to see what you tried in more detail, but I would guess
> another issue may arise here - that of "nearest color" approximations
> done by the output devices or libraries themselves, and hence not really
> under our control.
> 
> Could you try your test case for these two output settings:
> 
> 	set term png
> 	set term png truecolor
> 
> and see if it makes a difference?

Done. See the attached files. Notice the truecolor option gives almost 
correct results, except for the glaringly obvious red dot which should 
be white. 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. As `set term png` says, it's only using 157 palette 
positions for the colourbox. The green channel goes through 256 
oscillations over the cbrange, so the palette sampling is almost certain 
  not to give the desired results. Blue doesn't even bear thinking 
about. Other paletted terminals (postscript, x11) give similar 
undesirable results.

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.

THeo

Re: Explicit rgb colors [was Re: historysize]

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

On Wednesday 17 August 2005 07:04 am, Theo Hopman wrote:
> > 
> >   rgb(r,g,b)=int(r*65536)+int(g*256)+int(b)
> >   r(gray)=int(2.**24*gray)/65536/256.
> >   g(gray)=int(2.**24*gray)%65536/256/256.
> >   b(gray)=int(2.**24*gray)%256/256.
> >   set palette color model RGB functions r(gray),g(gray),b(gray)
> >   set cbrange [0:2.**24-1]
> >   unset colorbox
> >   splot 'colour-data.txt' using 1:2:3:(log($4)) \
> >       with points pointtype 6 pointsize variable lc("black"), \
> >     '' using 1:2:3:(rgb($1,$2,$3)) \
> >       with points pointtype 7 palette
> 
> Grr. This works in theory, but not in practise, and the (wrong) results 
> are different on different terminals. I suspect that the rapidly varying 
> rgb() function is being sampled at a relatively low frequency to get a 
> limited set of grey values. The binning of the rgb() values causes wrong 
> (encoded) gravy values to be given to the r(), g() and b() functions, 
> resulting in incorrect colours -- red is almost right, but green is 
> wrong, and is useless.

I would need to see what you tried in more detail, but I would guess
another issue may arise here - that of "nearest color" approximations
done by the output devices or libraries themselves, and hence not really
under our control.

Could you try your test case for these two output settings:

	set term png
	set term png truecolor

and see if it makes a difference?



-- 
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 05:27 am, Hans-Bernhard Broeker wrote:
> 
> Signed vs. unsigned issues plague the gnuplot source quite a bit.

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.

> And try to remember that we have at least some drivers 
> where
> 
> 	INT_MAX < term->xmax < UINT_MAX.

Are you sure?  Which ones?



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

povray patch submitted (was : Bug in image code ? )

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

    It's on sourceforge !

--
    Ga=EBl

Re: Bug in image code ?

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

Ga=EBl Varoquaux wrote:

>     I feel really stupid : I do not know how to do a "patch". I think i=
t
> involves the "diff" program, but I have not been succesfull at make it
> give the right kind of output=20

>     and that does not look like the patches I download from sourceforge=
=2E

You want to use something like

	diff -urp old_directory new_directory

instead.  If you have added any files (like 'povray.trm'), also check=20
out options -N and --unidirectional-new-file in the 'diff'=20
documentation.  For diffs that are made not for patching, but just for=20
looking at what you did, it often helps to use options -w and -B, too,=20
so unimportant re-indentations of source code don't show up in the output=
:

	diff -uwBrp old new

Re: Bug in image code ?

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

On Wed, Aug 17, 2005 at 09:54:16AM -0500, Daniel J Sebald wrote:
>  Is POV-Ray v3.7.beta.8 on the web page http://www.povray.org/
> what we are talking about to utilize the povray patch?=20

    Any povray above or including 3.5 would do the trick.=20
=20
> (Could you put the patch on the SourceForge page?)

    I feel really stupid : I do not know how to do a "patch". I think it
involves the "diff" program, but I have not been succesfull at make it
give the right kind of output : I get something that look like :

""""""""""""""""""""""""""""""""""""""""""""""""""""""
diff -r gnuplot/src/makefile.all gnuplot-patch/src/makefile.all
29c29
< $(T)win.trm $(T)x11.trm $(T)xlib.trm
---
> $(T)win.trm $(T)x11.trm $(T)xlib.trm $(T)povray.trm
diff -r gnuplot/src/makefile.awc gnuplot-patch/src/makefile.awc
29c29
< $(T)win.trm $(T)x11.trm $(T)xlib.trm
---
> $(T)win.trm $(T)x11.trm $(T)xlib.trm $(T)povray.trm
Only in gnuplot-patch/term: povray.trm
""""""""""""""""""""""""""""""""""""""""""""""""""""""

    and that does not look like the patches I download from sourceforge.

--
    Ga=EBl

Re: Bug in image code ?

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

Ga=EBl Varoquaux wrote:
>     Povray terminal has :
> #define POVRAY_XMAX (4096)
> #define POVRAY_YMAX (4096)
>=20
> and=20
> #define POVRAY_HCHAR (POVRAY_XMAX/60)
>=20
>     And, as a comparison, postscript terminal has :
> #define PS_XMAX (10*720)
>=20
> #define PS_HCHAR (14*PS_SC*6/10)
>=20
> where PS_SC is given by :
> #define PS_SC 10
>=20
> So t->xmax =3D 4096 for povray, 7200 for postscript,
>    t->h_char ~ 68 for povray, 84 for postscript.

These numbers don't look unreasonable, I guess.

>     I don't see any obvious difference, but I think I have missed your
> point. I don't really understand where axis_array[axis].term_lower come=
s
> from, and what it is supposed to be.

All I'm saying is use a printf(...) or fprintf(stdout,...) to print out t=
he values to perhaps pinpoint where the negative number is occurring.  (W=
hich you did.)  Is POV-Ray v3.7.beta.8 on the web page http://www.povray.=
org/ what we are talking about to utilize the povray patch?  (Could you p=
ut the patch on the SourceForge page?)

Dan

Re: Explicit rgb colors [was Re: historysize]

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

Theo Hopman wrote:
> `set palette functions` would work well here. The following assumes 8 
> bits for each component, but can be modified to handle more. It also 
> assumes that the r,g,b components are specified in the data file as 
> integers from 0--255.
> 
>   rgb(r,g,b)=int(r*65536)+int(g*256)+int(b)
>   r(gray)=int(2.**24*gray)/65536/256.
>   g(gray)=int(2.**24*gray)%65536/256/256.
>   b(gray)=int(2.**24*gray)%256/256.
>   set palette color model RGB functions r(gray),g(gray),b(gray)
>   set cbrange [0:2.**24-1]
>   unset colorbox
>   splot 'colour-data.txt' using 1:2:3:(log($4)) \
>       with points pointtype 6 pointsize variable lc("black"), \
>     '' using 1:2:3:(rgb($1,$2,$3)) \
>       with points pointtype 7 palette

Grr. This works in theory, but not in practise, and the (wrong) results 
are different on different terminals. I suspect that the rapidly varying 
rgb() function is being sampled at a relatively low frequency to get a 
limited set of grey values. The binning of the rgb() values causes wrong 
(encoded) gravy values to be given to the r(), g() and b() functions, 
resulting in incorrect colours -- red is almost right, but green is 
wrong, and is useless.

THeo

Re: Explicit rgb colors [was Re: historysize]

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

>    rgb(r,g,b)=int(r*65536)+int(g*256)+int(b)
>    r(gray)=int(2.**24*gray)/65536/256.
>    g(gray)=int(2.**24*gray)%65536/256/256.
>    b(gray)=int(2.**24*gray)%256/256.
>    set palette color model RGB functions r(gray),g(gray),b(gray)
>    set cbrange [0:2.**24-1]
>    unset colorbox
>    splot 'colour-data.txt' using 1:2:3:(log($4)) \
>        with points pointtype 6 pointsize variable lc("black"), \
>      '' using 1:2:3:(rgb($1,$2,$3)) \
>        with points pointtype 7 palette

Wow, that's pretty neat. I'm impressed.

> The point types are chosen to give hollow and filled circles 
> respectively on the x11 terminal. Unfortunately it does not seem to be 
> possible to have varying point sizes _and_ colours set independently of 
> the z value.

No, Ethan is right on this one. Something like:

splot 'tmp.txt' using 1:2:3:(log($4)):(rgb($1,$2,$3)) \
       with points pointtype 7 pointsize variable palette

works a treat.

If only gnuplot did a depth sort on the data before plotting it....

Rob
-- 
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: Bug in image code ?

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

Ga=EBl Varoquaux wrote:
> With the standard terminal drivers (x11, post, png) this works without =
a
> flaw, but while working on the povray terminal, on the image code, I no=
ted
> that corner[0].x ends up being negative ! But it is a unsigned int !!

I.e. it's not really negative.  It'll just look negative if you somewhat
incorrectly cast it to a signed value, which is what a printf("%d") will =

  do behind your back.

Such a value being presented to the terminal driver is plain and simply=20
*wrong*, and the error was introduced by the core code: it computed a=20
pixel position that is outside the page boundaries and tried to draw=20
there.  That's a bug.  There are some areas where we can't really help=20
it, like with parts of text that may end up outside the page because we=20
don't really know how large they'll be in the output.  For pixel=20
positions passed to term->vector() or similar functions, it's unacceptabl=
e.

> ridiculously high value printed. Printing it as an integer solves the
> problem,=20

No, it doesn't.  It just obfuscates it.  A POVray driver may not=20
actually care if you try to draw outside the page --- other drivers do,=20
and the core code must never assume it can step outside that border.

File based terminal behaviour

[Gareth W. <gw...@ca...>]

Hi,

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.

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.

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?


Many thanks for your help,

Gareth

Re: Bug in image code ?

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

Ga=EBl Varoquaux wrote:

>     I don't see any obvious difference, but I think I have missed your
> point. I don't really understand where axis_array[axis].term_lower come=
s
> from, and what it is supposed to be.

It's the lower border of the graph box, in terminal coordinates.  In=20
other words, for axis=3DFIRST_Y_AXIS, this is where the x axis will be (i=
n=20
a 2D plot).  It must be non-negative, and smaller than term->ymax.=20
Similarly, axis_array[FIRST_X_AXIS].term_lower is the position of the y=20
axis, and must be between zero and term->xmax - 1, inclusive.

The values of these variables are computed in graphics.c:boundary() and=20
graph3d.c:boundary3d(), respectively, and used heavily by macros and=20
functions in the 'axis' module, like AXIS_MAP(), and its callers map_x() =

and map_y().

Signed vs. unsigned issues plague the gnuplot source quite a bit.  It's=20
so bad that I've long since given up trying to enable gcc's=20
-Wsign-compare even in my "picky mode" CFLAGS.  You have to tread=20
carefully there.  And try to remember that we have at least some drivers =

where

	INT_MAX < term->xmax < UINT_MAX.

so no, casting isn't generally going to help.

Re: Bug in image code ?

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

> For your povray terminal, what is the value of axis_array[axis].term_lo=
wer?=20
> Perhaps on other terminals these are large values (i.e., the terminal a=
xis=20
> has a noticable offset compared to its base coordinate system) and the=20
> int/unsigned issue becomes a non-issue.

    I didn't define any ! I wasn't even aware that such a thing existed
(I still don"t know gnuplot's code terribly well). However, grepping the
term directory seems to show me that only the x11 and the tkcanvas use
it, and only to read values out of it, not to assign anything to it.

    I tried to see how this "axis_array[axis].term_lower" was assigned.
It is assigned in axis.c, line 1314, by axis_graphical_range, and this
function is called in graph3d.c and graphics.c with argument alike
"xleft", itself defined, for instance by :

    xleft =3D (int) (xoffset * t->xmax
                   + t->h_char * (lmargin >=3D 0 ? lmargin : 2));

    So what your are telling me is indeed that my t->xmax, and t->h_char
are ill defined ?

    Povray terminal has :
#define POVRAY_XMAX (4096)
#define POVRAY_YMAX (4096)

and=20
#define POVRAY_HCHAR (POVRAY_XMAX/60)

    And, as a comparison, postscript terminal has :
#define PS_XMAX (10*720)

#define PS_HCHAR (14*PS_SC*6/10)

where PS_SC is given by :
#define PS_SC 10

So t->xmax =3D 4096 for povray, 7200 for postscript,
   t->h_char ~ 68 for povray, 84 for postscript.

    I don't see any obvious difference, but I think I have missed your
point. I don't really understand where axis_array[axis].term_lower comes
from, and what it is supposed to be.

--
    Ga=EBl

Re: historysize

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

Daniel J Sebald wrote:
> [Hans' point]
>> Now imagine somebody who just happens to have an old gnuplot script
>> that defines all of the above variables equals to 5.  Or to 1/0, for that
>> matter, or 1.0e300.

> My first question is Why are you defining "unlimited" to mean 5?  

I'm not.  But some user very well might have a perfectly valid reason 
for doing so.  He might even have decided to use it as an expression in 
some place where the current code expects a number, just because he 
could.  This would be even worse with the single-letter alternatives 
I've seen mentioned elsewhere in this thread.

 > Second question is how popular is the redefining of keywords?

It's not --- because it's impossible.  But OTOH, "unlimited" has never 
been a keyword in gnuplot before, so if you introduce it now, you always 
run the risk of colliding with existing user-defined variables or functions.

The point is that any syntax that allows either a keyword or a number in 
a given position of the command introduces a parsing ambiguity, because 
we generally allow numeric variables to be used in *every* place where a 
numeric constant could be, and such variables are essentially 
indistinguishable from keywords.

User-defined variables and functions have been in gnuplot effectively 
forever.  Which means that in case of a parsing conflict, they must take 
precedence, or we risk breaking users' scripts for no valid reasons.

Re: Explicit rgb colors [was Re: historysize]

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

On Tuesday 16 August 2005 12:04 pm, Theo Hopman wrote:
> Unfortunately it does not seem to be 
> possible to have varying point sizes _and_ colours set independently of 
> the z value.

It is possible.  That was the example I posted earlier.
The colour is taken from the 4th 'using' spec;
the size is taken from the 5th spec.


-- 
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...>]

Ethan Merritt wrote:

> I'd have to think about whether there is a straight-forward way
> to implement the notion "rgb triplet generated by function and 
> then assigned to linecolor".  It may be possible, but I don't
> off the top of my head see how it would fit into the current
> scheme.  Which is to say, it may be a nightmare to implement
> even if it's a good idea from the perspective of user interface.

It seems to me Rob wants something like the `rgbimage` plotting style, 
where x,y,z and r,g,b are specified independently, but not limited to a 
rectangular sampling grid.

> If you have a specific set of discrete colors, then I think what you
> need to do for perfect accuracty is to define a discrete palette that
> consists of exactly these colors.  Let's say you discretize to 128
> colors, and define a palette of size 128.  Then you can specify your
> point colors by choosing directly from this palette:
> 
> 	rgb(x,y,z) = some-function-that-generates-the-palette-index
> 
> 	plot <foo> using 1:2:3:(rgb($1,$2,$3)) lt palette

`set palette functions` would work well here. The following assumes 8 
bits for each component, but can be modified to handle more. It also 
assumes that the r,g,b components are specified in the data file as 
integers from 0--255.

   rgb(r,g,b)=int(r*65536)+int(g*256)+int(b)
   r(gray)=int(2.**24*gray)/65536/256.
   g(gray)=int(2.**24*gray)%65536/256/256.
   b(gray)=int(2.**24*gray)%256/256.
   set palette color model RGB functions r(gray),g(gray),b(gray)
   set cbrange [0:2.**24-1]
   unset colorbox
   splot 'colour-data.txt' using 1:2:3:(log($4)) \
       with points pointtype 6 pointsize variable lc("black"), \
     '' using 1:2:3:(rgb($1,$2,$3)) \
       with points pointtype 7 palette

The point types are chosen to give hollow and filled circles 
respectively on the x11 terminal. Unfortunately it does not seem to be 
possible to have varying point sizes _and_ colours set independently of 
the z value.

THeo

Re: Bug in image code ?

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

Ga=EBl,

For your povray terminal, what is the value of axis_array[axis].term_lowe=
r?  Perhaps on other terminals these are large values (i.e., the terminal=
 axis has a noticable offset compared to its base coordinate system) and =
the int/unsigned issue becomes a non-issue.

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

Dan

Re: Bug in image code ?

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

You may have found a bug.  OK, let's see.

I haven't looked at any data or examples, but my initial suspicion is tha=
t although the following

> line 3777 : fprintf(gppsfile, "%d %d translate\n", corner[0].x, corner[=
0].y);
>=20
>     Why %d and not %u ?

is a conflict, unless corner[0].x is very large (i.e., the highest bit ch=
anges from 0 to 1) it will not print an incorrect value.

I do notice that corner.x and corner.y are unsigned int as part of gpiPoi=
nt.  In 'graphics.c' there is map_x() used to assign a value to corner.x =
.  However, map_x() is

#define map_x(x) AXIS_MAP(x_axis, x)

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

I.e., not unsigned.  So there may be a problem here.  I think it wouldn't=
 be unlikely that somehow this could be a negative value, if only due to =
rounding or whatnot.

So the question here may be What world should corner.x and corner.y live =
in?  Signed or unsigned?  I'm not sure I put too much thought into this o=
riginally.  I may have just patterned the function after that for filled =
polygons

_filled_polygon(int points, gpiPoint *corners)

I'll have to look at this when I have more time.

Thanks,

Dan


Ga=EBl Varoquaux wrote:
>     I have found a strange behaviour of the image code.=20
>     Here is a minimal example :
>=20
> set xrange [-10:137]
> set yrange [-10:157]
>=20
> unset colorbox
> plot 'blutux.rgb' binary array=3D128x128 flip xy \
> format=3D'%uchar%uchar%uchar' every 64:16 using ($1+$2+$3) with image
>=20
>=20
> With the standard terminal drivers (x11, post, png) this works without =
a
> flaw, but while working on the povray terminal, on the image code, I no=
ted
> that corner[0].x ends up being negative ! But it is a unsigned int !!
> The other terminals use it by calling it "(int) corner[0].x", thus
> forcing the conversion to a negativ integer. However if I put a=20
> "fprintf(gpoutfile, "corner[0].x : %u\n",corner[0].x)" I get a
> ridiculously high value printed. Printing it as an integer solves the
> problem, and this is how I worked around this.
>     I suspect this problem is lying around in other places (I think I
> might have seen it elsewhere, but it is hard to trick gnuplot into
> making a negative value for a coordinate). Maybe those "(int)" casts in
> many of the terminal drivers are just hiding more bug.
>     I just had a look at the way the post terminal calls this :
> line 3777 : fprintf(gppsfile, "%d %d translate\n", corner[0].x, corner[=
0].y);
>=20
>     Why %d and not %u ?
>=20
> 	I am wrong or is there a problem here ? Maybe these should not
> be unsigned ints, but ints ? Checking for there sign seems a bit
> complicated.
>=20
> --
>     Ga=EBl
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
ices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
 QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20
>=20


--=20

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Explicit rgb colors [was Re: historysize]

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

On Tuesday 16 August 2005 10:46 am, Robert Hart wrote:
> On Tue, 2005-08-16 at 10:06 -0700, Ethan Merritt wrote:
> > On Tuesday 16 August 2005 09:58 am, Robert Hart wrote:
> > > On Tue, 2005-08-16 at 09:26 -0700, Ethan Merritt wrote:
> > > 
> > > > That works, or would if you put parens around the expression:
> > > >     set pm3d
> > > >     splot "data" using 1:2:3:(rgb($1,$2,$3)) with lines
> > > > 
> > > 
> > > Are you sure? This just gives: undefined function rgb.
> > 
> > I assumed that "rgb" was a user-defined function that assigned
> > an rgb color on the basis of 3D coords x, y, and z.
> 
> Maybe I'm missing something really obvious here? I don't understand what
> you mean by "assigned an rgb color". How could I make a function return
> an rgb colour?

One way is to define a palette that maps [0:1] onto the "hue" parameter
of a color wheel. See the demo "colorwheel.dem". 

 
> I want to plot my data such that the colour of each point is defined by:
> r=x
> g=y
> b=z
> 
> Now as I understand it, rgb(some colour specifier) is the gnuplot way of
> specifying an arbitrary colour as in:
> 
> plot sin(x) lc rgb("salmon")

No, there is no such function currently.
Instead there is a keyword "rgb" that controls the parsing of the
next token on the line.

I'd have to think about whether there is a straight-forward way
to implement the notion "rgb triplet generated by function and 
then assigned to linecolor".  It may be possible, but I don't
off the top of my head see how it would fit into the current
scheme.  Which is to say, it may be a nightmare to implement
even if it's a good idea from the perspective of user interface.

> Specifically what I'm trying to do is visualise the gamut of colours
> used in an image file, such as a photo. I used Imagemagick to quantise
> the number of discrete colours down to a more manageable level, and then
> for each unique colour count how many pixels are of each colour.
> 
> I then want to visualise this in 3D by plotting a point at
> (x,y,z)=(r,g,b) with pointsize log(count) and colour (r,g,b)=(r,g,b)
> 
> err... I'm not sure how else to explain.

If you have a specific set of discrete colors, then I think what you
need to do for perfect accuracty is to define a discrete palette that
consists of exactly these colors.  Let's say you discretize to 128
colors, and define a palette of size 128.  Then you can specify your
point colors by choosing directly from this palette:

	rgb(x,y,z) = some-function-that-generates-the-palette-index

	plot <foo> using 1:2:3:(rgb($1,$2,$3)) lt palette


I don't claim that this is particularly convenient, but it may be
the best you can do using the current code.



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