gnuplot-beta Mailing List for gnuplot (Page 26)

I'm seeing something that puzzles me. I create a plot using this 
term line:

set term pngcairo size 762,600

Now I'm interested in retrieving the size of the PNG (which the 
venerable xv tells me really is 762 x 600). Using gnuplot 5.0.6 I 
get

GPVAL_TERM_XSIZE = 15240
GPVAL_TERM_YSIZE = 12000
GPVAL_TERM_SCALE = 20

and on division by 20 I get the size back OK. But using 5.2.8 I get

GPVAL_TERM_XSIZE = 15220
GPVAL_TERM_YSIZE = 11980
GPVAL_TERM_SCALE = 20

giving 761 x 599 on division by 20.

Is this inadvertant or is there a reason for the difference?

Allin Cottrell

Ethan A Merritt <me...@uw...> writes:

>     plot $D1 matrix nosurface,  $D2 using 1:2:3 notitle nocontour

YES! "nocontour" is the magic word. Thank you!

On Tuesday, 19 May 2020 22:52:48 PDT Dima Kogan wrote:
> Hi. I'm probably doing this wrong, but in case I'm not, can somebody
> give me a pointer?
> 
> I'm making an splot with "set view map". There're two things in the
> splot command:
> 
> - gridded data. this is for contours
> 
> - a line. the is just another thing to plot; no contours needed or
>   wanted
> 
> Gnuplot really wants to contour everything, so it gives me a warning
> aobut not being able to contour the line:
> 
>   "/tmp/tst.gp" line 15: warning: Cannot contour non grid data. Please use "set dgrid3d".
> 
> The plot works otherwise. How can I tell gnuplot what specifically I
> want contoured?

    set style data lines
    set contour
    plot $D1 matrix nosurface,  $D2 using 1:2:3 notitle nocontour

	Ethan


> A demo script:
> 
> 
> set view map
> set contour surface
> set cntrparam levels incremental 10,1,20
> splot '-' matrix with lines nosurface ,'-' using 1:2:3 notitle with lines lw 3
> 21.116659897839263 19.791039827138583 18.227675240475808
> 17.237090114458017 16.05638264955801 14.720006247692512
> 13.875609237866147 12.820842598325108 11.685987645475555
> 
> e
> .539 .853 0.0
> 0 .1706 0.0
> 0 .2986 0.0
> e
> 
> 
> Thanks!
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Hi. I'm probably doing this wrong, but in case I'm not, can somebody
give me a pointer?

I'm making an splot with "set view map". There're two things in the
splot command:

- gridded data. this is for contours

- a line. the is just another thing to plot; no contours needed or
  wanted

Gnuplot really wants to contour everything, so it gives me a warning
aobut not being able to contour the line:

  "/tmp/tst.gp" line 15: warning: Cannot contour non grid data. Please use "set dgrid3d".

The plot works otherwise. How can I tell gnuplot what specifically I
want contoured? A demo script:


set view map
set contour surface
set cntrparam levels incremental 10,1,20
splot '-' matrix with lines nosurface ,'-' using 1:2:3 notitle with lines lw 3
21.116659897839263 19.791039827138583 18.227675240475808
17.237090114458017 16.05638264955801 14.720006247692512
13.875609237866147 12.820842598325108 11.685987645475555

e
.539 .853 0.0
0 .1706 0.0
0 .2986 0.0
e


Thanks!

I would like to give people an -rc2 to test.

There have been no major changes since -rc1, but a few of them touch
the build + packaging pathway so it would be good to test them.

Bastian:  Did you figure out what the problem was with libgd + Windows 10?

Can someone comment on this issue - is it reproducible?
    Bug #2261 Text Size Depends on Windows Scale and Layout Setting
    https://sourceforge.net/p/gnuplot/bugs/2261/

Any other known issues?

	Ethan

Ethan A Merritt <me...@uw...> writes:

> The place where I can see it is a bit unclear is that "help set style fill"
> only says "see also 'set style rectangle'", which isn't much of a warning.
>
> I have now expanded that for 5.4 to read:
>
>    Note that there is a separate default fill style for rectangle objects.
>    See `set style rectangle`.
>
> Do you think that is OK, or is there something more or some additional
> place it should be expanded?

Yeah, I think that's a lot better. Can we replace "rectangle objects".
With "objects defined with 'set object rectangle'"? Otherwise it's not
clear whether we're talking about some generic 'object' or not.

Thanks much.

On Saturday, 2 May 2020 15:01:57 PDT Dima Kogan wrote:
> Hi. Thanks for the context.
> 
> I don't entirely follow the explanation, though. You're saying that "set
> style fill" kicks in when objects come from the plot and "set style
> rectangle" kicks in when objects come from "set object rectangle"?

Yes.

> My general feeling is that breaking backwards compatibility should be
> avoided at all costs, and we probably should leave this the way it is.
> After all, it has been this way, and you hear complaints very rarely.
> 
> One thing we SHOULD change is the docs. The impetus for this thread was
> that I was apparently looking at the wrong part of the docs, which told
> me the wrong thing. 

The information _is_ in there, but I can try to make it clearer. 

> If the interpretation above is correct, then "help
> set style rectangle" can say
> 
>   The default values correspond to solid fill with the background color
>   and a black border. Note that this default applies to rectangles
>   created with "set object". Rectangles from data are controlled by "set
>   style fill", and are empty by default.
> 
> Or something like that. Is that reasonable?

It already does say something like that, doesn't it?
The current text (version 5.2.8) reads

 Rectangles defined with the `set object` command can have individual styles.
 However, if the object is not assigned a private style then it inherits a
 default that is taken from the `set style rectangle` command.
 [syntax and examples snipped]
 The default values correspond to solid fill with the background color and a
 black border.

The place where I can see it is a bit unclear is that "help set style fill"
only says "see also 'set style rectangle'", which isn't much of a warning.

I have now expanded that for 5.4 to read:

   Note that there is a separate default fill style for rectangle objects.
   See `set style rectangle`.

Do you think that is OK, or is there something more or some additional
place it should be expanded?

	Ethan

Hi. Thanks for the context.

I don't entirely follow the explanation, though. You're saying that "set
style fill" kicks in when objects come from the plot and "set style
rectangle" kicks in when objects come from "set object rectangle"?

My general feeling is that breaking backwards compatibility should be
avoided at all costs, and we probably should leave this the way it is.
After all, it has been this way, and you hear complaints very rarely.

One thing we SHOULD change is the docs. The impetus for this thread was
that I was apparently looking at the wrong part of the docs, which told
me the wrong thing. If the interpretation above is correct, then "help
set style rectangle" can say

  The default values correspond to solid fill with the background color
  and a black border. Note that this default applies to rectangles
  created with "set object". Rectangles from data are controlled by "set
  style fill", and are empty by default.

Or something like that. Is that reasonable?

On Friday, 1 May 2020 15:38:15 PDT Ethan A Merritt wrote:
> On Friday, 1 May 2020 14:04:22 PDT Dima Kogan wrote:
> > Hi. The docs (help fillstyle) say that the default fillstyle is "empty".
> > But this isn't what's happening:
> > 
> >   set grid
> >   set object rectangle from 0,0 to 1,1
> >   plot [-1:2][-1:2] x
> > 
> > Note that the grid lines do not show up behind the rectangle. If I
> > explicitly add "fillstyle empty" to the rectangle definition, you get
> > the transparent rectangle.
> 
> Going way back to the initial implementation of rectangle as objects,
> the default was "solid fill with background color", which is not the
> same thing as "empty". This is true for all object types.
> 
> gnuplot> help set style rectangle
>  Rectangles defined with the `set object` command can have individual styles.
>  However, if the object is not assigned a private style then it inherits a
>  default that is taken from the `set style rectangle` command.
>  [snip]
>  The default values correspond to solid fill with the background color and a
>  black border. 
> 
> The idea was to have separate global fill styles for each object type.
> In retrospect that might not have been the best idea, but that's what we have.
> In retrospect it might also have been better to have all global fill styles
> start with the same default.
> 
> What do you think?
> Is it worth breaking backward compatibility to change this?
> I'm inclined to say yes, but only in the development verion, not for 5.4.   
> Do away with separate fillstyles?
> Keep them but give them all the same default properties?

After some thought, I'm coming around to thinking that if we do change it,
5.4 would be a good time.   It could be a bullet point in the Release Notes

o CHANGE - objects (rectangles, circles, etc) now default to fillstyle "empty"
                    rather than solid fill with background color.   

	Ethanμ

On Friday, 1 May 2020 14:04:22 PDT Dima Kogan wrote:
> Hi. The docs (help fillstyle) say that the default fillstyle is "empty".
> But this isn't what's happening:
> 
>   set grid
>   set object rectangle from 0,0 to 1,1
>   plot [-1:2][-1:2] x
> 
> Note that the grid lines do not show up behind the rectangle. If I
> explicitly add "fillstyle empty" to the rectangle definition, you get
> the transparent rectangle.

Going way back to the initial implementation of rectangle as objects,
the default was "solid fill with background color", which is not the
same thing as "empty". This is true for all object types.

gnuplot> help set style rectangle
 Rectangles defined with the `set object` command can have individual styles.
 However, if the object is not assigned a private style then it inherits a
 default that is taken from the `set style rectangle` command.
 [snip]
 The default values correspond to solid fill with the background color and a
 black border. 

The idea was to have separate global fill styles for each object type.
In retrospect that might not have been the best idea, but that's what we have.
In retrospect it might also have been better to have all global fill styles
start with the same default.

What do you think?
Is it worth breaking backward compatibility to change this?
I'm inclined to say yes, but only in the development verion, not for 5.4.   
Do away with separate fillstyles?
Keep them but give them all the same default properties?


There is another very messy historical artifact about fill styles that
goes with this and affects many many places in the code. 

Example:     plot FOO with candlesticks lt 3

At the time it seemed reasonable that if the fillstyle was "empty",
this meant to use the color of linetype 3 for the border of the
candlestick boxes. But if the fillstyle was "solid" it meant use the
color of linetype 3 for the fill area, not the border.  See the problem?
Then it got worse when "set fillstyle" got a bordercolor property
and worse again when linetype and linecolor became differentiated.

This adds complexity and non-obvious side effects in a lot of
places.  When the code sees "plot ... with boxes lc foo", where should
it store that color? 
  As the linecolor of the plot?
  As the bordercolor of the fillstyle for that plot?
  As the fill color for the fillstyle for that plot?
Right now it's a messy combination of all three options depending
on whether the fillstyle is EMPTY or SOLID and depending on whether
we are in pm3d or hidden3d mode. Ugh.

It would be much nicer to rationalize where colors are stored, even
if it means adding yet more places to the plot structure.
But that would be quite a lot of work and likely to generate a trail
of bug reports because it touches the code in so many places.
Maybe a wishlist item for version 6?

	Ethan

Hi. The docs (help fillstyle) say that the default fillstyle is "empty".
But this isn't what's happening:

  set grid
  set object rectangle from 0,0 to 1,1
  plot [-1:2][-1:2] x

Note that the grid lines do not show up behind the rectangle. If I
explicitly add "fillstyle empty" to the rectangle definition, you get
the transparent rectangle.

Thanks!

Ethan A Merritt <me...@uw...> writes:

> On Monday, 13 April 2020 11:08:01 PDT Dima Kogan wrote:
>
>> >> I tried big images too. I THINK they work, but it's still really slow
>> >> compared to any image viewer. Is that expected? Should it be faster than
>> >> what "with rgbimage" does?
>> >
>> > "slow" when doing what?  rotating in 3D?
>> > Can you do that in a normal image viewer?
>>
>> Just the simplest usage: plot an image with some annotations. No 3d or
>> any transformations of anything. Compared to image viewers the speed
>> difference isn't subtle.
>
> I may be misunderstanding what you are doing (quite possible).
>
> For me using a large image (say a 1365x1024 jpg "wallpaper" photo)
> as a background introduces no noticeable delay at all using the wxt
> terminal.  Even for 3D rotation the response is instantaneous:
>
>     set term wxt size 1500,1000
>     set pixmap 1 at screen 0,0 size screen 1,1 behind '~/images/wallpaper/p1040193.jpg'
>     splot x*y with pm3d
>     [rotate/zoom/translate with mouse as normal]

That's a really good data point. Thanks. I got side-tracked into
something else, but let me come back to this later with some benchmarks,
and we can compare. It'd be great if there was something specific about
my setup that's slowing it down.

On Tue, 14 Apr 2020, Ethan A Merritt wrote:

> On Monday, 13 April 2020 13:14:54 PDT Allin Cottrell wrote:
>> On Fri, 6 Mar 2020, Ethan A Merritt wrote:
>>
>> [a propos Manfred Schwarb's suggestion of using GeoJSON files
>> for geographic plotting in gnuplot]
>>
>>> Good call.  Geojson looks quite promising.
>>> A real parser should be easy, but even a quick pass through sed
>>> or a text editor makes it usable.
>>> I have posted a proof-of-principle example using US state boundary
>>> data from a sample file on the geojson development site:
>>>
>>>  http://skuld.bmsc.washington.edu/people/merritt/gnuplot/
>>
>> Thanks for the example, Ethan.
>>
>> I've recently returned to this issue, exploring the shapefiles
>> option. I've written some relevant utilities in C, designed to link
>> against Frank Warmerdam's lipshape. (I'll be happy to share these
>> once they're better tested.) With their help I've managed to create
>> quite a nice map of the US states, colorized by state population
>> levels. See
>> http://ricardo.ecn.wfu.edu/pub/gretl/datamaps/statepop.png .
>>
>> But the method I'm using for the colorization is clunky and I'm sure
>> it can be improved upon. Here's my input file:
>>
>> <gnuplot>
>> set term pngcairo size 660,400
>> set output 'statepop.png'
>> set linetype 1 lc rgb "white" lw 1
>>
>> set palette model HSV file 'statepop.hsv'
>> set cbrange [0:50]
>> unset colorbox
>>
>> set xrange [95:210]
>> set yrange [-175:-135]
>> set noxtics
>> set noytics
>> set border 0
>> unset key
>>
>> plot for [i=0:*] 'merc.dat' index i with filledcurves \
>>   fc palette cb i, 'merc.dat' with lines lt 1
>> </gnuplot>
>>
>> In the above, 'merc.dat' contains the state outlines from the .shp
>> file. The population data get into the picture via the pre-processed
>> 'statepop.hsv'. To produce this (with its shades of blue) I ran a
>> loop across the states using H = 229/360, V = 93/100, and S[i] =
>> population of state i divided by the max population value.
>>
>> Any suggestions on the best way to do the colorization within
>> gnuplot? And also, perhaps, how to discretize it (by decile for
>> instance)? Is there a way to replace
>>
>>    fc palette cb i
>>
>> with something like
>>
>>    fc palette cb <function of i and the data to be colorized>
>
> Assuming you can get the state's population from somewhere
> (maybe the header of the data block in the outlines file?)
> the palette need not be involved.

In general the data one wants to represent via color on a map will 
not be present in the outlines file; they'll come from some other 
source (as in my population data).

>   blue = 0x000044
>   white = 0xffffff
>   color(i) =  pop(i)/maxpop * blue + (maxpop-pop(i))/maxpop * white
>
> If you use your array S[], that becomes
>   color(i) = S[i] * blue + (1.0-S[i]) * white
>
> Then you can plot using the color directly
>
>   plot for [i=0:*] 'merc.dat' index i using 1:2:(color(i)) with filledcurves \
>           fc rgb variable

Nice, thanks. Using a gnuplot array for the "extra" data is clearly 
a good solution. My only problem is that I'm trying to come up with 
something that works for gnuplot >= 5.0 (and arrays are new in 5.2).

I've found one alternative to my original approach: In preparing the 
data for gnuplot, I append a third column after the coordinate pairs 
for the vertices of the outlines. The values in this column repeat 
the population (or whatever) value for each entity. So now I can do 
something like:

set cbrange [0:1]
set palette defined (0 'white', 1 'steelblue')
...
plot for [i=0:*] 'states.dat' index i with filledcurves \
  fc palette, 'states.dat' using 1:2 with lines

where a little slice of one of the states in 'states.dat' looks 
like this:

# longitude, latitude, popratio
-85.799227 41.763535 0.25275361
-86.068302 41.764628 0.25275361
-86.234565 41.764864 0.25275361
-86.525181 41.765540 0.25275361
-86.834829 41.765504 0.25275361

Allin Cottrell

On Monday, 13 April 2020 13:14:54 PDT Allin Cottrell wrote:
> On Fri, 6 Mar 2020, Ethan A Merritt wrote:
> 
> [a propos Manfred Schwarb's suggestion of using GeoJSON files
> for geographic plotting in gnuplot]
> 
> > Good call.  Geojson looks quite promising.
> > A real parser should be easy, but even a quick pass through sed
> > or a text editor makes it usable.
> > I have posted a proof-of-principle example using US state boundary
> > data from a sample file on the geojson development site:
> >
> >  http://skuld.bmsc.washington.edu/people/merritt/gnuplot/
> 
> Thanks for the example, Ethan.
> 
> I've recently returned to this issue, exploring the shapefiles 
> option. I've written some relevant utilities in C, designed to link 
> against Frank Warmerdam's lipshape. (I'll be happy to share these 
> once they're better tested.) With their help I've managed to create 
> quite a nice map of the US states, colorized by state population 
> levels. See 
> http://ricardo.ecn.wfu.edu/pub/gretl/datamaps/statepop.png .
> 
> But the method I'm using for the colorization is clunky and I'm sure 
> it can be improved upon. Here's my input file:
> 
> <gnuplot>
> set term pngcairo size 660,400
> set output 'statepop.png'
> set linetype 1 lc rgb "white" lw 1
> 
> set palette model HSV file 'statepop.hsv'
> set cbrange [0:50]
> unset colorbox
> 
> set xrange [95:210]
> set yrange [-175:-135]
> set noxtics
> set noytics
> set border 0
> unset key
> 
> plot for [i=0:*] 'merc.dat' index i with filledcurves \
>   fc palette cb i, 'merc.dat' with lines lt 1
> </gnuplot>
> 
> In the above, 'merc.dat' contains the state outlines from the .shp
> file. The population data get into the picture via the pre-processed
> 'statepop.hsv'. To produce this (with its shades of blue) I ran a
> loop across the states using H = 229/360, V = 93/100, and S[i] =
> population of state i divided by the max population value.
> 
> Any suggestions on the best way to do the colorization within 
> gnuplot? And also, perhaps, how to discretize it (by decile for 
> instance)? Is there a way to replace
> 
>    fc palette cb i
> 
> with something like
> 
>    fc palette cb <function of i and the data to be colorized>

Assuming you can get the state's population from somewhere
(maybe the header of the data block in the outlines file?)
the palette need not be involved.

   blue = 0x000044
   white = 0xffffff
   color(i) =  pop(i)/maxpop * blue + (maxpop-pop(i))/maxpop * white

If you use your array S[], that becomes
   color(i) = S[i] * blue + (1.0-S[i]) * white

Then you can plot using the color directly

   plot for [i=0:*] 'merc.dat' index i using 1:2:(color(i)) with filledcurves \
           fc rgb variable

		Ethan

> Allin Cottrell

On Monday, 13 April 2020 11:08:01 PDT Dima Kogan wrote:

> >> I tried big images too. I THINK they work, but it's still really slow
> >> compared to any image viewer. Is that expected? Should it be faster than
> >> what "with rgbimage" does?
> >
> > "slow" when doing what?  rotating in 3D?
> > Can you do that in a normal image viewer?
> 
> Just the simplest usage: plot an image with some annotations. No 3d or
> any transformations of anything. Compared to image viewers the speed
> difference isn't subtle.

I may be misunderstanding what you are doing (quite possible).

For me using a large image (say a 1365x1024 jpg "wallpaper" photo)
as a background introduces no noticeable delay at all using the wxt
terminal.  Even for 3D rotation the response is instantaneous:

    set term wxt size 1500,1000
    set pixmap 1 at screen 0,0 size screen 1,1 behind '~/images/wallpaper/p1040193.jpg'
    splot x*y with pm3d
    [rotate/zoom/translate with mouse as normal]

For x11 the initial display is very quick, but the response to 3D rotation
is somewhat laggy.  Not bad, though.  

The strange one is actually qt, where the response to 3D rotation is horribly slow.
Zoom and pan in 2D is quick however. I'll bet there is some way to speed up the qt 
3D rendering also, but it will require some investigation. 

	Ethan

On Fri, 6 Mar 2020, Ethan A Merritt wrote:

[a propos Manfred Schwarb's suggestion of using GeoJSON files
for geographic plotting in gnuplot]

> Good call.  Geojson looks quite promising.
> A real parser should be easy, but even a quick pass through sed
> or a text editor makes it usable.
> I have posted a proof-of-principle example using US state boundary
> data from a sample file on the geojson development site:
>
>  http://skuld.bmsc.washington.edu/people/merritt/gnuplot/

Thanks for the example, Ethan.

I've recently returned to this issue, exploring the shapefiles 
option. I've written some relevant utilities in C, designed to link 
against Frank Warmerdam's lipshape. (I'll be happy to share these 
once they're better tested.) With their help I've managed to create 
quite a nice map of the US states, colorized by state population 
levels. See 
http://ricardo.ecn.wfu.edu/pub/gretl/datamaps/statepop.png .

But the method I'm using for the colorization is clunky and I'm sure 
it can be improved upon. Here's my input file:

<gnuplot>
set term pngcairo size 660,400
set output 'statepop.png'
set linetype 1 lc rgb "white" lw 1

set palette model HSV file 'statepop.hsv'
set cbrange [0:50]
unset colorbox

set xrange [95:210]
set yrange [-175:-135]
set noxtics
set noytics
set border 0
unset key

plot for [i=0:*] 'merc.dat' index i with filledcurves \
  fc palette cb i, 'merc.dat' with lines lt 1
</gnuplot>

In the above, 'merc.dat' contains the state outlines from the .shp
file. The population data get into the picture via the pre-processed
'statepop.hsv'. To produce this (with its shades of blue) I ran a
loop across the states using H = 229/360, V = 93/100, and S[i] =
population of state i divided by the max population value.

Any suggestions on the best way to do the colorization within 
gnuplot? And also, perhaps, how to discretize it (by decile for 
instance)? Is there a way to replace

   fc palette cb i

with something like

   fc palette cb <function of i and the data to be colorized>

?

Allin Cottrell

Ethan A Merritt writes:
>> The tutorial seems missing from the 5.4 branch and tarball, but still
>> available in master.  Is that intentional?
>
> Yes.  
>
> The latex tutorial was written for the old, old latex drivers "set term latex"
> and "set term eepic" that are no longer included in the gnuplot distribution. 
> The tutorial source is still in master in case it inspires  someone to
> write a new one illustrating use of the newer terminals relevant to latex.

I would suggest to mention that in the release notes and move on, then.

I have made the RC1 available on Cygwin in both 32bit and 64bit variants
for testing.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

On Monday, 13 April 2020 11:45:42 PDT Achim Gratz wrote:
> Ethan A Merritt writes:
> > You can download a source tarball for the first version 5.4 release candidate from 
> >
> >     https://sf.net/projects/gnuplot/files/testing/gnuplot-5.4.rc1.tar.gz
> 
> The tutorial seems missing from the 5.4 branch and tarball, but still
> available in master.  Is that intentional?

Yes.  

The latex tutorial was written for the old, old latex drivers "set term latex"
and "set term eepic" that are no longer included in the gnuplot distribution. 
The tutorial source is still in master in case it inspires  someone to
write a new one illustrating use of the newer terminals relevant to latex.

	Ethan

Ethan A Merritt writes:
> You can download a source tarball for the first version 5.4 release candidate from 
>
>     https://sf.net/projects/gnuplot/files/testing/gnuplot-5.4.rc1.tar.gz

The tutorial seems missing from the 5.4 branch and tarball, but still
available in master.  Is that intentional?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Ethan A Merritt <me...@uw...> writes:

> On Thursday, 9 April 2020 14:06:01 PDT Dima Kogan wrote:
>
>> You need to zoom out manually because the pixmap isn't a part of the
>> autoscaling logic. Should it be? It is when using "with rgbimage" I
>> think.
>
> I think you misunderstood the meaning of "first" in that context.
> The default xrange is [-10:10], if you place an image with its lower
> corner at 0,0 then the maximum size that will fit in the plot is
>    set pixmap 1 "/tmp/front2.png" at 0,0 width first 10 behind
> i.e. 10 units in the first axis coordinate system

By default gnuplot scales the axes to fit all the data being plotted.
But the images plotted with "set pixmap" aren't included in this logic,
it looks like. I think they probably should be. So the default xrange of
[-10:10] would be expanded to include the image.


> If you use axis coordinates (e.g. "first 10") then it autoscales.
> If you stay in pixel coordinates then it doesn't scale.

I think this is how it should work, but it doesn't. I do this:

  set pixmap 1 "/tmp/front2.png" at 0,0 width first 300 behind
  plot x

This says "plot the image with a corner at 0,0 scaled such the whole
image is 300 wide along the x axis." The plot I get uses the initial
x scaling of [-10:10], which includes only a tiny corner of the image. I
used axis coordinates and it did not autoscale.

>> It'd also be really nice to use the native size of the image somehow.
>> The default "set pixmap" uses is "native image size in pixel
>> coordinates". But what I'd want usually is "native image size in plot
>> axis coordinates", and this isn't available.
>
> What does that even mean?
>
>> I have to know the size,
>> and to communicate it in the command with something like "first 300".
>
> No, that's wrong.  If you use plot coordinates you *don't* need to know
> the original size in pixels because it will be scaled to match the plot.
> You are specifying a width in plot coordinates.

I'm being loose with terminology; sorry. I'm trying to emulate "with
rgbimage". So if I have an image that's 500 pixels wide I want the x
mapping I get with

  set pixmap 1 "/tmp/front2.png" at 0,0 width first 500

But I don't want to specify "500" in the command. Should we maybe have a
width of "0" mean "original image width", or something? Currently
"set pixmap ... width first 0" is equivalent to "set pixmap ..."


> Pixmaps are not intended as a replacement for "with image".
>
> I think of it more like placing a complicated character glyph within
> a page of text.  You can specify where to put it, and you can make
> it larger or smaller, but in the end it is still the same character.
> Rotation, inversion, or other substantial transformation is left to
> images=pictures rather than to pixmaps=characters.

OK, so maybe pixmaps aren't what I actually want then. It's just a
different use case.


>> I tried big images too. I THINK they work, but it's still really slow
>> compared to any image viewer. Is that expected? Should it be faster than
>> what "with rgbimage" does?
>
> "slow" when doing what?  rotating in 3D?
> Can you do that in a normal image viewer?

Just the simplest usage: plot an image with some annotations. No 3d or
any transformations of anything. Compared to image viewers the speed
difference isn't subtle.


> The difference from rgbimage is that all the "with image" commands treat the
> individual pixels as independent data points.  They are stored and manipulated
> separately, taking up a lot of memory.  The "pixmap" mechanism stores and
> dumps a whole png image, which is much more compact, possibly with rescaling.
> The internal storage is persistant, so it doesn't have to be read in and re-processed
> as new data on each plot/replot etc.
>
> So yeah, it should be faster so far as the gnuplot code is concerned.
> What happens after you send it to an X-server is another matter.
> Once it is in the x11 display list it probably doesn't make any difference
> how it got there.

OK. I'm guessing there's both a gnuplot and an x component in the
performance difference. I'll take a look at some point.

Thanks for explaining

dima

On Thursday, 9 April 2020 14:06:01 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > On Thursday, 9 April 2020 11:58:52 PDT Dima Kogan wrote:
> >> A common use case for me is to mark-up images. So gnuplot would plot an
> >> image, and render stuff on top of it.
> >
> > Already there in 5.4 (please test release candidate!)
> 
> What? Wow! OK.
> 
> First off, I've been running 5.4-rc1 (built from source, new
> x11_waitforinput patch cherry-picked) for a few days now. No surprises
> yet.
> 
> I just tried out 'set pixmap'. For me it only appears to work in the
> most basic cases, and I can't tell if it's any faster. I think there're
> several issues at play.
> 
> I tried small images first. Using http://gnuplot.info/figs/front2.png
> from the gnuplot site.
> 
> This works:
> 
>   set terminal x11
>   set pixmap 1 "/tmp/front2.png" at 0,0
>   plot x
> 
> This doesn't:
> 
>   set terminal x11
>   set pixmap 1 "/tmp/front2.png" at 0,0 width first 300 behind
>   plot x

I think you misunderstood the meaning of "first" in that context.
The default xrange is [-10:10], if you place an image with its lower
corner at 0,0 then the maximum size that will fit in the plot is
   set pixmap 1 "/tmp/front2.png" at 0,0 width first 10 behind
i.e. 10 units in the first axis coordinate system

> The plot pops up, and goes away immediately. Might be x11_waitforinput()
> still needs work, because in the qt terminal it does work. x11 is weird
> in lots of cases here, so I'm using qt for the rest of this email. Will
> revisit x11 later.

I have no idea what that's all about, but possibly it is a result of
trying to draw a bitmap that extends waaaay off screen,
since "width first 300" is 30 times too big to fit on screen.

> You need to zoom out manually because the pixmap isn't a part of the
> autoscaling logic. Should it be? It is when using "with rgbimage" I
> think.

Again a misunderstanding?
If you use axis coordinates (e.g. "first 10") then it autoscales.
If you stay in pixel coordinates then it doesn't scale.

> It'd also be really nice to use the native size of the image somehow.
> The default "set pixmap" uses is "native image size in pixel
> coordinates". But what I'd want usually is "native image size in plot
> axis coordinates", and this isn't available.

What does that even mean?

> I have to know the size,
> and to communicate it in the command with something like "first 300".

No, that's wrong.  If you use plot coordinates you *don't* need to know
the original size in pixels because it will be scaled to match the plot.
You are specifying a width in plot coordinates.

> Usually when talking about images, the y axis is flipped: the (0,0)
> pixel is the TOP-left not the BOTTOM-left. So "set pixmap at" should
> maybe place the top-left pixel of the image? In my usage I generally do
> "set yrange [:] reverse". But even in that usage "set pixmap at" places
> the bottom-left pixel. Among the same lines, it should be possible for
> the image pixel axes to follow the plot axes. In that mode "set yrange
> [:] reverse" would plot the image right side up, and with the default
> axis orientation, it would be upside down.

Pixmaps are not intended as a replacement for "with image".

I think of it more like placing a complicated character glyph within
a page of text.  You can specify where to put it, and you can make
it larger or smaller, but in the end it is still the same character.
Rotation, inversion, or other substantial transformation is left to
images=pictures rather than to pixmaps=characters.

> "set pixel height" and "set pixel size" don't play nicely with "set
> yrange [:] reverse", so for instance this doesn't draw an image at all:
> 
>   set yrange [:] reverse
>   set pixmap 1 "/tmp/front2.png" at 0,0 height 300
>   plot x

Huh. That indeed looks like a bug of some sort.
The requested height is still wrong there (should be <10) but yes setting
yrange reverse messes up the placement.  I will have a look at that.

> "set pixel size" doesn't follow the docs, I think. The docs say it wants
> "set pixel size A B", while it actually wants "set pixel size A,B". Note
> the extra comma.

yes.

> I tried big images too. I THINK they work, but it's still really slow
> compared to any image viewer. Is that expected? Should it be faster than
> what "with rgbimage" does?

"slow" when doing what?  rotating in 3D? 
Can you do that in a normal image viewer?

The difference from rgbimage is that all the "with image" commands treat the
individual pixels as independent data points.  They are stored and manipulated
separately, taking up a lot of memory.  The "pixmap" mechanism stores and
dumps a whole png image, which is much more compact, possibly with rescaling.
The internal storage is persistant, so it doesn't have to be read in and re-processed
as new data on each plot/replot etc.   

So yeah, it should be faster so far as the gnuplot code is concerned.
What happens after you send it to an X-server is another matter.
Once it is in the x11 display list it probably doesn't make any difference
how it got there.

	Ethan

You can now download binaries for Windows (64bit), OS/2/eComStation/ArcaOS, and
DOS (32bit) from

     https://sf.net/projects/gnuplot/files/gnuplot/testing/

Cheers, Bastian


> Gesendet: Dienstag, 07. April 2020 um 22:58 Uhr
> Von: "Ethan A Merritt" <me...@uw...>
> An: gnu...@li...
> Betreff: First release candidate for gnuplot version 5.4
>
> You can download a source tarball for the first version 5.4 release candidate from
>
>     https://sf.net/projects/gnuplot/files/testing/gnuplot-5.4.rc1.tar.gz
>
> Release notes here:
>
>     http://gnuplot.sourceforge.net/ReleaseNotes_5_4.html
>
> Please test, but there is no great hurry.
> The final release of 5.4 can wait until it is ready.
>
>
> 	cheers, and happy plotting
>
> 		Ethan
>

Ethan A Merritt <me...@uw...> writes:

> On Thursday, 9 April 2020 11:58:52 PDT Dima Kogan wrote:
>> A common use case for me is to mark-up images. So gnuplot would plot an
>> image, and render stuff on top of it.
>
> Already there in 5.4 (please test release candidate!)

What? Wow! OK.

First off, I've been running 5.4-rc1 (built from source, new
x11_waitforinput patch cherry-picked) for a few days now. No surprises
yet.

I just tried out 'set pixmap'. For me it only appears to work in the
most basic cases, and I can't tell if it's any faster. I think there're
several issues at play.

I tried small images first. Using http://gnuplot.info/figs/front2.png
from the gnuplot site.

This works:

  set terminal x11
  set pixmap 1 "/tmp/front2.png" at 0,0
  plot x

This doesn't:

  set terminal x11
  set pixmap 1 "/tmp/front2.png" at 0,0 width first 300 behind
  plot x

The plot pops up, and goes away immediately. Might be x11_waitforinput()
still needs work, because in the qt terminal it does work. x11 is weird
in lots of cases here, so I'm using qt for the rest of this email. Will
revisit x11 later.

You need to zoom out manually because the pixmap isn't a part of the
autoscaling logic. Should it be? It is when using "with rgbimage" I
think.

It'd also be really nice to use the native size of the image somehow.
The default "set pixmap" uses is "native image size in pixel
coordinates". But what I'd want usually is "native image size in plot
axis coordinates", and this isn't available. I have to know the size,
and to communicate it in the command with something like "first 300".

Usually when talking about images, the y axis is flipped: the (0,0)
pixel is the TOP-left not the BOTTOM-left. So "set pixmap at" should
maybe place the top-left pixel of the image? In my usage I generally do
"set yrange [:] reverse". But even in that usage "set pixmap at" places
the bottom-left pixel. Among the same lines, it should be possible for
the image pixel axes to follow the plot axes. In that mode "set yrange
[:] reverse" would plot the image right side up, and with the default
axis orientation, it would be upside down.

"set pixel height" and "set pixel size" don't play nicely with "set
yrange [:] reverse", so for instance this doesn't draw an image at all:

  set yrange [:] reverse
  set pixmap 1 "/tmp/front2.png" at 0,0 height 300
  plot x

"set pixel size" doesn't follow the docs, I think. The docs say it wants
"set pixel size A B", while it actually wants "set pixel size A,B". Note
the extra comma.

I tried big images too. I THINK they work, but it's still really slow
compared to any image viewer. Is that expected? Should it be faster than
what "with rgbimage" does?

Thanks for the feature!

On Thursday, 9 April 2020 11:58:52 PDT Dima Kogan wrote:
> Hi.
> 
> Can somebody chime in on how hard/trivial a new feature would be?
> 
> A common use case for me is to mark-up images. So gnuplot would plot an
> image, and render stuff on top of it. Something like this:
> 
>   plot "image.jpg" binary filetype=auto flipy with rgbimage, ...
> 
> This works, but it is always really slow, and if I'm on a machine that's
> not ridiculously overpowered, it runs out of memory.
> 
> My images are several 1000 pixels per side. So big, but not giant. I
> THINK gnuplot is loading each pixel in the image into a separate point
> to be plotted, which makes sense given how flexible this is. But 99% of
> the time for ME, I'm just plotting the image exactly as it is, with
> maybe some independent scaling in x and y. Would it be massively
> effortful to detect that the user is trying to do the simple thing, and
> to run a different code path that treats the image as an image, and is
> thus fast?
> 
> Implementation suggestions? Would we want another terminal command for
> this?

Already there in 5.4 (please test release candidate!)
See

    http://gnuplot.sourceforge.net/demo_5.4/pixmap.html

But I have not benchmarked it or tried to establish what the limits might be
on a memory-limited machine.



gnuplot> help pixmap

 Syntax:
       set pixmap <index> "filename" at <position>
                  {width <w> | height <h> | size <w> <h>}
                  {front|behind} {center}
       show pixmaps
       unset pixmaps

 The `set pixmap` command is similar to `set object` in that it defines an
 object that will appear on subsequent plots. The rectangular array of
 red/green/blue/alpha values making up the pixmap are read from a png, jpeg,
 or gif file.  The position and extent occupied by the pixmap in the gnuplot
 output may be specified in any coordinate system (see `coordinates`).
 The coordinates given by `at <position>` refer to the lower left
 corner of the pixmap unless keyword `center` is present.

[rest of documentation snipped]

	Ethan

Hi.

Can somebody chime in on how hard/trivial a new feature would be?

A common use case for me is to mark-up images. So gnuplot would plot an
image, and render stuff on top of it. Something like this:

  plot "image.jpg" binary filetype=auto flipy with rgbimage, ...

This works, but it is always really slow, and if I'm on a machine that's
not ridiculously overpowered, it runs out of memory.

My images are several 1000 pixels per side. So big, but not giant. I
THINK gnuplot is loading each pixel in the image into a separate point
to be plotted, which makes sense given how flexible this is. But 99% of
the time for ME, I'm just plotting the image exactly as it is, with
maybe some independent scaling in x and y. Would it be massively
effortful to detect that the user is trying to do the simple thing, and
to run a different code path that treats the image as an image, and is
thus fast?

Implementation suggestions? Would we want another terminal command for
this?

Thanks