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

Re: it seems my Gnuplot 4.0 didn't read my ~/.Xdefaults

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

I think you may misunderstand how x11 works.

(1)
gnuplot (or any other x11 application) does not read the .Xdefaults
file by itself.   Instead, the x11 server reads the file when you
begin a new X-session, and applies the values in finds there to
answer queries from any applications (like gnuplot) that run later.

So editing the .Xdefaults has no automatic effect until the
next x-session.  You can force an update of the x-session values
by typing:
	xrdb -merge < ~/.Xdefaults

Even that, however, will not necessarily affect programs that
are already running. 

(2)
Setting a value for some particular X resource can only have
an effect if a corresponding application actually asks for that
value by name.  gnuplot does have a list of X resource values
that it asks for, but your "gnuplot*line30Width", for instance,
is not one of them.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: suggestion on axis ratios

[James R. V. Z. <jr...@co...>]

"Apolonija Hunkins" <apo...@ca...> wrote:
> Georg wrote:
>> orthogonal grid lines look distorted when the aspect ratio of the
>> section (related to the both axis) is not equal to one.
> 
>the solution:
>
>	set size ratio -1

It would be nice if this worked for splot too.

                 - Jim Van Zandt

Re: it seems my Gnuplot 4.0 didn't read my ~/.Xdefaults

[<br...@ph...>]

michele carlini wrote:
> I wrote my own ~/.Xdefaults since I have to plot sth like 20 graphs.

Incorrect conclusion.  Just because you have many different graphs 
doesn't mean that changing X resources is necessary or helpful in 
distinguishing them.  That's what the style arguments in the plot 
command are for.

> My intention was to keep the same line style while changing colours for the
> first 10 graphs... then to keep another line style & changing colours for the
> next 10 graphs... and so on

And what made you think you could specify that many line styles 
independently in your .Xdefaults?

Gnuplot Question

[<nic...@vo...>]

Hello,
I have a Gnuplot question that I would like to submit for you. I want to plot a data file
using pm3d and view map. In this data file the two first column are x and y and I will call 
the third and fourth column R1 and R2 (with the relation R1+R2=1). My problem is that I 
want to attribute one different color for each column R1 and R2 and then  splot on view map
(x,y,R1+R2).Well maybe I am not so clear...I give an example: if the first line of my data 
file is x=0,y=0,R1=0.5,R2=0.5 and I attribute yellow to R1 and blue to R2, R1+R2 will be green. 
Is it possible to draw such map ?? I hope I was clear enough...
Thank you for your great 'faq' internet site and that would be really kind of you to help me.
Best regards
Nicolas Dupuis

it seems my Gnuplot 4.0 didn't read my =?utf-8?b?fi8uWGRlZmF1bHRz?=

[michele c. <mi...@uk...>]

hi there

I wrote my own ~/.Xdefaults since I have to plot sth like 20 graphs.

My intention was to keep the same line style while changing colours for the
first 10 graphs... then to keep another line style & changing colours for the
next 10 graphs... and so on

You can find here below my .Xdefault file.
Please let me know where I did wrong.
thank you in advance

cheers

mic

----------------------------------
gnuplot*background: white
gnuplot*textColor: black
gnuplot*borderColor: black
gnuplot*axisColor: black
gnuplot*line1Color: blue
gnuplot*line2Color: red
gnuplot*line3Color: green
gnuplot*line4Color: magenta
gnuplot*line5Color: cyan
gnuplot*line6Color: sienna
gnuplot*line7Color: black
gnuplot*line8Color: orange
gnuplot*line9Color: coral
gnuplot*line10Color: black, 0.5
gnuplot*line11Color: blue
gnuplot*line12Color: red
gnuplot*line13Color: green
gnuplot*line14Color: magenta
gnuplot*line15Color: cyan
gnuplot*line16Color: sienna
gnuplot*line17Color: black
gnuplot*line18Color: orange
gnuplot*line19Color: coral
gnuplot*line20Color: black, 0.5
gnuplot*line21Color: blue
gnuplot*line22Color: red
gnuplot*line23Color: green
gnuplot*line24Color: magenta
gnuplot*line25Color: cyan
gnuplot*line26Color: sienna
gnuplot*line27Color: black
gnuplot*line28Color: orange
gnuplot*line29Color: coral
gnuplot*line30Color: black, 0.5
gnuplot*borderWidth: 2
gnuplot*axisWidth: 2
gnuplot*line1Width: 0
gnuplot*line2Width: 0
gnuplot*line3Width: 0
gnuplot*line4Width: 0
gnuplot*line5Width: 0
gnuplot*line6Width: 0
gnuplot*line7Width: 0
gnuplot*line8Width: 0
gnuplot*line9Width: 0
gnuplot*line10Width: 0
gnuplot*line11Width: 0
gnuplot*line12Width: 0
gnuplot*line13Width: 0
gnuplot*line14Width: 0
gnuplot*line15Width: 0
gnuplot*line16Width: 0
gnuplot*line17Width: 0
gnuplot*line18Width: 0
gnuplot*line19Width: 0
gnuplot*line20Width: 0
gnuplot*line21Width: 0
gnuplot*line22Width: 0
gnuplot*line23Width: 0
gnuplot*line24Width: 0
gnuplot*line25Width: 0
gnuplot*line26Width: 0
gnuplot*line27Width: 0
gnuplot*line28Width: 0
gnuplot*line29Width: 0
gnuplot*line30Width: 0
gnuplot*borderDashes: 0
gnuplot*axisDashes: 16
gnuplot*line1Dashes: 0
gnuplot*line2Dashes: 0
gnuplot*line3Dashes: 0
gnuplot*line4Dashes: 0
gnuplot*line5Dashes: 0
gnuplot*line6Dashes: 0
gnuplot*line7Dashes: 0
gnuplot*line8Dashes: 0
gnuplot*line9Dashes: 0
gnuplot*line10Dashes: 0
gnuplot*line11Dashes: 44
gnuplot*line12Dashes: 44
gnuplot*line13Dashes: 44
gnuplot*line14Dashes: 44
gnuplot*line15Dashes: 44
gnuplot*line16Dashes: 44
gnuplot*line17Dashes: 44
gnuplot*line18Dashes: 44
gnuplot*line19Dashes: 44
gnuplot*line20Dashes: 44
gnuplot*line21Dashes: 4444
gnuplot*line22Dashes: 4444
gnuplot*line23Dashes: 4444
gnuplot*line24Dashes: 4444
gnuplot*line25Dashes: 4444
gnuplot*line26Dashes: 4444
gnuplot*line27Dashes: 4444
gnuplot*line28Dashes: 4444
gnuplot*line29Dashes: 4444
gnuplot*line30Dashes: 4444

Re: suggestion on axis ratios

[<br...@ph...>]

Georg wrote:

> The 'set size square' command only affects the lenght of the axis 'on
> the paper' but not in reality. Tics and axis lenghts have to be
> combined somehow.
> 
> Maybe there is already something in work or does even exist.

Either you don't ever read documentation, or you must be using an 
ancient version of gnuplot.  At least that's the only way I can imagine 
how you managed to find 'set size', with what you really wanted to do in 
mind, and not stumble across the solution:

	set size ratio -1

Re: new demo with cyan lines

[<br...@ph...>]

Ethan Merritt wrote:

> I will construct a full example pair if you like, but my observation
> is that in case such as the final plot in rgb_variable.dem, the axes
> are properly occluded by other plot elements if you draw them by
> including a dataset of  unit vectors in 3D, but not properly occluded
> if you draw them via the "set zeroaxis" command.

I don't think that would make a difference.  The problem is simpler: 
hidden3d doesn't try to hide points behind lines.  For actual points, 
that wouldn't be a problem: the probability of in infinitely small point 
actually coinciding with a zero-width line is zero.  The problem is that 
point symbols aren't zero-size, and lines aren't zero-width.  To fix 
that would take almost a rewrite of hidden3d.  I'm not sure we want to 
go there.

There's more wrong with those plot than just the hiding of the zeroaxis 
itself.  E.g. the direction of the tics on the "Green" (y) axis the 
wrong way round --- the tick labels are inside the plot, the ytics point 
outward, rather the opposite of what the sate of 'set ytics in' would 
suggest.

And the "Warning: Single isoline..." message from the pm3d code is 
getting rather in the way of rotating that plot via mouse.  That warning 
needs to be limited to at most a few displays per gnuplot session.

suggestion on axis ratios

[Georg <geo...@gm...>]

Dear Gnuplot Team !

I strongly appreciate your work and I got a suggestion for a (in my
mind important) feature.
I am working on grids for solving partial differential equations and
I have to check wether the grid lines are orthogonal to each other.

But orthogonal grid lines look distorted when the aspect ratio of the
section (related to the both axis) is not equal to one.
For example a section which shows eg. 10 units in x and 5 in y
direction.
The 'set size square' command only affects the lenght of the axis 'on
the paper' but not in reality. Tics and axis lenghts have to be
combined somehow.

Maybe there is already something in work or does even exist.
I do offer  my help! I hope the problem became clear at least.

Please answer me.


My best regards,

Georg Steidl
bavaria/germany

Re: gnuplot manual misprint (no.18)

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

> I found some points that seem to be misprints. I send the unified
> diff file for them.

Thanks, committed to cvs.

---
PM

Re: new demo with cyan lines

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

On Thursday 23 February 2006 02:40 am, Hans-Bernhard Br=F6ker wrote:
> Ethan A Merritt wrote:
> > But that reminds me of something else shown by the same demo.
> > The axes in a 3D plot with "set hidden3d" are never obscured
> > by the plotted surface.
>
> Which "axes" are you talking about there?  The only standard
> plot element that could fit that name, i.e. the scales on the
> borders, *are* hidden by the surface.

My apologies. I had forgotten that that plot used explicit arrows
rather than the zero-axis lines.

The plot which was annoying me was actually a different one,
the one I recently constructed for rgb_variable.dem;
when Daniel mentioned the plot in pointsize.dem, I falsely
concluded that it was a parallel case.

I will construct a full example pair if you like, but my observation
is that in case such as the final plot in rgb_variable.dem, the axes
are properly occluded by other plot elements if you draw them by
including a dataset of  unit vectors in 3D, but not properly occluded
if you draw them via the "set zeroaxis" command.
Quite probably a bug in the code I added myself.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: new demo with cyan lines

[<br...@ph...>]

Ethan A Merritt wrote:

> But that reminds me of something else shown by the same demo.
> The axes in a 3D plot with "set hidden3d" are never obscured
> by the plotted surface. 

Which "axes" are you talking about there?  The only standard
plot element that could fit that name, i.e. the scales on the borders,
*are* hidden by the surface.

The only things that don't get hidden by the surface are arrows.  They 
would need special handling added to hidden.dem, and it would almost 
certainly still fail to correctly hide the point, especially if the 
terminal draws its own arrows.

Re: new demo with cyan lines

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

Ethan A Merritt wrote:
> On Monday 20 February 2006 11:36 pm, Daniel J Sebald wrote:
> 
>>On the new demo in 'pointsize.dem', the globe has cyan 
>>longitude/latitude (x11) and there are some lines and 
>>arrows apparently marking axes.  But the lines are cyan as 
>>well and things look confusing.  Is there a better color for the axes?   
> 
> 
> Whatever.
> 
> But that reminds me of something else shown by the same demo.
> The axes in a 3D plot with "set hidden3d" are never obscured
> by the plotted surface. That tends to destroy the visual impression
> of depth.

That was kind of my point.  The eye doesn't immediately grasp what that visual is supposed to be.  Something just isn't right about it.

Dan

Re: new demo with cyan lines

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

On Monday 20 February 2006 11:36 pm, Daniel J Sebald wrote:
> On the new demo in 'pointsize.dem', the globe has cyan 
> longitude/latitude (x11) and there are some lines and 
> arrows apparently marking axes.  But the lines are cyan as 
> well and things look confusing.  Is there a better color for the axes?   

Whatever.

But that reminds me of something else shown by the same demo.
The axes in a 3D plot with "set hidden3d" are never obscured
by the plotted surface. That tends to destroy the visual impression
of depth.  I think that in this case the axis vectors should be
handled by the hidden3d code, just like any other plot vectors.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: slow drawing with large images

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

On Wednesday 22 February 2006 06:37 am, Bastian Maerkisch wrote:
> When drawing large images (binary and ascii) gnuplot is veeeery
> slow on my (windows) machine. E.g. with an image (RGB) of 1024*256
> pixels it takes about >5.5s to output on any terminal.
> 
> Profiling reveals that gnuplot spends >75% of it's time in
> gp_realloc()  <--  cp_extend() <--  get_data().

OK, I've done a proper profiling run under linux (Mandriva 2006).

lascaux [141] cat rgbimage.dem
plot '< convert sen.jpeg avs:-' binary filetype=avs with rgbimage
replot
replot
replot
replot
replot

lascaux [142] identify sen.jpeg
sen.jpeg JPEG 1280x899 DirectClass 256kb 0.090u 0:01

Profiling output:
    %   cumulative   self              self     total
  6.81      6.39     6.39                             cb2gray (pm3d.c:174 @ 80c666c)
  5.53     11.57     5.19                             store2d_point (plot2d.c:842 @ 80b8711)
  4.66     15.94     4.37                             X11_image (x11.trm:1868 @ 80efae3)
  3.74     19.45     3.51                             cb2gray (pm3d.c:180 @ 80c66ee)
  3.50     22.73     3.28                             cb2gray (pm3d.c:178 @ 80c66d0)
  3.09     25.63     2.90                             store2d_point (plot2d.c:841 @ 80b849d)
  2.87     28.32     2.69                             store2d_point (plot2d.c:843 @ 80b899e)
[snip 200 lines]
  0.00     93.81     0.00     6954     0.00     0.00  gp_realloc (alloc.c:295 @ 804bc00)
  0.00     93.81     0.00     6930     0.00     0.00  cp_extend (plot2d.c:144 @ 80b587c)

> 
> Can anybody confirm this behaviour on non-windows machines?

No.  
Under linux the gp_realloc() takes 0 time for all intents and purposes.

Most time spent (19% net) is in routine store2d_point()  
Next largest chunk of time (14%) is in cb2gray()
After that no single routine stands out

> Or is this a problem of gp_realloc() on Windows?

No idea where the problem is under Windows.



Separate timing run (no profiling):

lascaux [2389] time ./gnuplot rgbimage.dem
1.854u 0.249s 0:02.70 77.4%     0+0k 0+0io 54pf+0w

So, 6 times through plotting a 1280x899 rgbimage takes less than
2 seconds including the file reading and program startup.
Your reported 5+ seconds for 1 plot of an image 1/3 that size
seems excessive any way you look at it.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: slow drawing with large images

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

Hans-Bernhard Br=F6ker wrote:
> Factor of 2 of waste is not really excessive.

Shouldn't be too bad.  Factor of 2 at worst.  As far as having reassign m=
emory, with images having the array size, one would know right away the e=
ventual number of points.  With binary data, one could make a reasonable =
guess based on file size.  With ascii data, not worth the trouble as the =
reading of ascii data is just as consuming as reassigning memory.

>  But if you don't like it,=20
> it can always be replaced by something like
>=20
>     new_size =3D (1.5 * old_size + 1000)
>=20
> Call me biased, but I suspect this code had better use the existing=20
> dynarray.h stuff instead.  I broke that code out of hidden3d for a=20
> reason, see?

Wasn't aware of it.

Dan

Re: slow drawing with large images

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

Bastian Maerkisch wrote:
> When drawing large images (binary and ascii) gnuplot is veeeery
> slow on my (windows) machine. E.g. with an image (RGB) of 1024*256
> pixels it takes about >5.5s to output on any terminal.
> 
> Profiling reveals that gnuplot spends >75% of it's time in
> gp_realloc()  <--  cp_extend() <--  get_data().
> 
> The crucial point is that the maximum increase of the points[]
> array is limited to 1000. Changing line 411 in plot2d.c
> 
> - cp_extend(current_plot, i + (i < 1000 ? i : 1000));
> + cp_extend(current_plot, i + i);
> 
> eliminates that problem, but uses exceedingly large amounts
> of memory.
> 
> Can anybody confirm this behaviour on non-windows machines?
> Or is this a problem of gp_realloc() on Windows?

In linux, even running through Octave, a 1024*256 image takes about .75 sec on a five year old pentium 3 (about 1 GHz, I forget memory speed).

I agree the linear expension rule is bad.  (In fact, in some cases with image one should be able to make a reasonable guess about the final number of points required.)

Why your system is so slow though, not sure?  With the 1000 rule and 1024*256 image, that means you'd execute cp_extend roughly 250 times.  (Not good.)  In that routine I see a TRACE_ALLOC() command which I'm sure is deactivated in my compilation.  Perhaps if you have that turned on by default, that's where the slowdown comes from.

Dan

Re: slow drawing with large images

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

I don't have time to do real profiling at the moment,
but a quick test under linux handles a 1280x1024 image
in 2.36 seconds using the current code, and 2.40 seconds
using your modified code. I.e. no significant difference.

echo "plot '< convert xxx.jpeg avs:-' binary filetype=avs with rgbimage" > bench.gnu
time gnuplot bench.gnu 
2.118u 0.260s 0:02.36 100.4%    0+0k 0+0io 0pf+0w
time gnuplot_new bench.gnu
2.129u 0.257s 0:02.40 98.7%     0+0k 0+0io 0pf+0w

But I agree that the current arbitrary limit of 
1000 additional bytes is foolish.

On Wednesday 22 February 2006 06:37 am, Bastian Maerkisch wrote:
> When drawing large images (binary and ascii) gnuplot is veeeery
> slow on my (windows) machine. E.g. with an image (RGB) of 1024*256
> pixels it takes about >5.5s to output on any terminal.
> 
> Profiling reveals that gnuplot spends >75% of it's time in
> gp_realloc()  <--  cp_extend() <--  get_data().
> 
> The crucial point is that the maximum increase of the points[]
> array is limited to 1000. Changing line 411 in plot2d.c
> 
> - cp_extend(current_plot, i + (i < 1000 ? i : 1000));
> + cp_extend(current_plot, i + i);
> 
> eliminates that problem, but uses exceedingly large amounts
> of memory.
> 
> Can anybody confirm this behaviour on non-windows machines?
> Or is this a problem of gp_realloc() on Windows?
> 
> Bastian
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: slow drawing with large images

[<br...@ph...>]

Bastian Maerkisch wrote:
> The crucial point is that the maximum increase of the points[]
> array is limited to 1000. 

I'm pretty sure that test is plain and buggily ass-backwards.
The general approach to avoid excessively frequent realloc()s is to 
double the allocation size each time you have to grow it.  I'm guessing 
here, but that business with 1000 is probably intended to avoid the 
early, rather pointless early stages of that process, i.e. to ensure 
that the allocation alwyas grows by *at least* 1000, not at most 1000.

> eliminates that problem, but uses exceedingly large amounts
> of memory.

Factor of 2 of waste is not really excessive.  But if you don't like it, 
it can always be replaced by something like

	new_size = (1.5 * old_size + 1000)

Call me biased, but I suspect this code had better use the existing 
dynarray.h stuff instead.  I broke that code out of hidden3d for a 
reason, see?

slow drawing with large images

[Bastian M. <bma...@we...>]

When drawing large images (binary and ascii) gnuplot is veeeery
slow on my (windows) machine. E.g. with an image (RGB) of 1024*256
pixels it takes about >5.5s to output on any terminal.

Profiling reveals that gnuplot spends >75% of it's time in
gp_realloc()  <--  cp_extend() <--  get_data().

The crucial point is that the maximum increase of the points[]
array is limited to 1000. Changing line 411 in plot2d.c

- cp_extend(current_plot, i + (i < 1000 ? i : 1000));
+ cp_extend(current_plot, i + i);

eliminates that problem, but uses exceedingly large amounts
of memory.

Can anybody confirm this behaviour on non-windows machines?
Or is this a problem of gp_realloc() on Windows?

Bastian

--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg

postscript image encode overlooked bit alignment in memory assignment

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

We obviously never tested this imshow(A,A,A) routine... found a bug in my image encoding for the palettes of size larger than 2^8 such that the routine adds a half byte per line:

	* term/post.trm(PS_encode_image):  The computation for the max number
	of required bytes for encoding the image didn't take into account that
	there is 8 bit alignment (potentially additional 7 bits) at the end
	of each image line.  The encoded image was written outside memory on
	the heap and corrupted when cleared.  Fixed, and added an assert()
	test, after the fact, to compare encode size against memory size.

This should be the last one for a while.

Thanks,

Dan

Re: bug in palette routine?

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

Petr Mikulik wrote:
>> There is also the bug fix for the interpolation, with a ChangeLog 
>> comment.
>>
>> Could someone please add these and then let me know when CVS has been 
>> updated.
> 
> 
> It is in cvs.

Thanks, I will have one more short bug fix for something else in a second.

> 
> I think you should become developer of gnuplot@SF so that you have 
> rights to contribute your code directly to cvs. (Hans-Bernhard or Lars 
> could add you.)

I've thought about it.  It's up to you.  But I kind of like having more computer science oriented people browse the code to sort of hash things out.  (I'm more the DSP/math type.)  Perhaps this summer if some larger group-oriented projects emerge.

Dan

Re: bug in palette routine?

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

> There is also the bug fix for the interpolation, with a ChangeLog comment.
>
> Could someone please add these and then let me know when CVS has been 
> updated.

It is in cvs.

I think you should become developer of gnuplot@SF so that you have rights to 
contribute your code directly to cvs. (Hans-Bernhard or Lars could add you.)

---
PM

Re: bug in palette routine?

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

Daniel J Sebald wrote:
> Petr Mikulik wrote:
> 
>>>> Attached is a patch to fix this bug.  It uses a bisecting method.  
>>>> Please check it over and test it.  You'll find that the 
>>>> imshow(A,A,A) now works but doesn't look to be the correct 
>>>> brightness.  We'll address that problem next.
>>
>>
>>
>> OK, now the patch, gnuplot does not crash.
>>
>> On the other hand, it shows the following garbage:
>>
>> octave|3> A = loadimage ("default.img");
>> octave|4> imshow(A,A,A);
>> gnuplot_x11: unknown command 
>> <.'.'.'<.<.<.>/>/>/$@0@0@0,@0@0@03@0@0@0;@0@0@0C@p@p@pJ@p@p@pR@p@p@pZ?p?p?pb>o>o>oi<n<n<nq9m9m9my:m:m:m:m:m:m8l8l8l8l8l8l9,9,9,9m9m9m 

I think I found this little easter egg.  After printing out tons of stuff I finally saw this for the buffer offset:

buff_offset = 0
i = 1250
buff_offset = 0
i = 1300
buff_offset = 193

DONE PAL
what is a makepal
total_chars = 6785

buff_offset = 0

This is from comments added to the hunk of 50 palette values sent through the pipe, and somewhere around the 1300 value the pipe paused for other traffic (the middle three lines came from the core fprintf) and only a partial buffer (buff_offset = 193) was read.  So, the shorter palettes were generally making it through in time, but not this longer one.

In the palette code there were these comments:

	read_input();  /*  FIXME: discarding status  */

which means that when a partial read was done the code continued on its merry way.  The partial read didn't advance the buffer, so there was all kinds of garbage left at the end.

Patch attached.

There is also the bug fix for the interpolation, with a ChangeLog comment.

Could someone please add these and then let me know when CVS has been updated.

Thank you,

Dan

new demo with cyan lines

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

On the new demo in 'pointsize.dem', the globe has cyan longitude/latitude (x11) and there are some lines and arrows apparently marking axes.  But the lines are cyan as well and things look confusing.  Is there a better color for the axes?

Dan

Re: bug in palette routine?

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

Petr Mikulik wrote:
>>> Attached is a patch to fix this bug.  It uses a bisecting method.  
>>> Please check it over and test it.  You'll find that the imshow(A,A,A) 
>>> now works but doesn't look to be the correct brightness.  We'll 
>>> address that problem next.
> 
> 
> OK, now the patch, gnuplot does not crash.
> 
> On the other hand, it shows the following garbage:
> 
> octave|3> A = loadimage ("default.img");
> octave|4> imshow(A,A,A);
> gnuplot_x11: unknown command 
> <.'.'.'<.<.<.>/>/>/$@0@0@0 ...

OK, I'm seeing that too, so we're consistent.  I think this is a bug different from the patch I sent.  I'll see if I can find that quick.

I see there is a strip along the right edge in the image that is not appearing.  It looks as though that last line is not being read in and is instead being interpretted as a command.  Could be an Octave problem.


> > Oh, btw, I made the patch behave similar to the existing routine in that it rounds up, like a ceil() function.  I didn't look closely, but perhaps you'd like the routine to be round(), unless that's been compensated for somewhere else already.
>
> I have no idea what you mean.

What I mean is that by rounding up, if the number of palette colors is of less precision than the value of "gray" that is continually passed in, rounding up will mean that the "zero" value will occur only if it exactly equals the zeroeth value in the palette as opposed.  An alternative might be instead the comparison

if ((sm_palette.gradient[tmpidx].pos + sm_palette.gradient[tmpidx+1].pos)/2 < gray)

that's all.  (I believe the tmpidx+1 above is safe from ever going out of range and causing a crash... tmpidx will never be maxidx - 1 as the bisecting algorithm is because the loop will break first.


> But it does not matter, please send me the patch as close as to the "traditional" octave or Matlab behaviour as possible.

Well, I think the choice should be in gnuplot, then adjust the Octave script appropriately.  So whatever you choose is fine.

Dan