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

Re: swprintf_s in src/win32

[Hans-Bernhard B. <HBB...@t-...>]

Am 28.09.2017 um 23:12 schrieb Allin Cottrell:
> Three of the source files in gnuplot's src/win32 use the function 
> swprintf_s(), namely wgdiplus.cpp, wmenu.c and wtext.c. In one of these 
> files, wgdiplus.cpp, there's a recognition that this function is not 
> universally available:
> 
> #ifdef __WATCOMC__
> // swprintf_s is missing from <cwchar>
> # define swprintf_s(s, c, f, ...) swprintf(s, c, f, __VA_ARGS__)
> #endif
> 
> It seems to me that this guard against use of an undefined function 
> should also be present in wmenu.c and wtext.c

It may seem like that at first glance, but it's not actually the case. 
OpenWatcom does supply swprintf_s(), but only for C source code, not for 
C++.  I.e. it's in <wchar.h>, but not available via its C++ equivalent, 
<cwchar>.

. Moreover, it's not just
> the Watcom compiler that's affected: swprintf_s is not declared in the 
> headers provided for cross-compilation via mingw64.

I see no such problem here.  Maybe your version of mingw64 is outdated?

(For reference, I'm using the current version of the MinGW64 headers as 
installed by Cygwin, from package mingw64-x86_64-headers-5.0.2-1).

Re: old online html documentation

[Allin C. <cot...@wf...>]

On Thu, 28 Sep 2017, Ethan A Merritt via gnuplot-beta wrote:

> On Thursday, 28 September, 2017 13:12:37 Karl-Friedrich Ratzsch wrote:
>> Hi,
>>
>> whenever someone asks google for help on gnuplot, one of the first
>> hits is an online version on sf.net of the html docs for gnuplot 4.2
>>
>> https://www.google.de/search?q=gnuplot+dgrid3d
>>
>> http://gnuplot.sourceforge.net/docs_4.2/node177.html
>>
>> I assume this is because the build process for the html help has
>> been broken for quite some time. For lack of a quick fix for that,
>> it would probably still be better to just remove that outdated stuff?
>
> Google never forgets.
> There's probably no way to remove it from the search results.
>
> A better question is how to persuade Google to return a
> link to current docs rather than to a 10-year-old version.
>
> I have no idea how to do that.

It's true that Google never forgets, but it's also true that Google 
is extremely clever. The trouble in this case, I think, is that the 
online html doc for gnuplot has never been updated on sourceforge 
since version 4.2.

Given the URL

http://gnuplot.sourceforge.net/docs_4.2/

try updating it by substituting "4.6" or "5.0" or "5.2" for "4.2" 
and you get nothing but 404-errors.

If you start from scratch by googling "gnuplot dgrid3d" the obsolete
4.2 doc comes first, but (at least for me) the relatively up-to-date

http://www.gnuplot.info/demo/dgrid3d.html

comes second (well, actually the order may vary). I can't blame 
google for preferring actual documentation to a demo (when that 
happens).

If you back up another level and google just "gnuplot documentation" 
you get (or at least I get) at first hit

http://www.gnuplot.info/documentation.html

(so exemplifying the old equivocation between www.gnuplot.info and
gnuplot.sourceforge.net as canonical source). But this page just 
offers PDF files. Nothing wrong with PDF, but I can see that google 
(that is, ultimately, google users) might prefer HTML, however out 
of date it may be.

I don't mean to blame anyone -- least of all Ethan, who's doing a 
great job as primary gnuplot maintainer/developer these days -- and 
I'm afraid I'm not about to volunteer to maintain the gnuplot online 
doc myself (too many other fish to fry). But if anyone were willing 
to help, certain paths look like they might be promising.

I'm fairly confident that if anyone were to put updated 
HTML documentation under, say,

http://gnuplot.sourceforge.net/docs_5.0/

that would be picked up quite quickly and displace the old stuff on 
google. Or perhaps a redirect could be installed at

http://gnuplot.sourceforge.net/docs_4.2/

to point to whatever is the preferred location for current 
documentation.

--
Allin Cottrell
Department of Economics
Wake Forest University

swprintf_s in src/win32

[Allin C. <cot...@wf...>]

Three of the source files in gnuplot's src/win32 use the function 
swprintf_s(), namely wgdiplus.cpp, wmenu.c and wtext.c. In one of 
these files, wgdiplus.cpp, there's a recognition that this function 
is not universally available:

#ifdef __WATCOMC__
// swprintf_s is missing from <cwchar>
# define swprintf_s(s, c, f, ...) swprintf(s, c, f, __VA_ARGS__)
#endif

It seems to me that this guard against use of an undefined function 
should also be present in wmenu.c and wtext.c. Moreover, it's not 
just the Watcom compiler that's affected: swprintf_s is not declared 
in the headers provided for cross-compilation via mingw64.

Hence, a request: could this back-up definition be provided in all 
the affected files, and could it please be extended from __WATCOM__ 
to some convenient symbol that could be defined on the compiler 
command line for any system that's missing the definition -- for
example something like:

#if defined(__WATCOM__) || defined(SWPRINTF_S_MISSING)
<alternative definition>
#endif

That way, one would not have to hack these three files to get 
current wgnuplot.exe to build.

Thanks.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: old online html documentation

[Ethan A M. <sf...@us...>]

On Thursday, 28 September, 2017 13:12:37 Karl-Friedrich Ratzsch wrote:
> Hi,
> 
> whenever someone asks google for help on gnuplot, one of the first
> hits is an online version on sf.net of the html docs for gnuplot 4.2
> 
> https://www.google.de/search?q=gnuplot+dgrid3d
> 
> http://gnuplot.sourceforge.net/docs_4.2/node177.html
> 
> I assume this is because the build process for the html help has
> been broken for quite some time. For lack of a quick fix for that,
> it would probably still be better to just remove that outdated stuff?

Google never forgets.
There's probably no way to remove it from the search results.

A better question is how to persuade Google to return a 
link to current docs rather than to a 10-year-old version.

I have no idea how to do that.

	Ethan

old online html documentation

[Karl-Friedrich R. <mai...@gm...>]

Hi,

whenever someone asks google for help on gnuplot, one of the first
hits is an online version on sf.net of the html docs for gnuplot 4.2

https://www.google.de/search?q=gnuplot+dgrid3d

http://gnuplot.sourceforge.net/docs_4.2/node177.html

I assume this is because the build process for the html help has
been broken for quite some time. For lack of a quick fix for that,
it would probably still be better to just remove that outdated stuff?

Best,
   Karl

5.2 bug? in log scale yrange set by [ : ]

[KH.Moriyama <khm...@gm...>]

Hi.
I installed the 5.2 and very happy with it, thanks to everybody.

And, I found a strange behavior when I use log scale.
Try the below:

set log xy
plo [3:200][5:50] x

What I see is the x-range is properly drawn but
y-range of the graph becomes 1:100 instead of 5:50
while the line is clipped at y=5 and 50 as set by [...].
Then, do this:

set yrange [5:50]
replo

Then, I get a graph with the expected drawing of the axes.

This problem seems to appear only in the y-range set by [ ] in the plot
command line. (also in the case x is linear)
Using "set nonlinear" to make the log scale shows no problem.

I tested this with RC2 that I previously installed and saw the same situation.
5.0.5 does not.
Maybe the reimplementation of "set logscale" after the introduction of
the "set nonlinear" involved some bug, I suppose.

Thanks.

KH Moriyama

Re: y2 tics on the left of the plot

[sfeam <sf...@us...>]

On Monday, 04 September 2017 19:50:25 Dima Kogan wrote:
> Hi. This may seem convoluted, but is there a way to print the y2 tics
> and axis labels on the LEFT edge of a plot? And similarly, x2
> tics,labels on the BOTTOM.
> 
> This would be useful to me for the OSM-tile plotting in the other
> thread: I want to have a nonlinear y1-y2 relationship, with an rgbimage
> plotted against the axis that is linearly mapped to the terminal
> coordinates (y in this case). Thus the axes I want to display to the
> user are x2,y2 and I want them to be rendered in the "normal" place.
> 
> Other ways to achieve this are welcome.

The tics per se are easy.

    unset ytics; set y2tics mirror

The labels are a bit harder because the auto-positioning
was not really designed for this.
You will have to adjust the exact offset and probably force
the left margin to be larger because the program is not
reserving space there for the y2 labels.

    set y2tics offset graph -1.025 right
    set lmargin screen .05

	Ethan

Re: Two minor patches

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

> I hope you don't mind if I cc any complaints from the OSXers in your
> direction :)

Sure :)

y2 tics on the left of the plot

[Dima K. <gn...@di...>]

Hi. This may seem convoluted, but is there a way to print the y2 tics
and axis labels on the LEFT edge of a plot? And similarly, x2
tics,labels on the BOTTOM.

This would be useful to me for the OSM-tile plotting in the other
thread: I want to have a nonlinear y1-y2 relationship, with an rgbimage
plotted against the axis that is linearly mapped to the terminal
coordinates (y in this case). Thus the axes I want to display to the
user are x2,y2 and I want them to be rendered in the "normal" place.

Other ways to achieve this are welcome.

Re: Two minor patches

[sfeam <sf...@us...>]

On Monday, 04 September 2017 12:32:25 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> >> Pinging this thread before I forget about it. Can we please merge the
> >> patch?
> >>
> >> On systems where X11 is available, $LIBRARIES_FOR_X will contain the
> >> X11 link flags, so we'll link in the appropriate library, and things
> >> will work.
> >
> > I do not think this is correct. What about systems where X is
> > "available" but is not used for wxt? I think that is true for both OSX
> > and Windows. My recollection is that putting -LX11 in the build flags
> > broke OSX.
> 
> I'l like to get confirmation from somebody who actually uses OSX.
> 
> 
> > I still think this is a wxgtk configuration error and not something
> > that gnuplot can fix on its own.
> 
> Maybe. But the current state of affairs is that on Debian (and probably
> every other linux distro) a simple
> 
>   ./prepare; ./configure; make
> 
> sequence fails. It doesn't matter whose bug this is we should try to
> work around it.

It does not fail here (Mageia 4/5/6).
But OK, let's try it out in 5.3
I hope you don't mind if I cc any complaints from the OSXers 
in your direction :)

	Ethan

Re: rgbimage plots with linked axes

[Dima K. <gn...@di...>]

Thanks much for the help, Ethan. The end-product of this discussion:

  https://github.com/dkogan/osmgnuplot

I found another bug: the check for an invalid axis-linking function was
behaving poorly, and would be over-eager to report errors due to
numerical inaccuracies. A patch (with further description of problem and
solution):

Re: Two minor patches

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

>> Pinging this thread before I forget about it. Can we please merge the
>> patch?
>>
>> On systems where X11 is available, $LIBRARIES_FOR_X will contain the
>> X11 link flags, so we'll link in the appropriate library, and things
>> will work.
>
> I do not think this is correct. What about systems where X is
> "available" but is not used for wxt? I think that is true for both OSX
> and Windows. My recollection is that putting -LX11 in the build flags
> broke OSX.

I'l like to get confirmation from somebody who actually uses OSX.


> I still think this is a wxgtk configuration error and not something
> that gnuplot can fix on its own.

Maybe. But the current state of affairs is that on Debian (and probably
every other linux distro) a simple

  ./prepare; ./configure; make

sequence fails. It doesn't matter whose bug this is we should try to
work around it.

Re: Two minor patches

[sfeam <sf...@us...>]

On Monday, 04 September 2017 11:50:11 Dima Kogan wrote:
> Dima Kogan <gn...@di...> writes:
> 
> > sfeam <sf...@us...> writes:
> >
> >> On Thursday, 17 August 2017 19:17:05 Dima Kogan wrote:
> >>> On Thu, Aug 17, 2017, at 14:13, Ethan A Merritt wrote:
> >>>
> >>> > > 2. The build was broken on a recent Debian system: we were calling
> >>> > > XInitThreads(), but not linking in -lX11. The patch adds the linkage
> >>> >
> >>> > Sigh.  This keeps coming back and back and back.
> >>> > Adding -lX11 fixes most linux installations but breaks everyone else.
> >>> >
> >>> > See for example https://sourceforge.net/p/gnuplot/bugs/1764/
> >>>
> >>> OK, I read your links, but it's not obvious how it breaks everyone else.
> >>> Is the concern that some platforms have wx, but not X11, so the link to
> >>> libX11 will fail? What if instead of linking to -lX11 we link to
> >>> $LIBRARIES_FOR_X?
> >>
> >> Doesn't that just push the same problem down or up one level?
> >> The question then becomes how do you figure out what to put
> >> in $LIBRARIES_FOR_X.
> 
> Pinging this thread before I forget about it. Can we please merge the
> patch?
> 
> On systems where X11 is available, $LIBRARIES_FOR_X will contain the X11
> link flags, so we'll link in the appropriate library, and things will
> work.

I do not think this is correct.
What about systems where X is "available" but is not used for wxt?
I think that is true for both OSX and Windows.
My recollection is that putting -LX11 in the build flags broke OSX.

For that matter, even on my linux systems that still use wxgtk 2.8 rather than
3.0, the -lX11 is not needed.  In this case it doesn't break anything, but
still it's annoying to include a library dependency that isn't even used.
gnuplot itself does not use the X libraries.

I still think this is a wxgtk configuration error and not something that
gnuplot can fix on its own.
	
	Ethan

> 
> On systems where X11 is not available, $LIBRARIES_FOR_X will be "", so
> nothing extra will be linked in, and things will keep functioning as
> before.

Re: Two minor patches

[Dima K. <gn...@di...>]

Dima Kogan <gn...@di...> writes:

> sfeam <sf...@us...> writes:
>
>> On Thursday, 17 August 2017 19:17:05 Dima Kogan wrote:
>>> On Thu, Aug 17, 2017, at 14:13, Ethan A Merritt wrote:
>>>
>>> > > 2. The build was broken on a recent Debian system: we were calling
>>> > > XInitThreads(), but not linking in -lX11. The patch adds the linkage
>>> >
>>> > Sigh.  This keeps coming back and back and back.
>>> > Adding -lX11 fixes most linux installations but breaks everyone else.
>>> >
>>> > See for example https://sourceforge.net/p/gnuplot/bugs/1764/
>>>
>>> OK, I read your links, but it's not obvious how it breaks everyone else.
>>> Is the concern that some platforms have wx, but not X11, so the link to
>>> libX11 will fail? What if instead of linking to -lX11 we link to
>>> $LIBRARIES_FOR_X?
>>
>> Doesn't that just push the same problem down or up one level?
>> The question then becomes how do you figure out what to put
>> in $LIBRARIES_FOR_X.

Pinging this thread before I forget about it. Can we please merge the
patch?

On systems where X11 is available, $LIBRARIES_FOR_X will contain the X11
link flags, so we'll link in the appropriate library, and things will
work.

On systems where X11 is not available, $LIBRARIES_FOR_X will be "", so
nothing extra will be linked in, and things will keep functioning as
before.

Re: Release 5.2 tarball now on SourceForge

[Tatsuro M. <tma...@ya...>]

I have made 5.2.0 windows binary packages and uploaded on SourceForge site.

Tatsuro



----- Original Message -----
> From: sfeam via gnuplot-beta <gnu...@li...>
> To: gnu...@li...
> Cc: 
> Date: 2017/9/4, Mon 12:51
> Subject: Release 5.2 tarball now on SourceForge
> 
>T he final 5.2 release contains a couple of last-minute fixes for bugs reported
> at the 11th hour.  Many thanks to everyone who helped with the release and
> tested earlier release candidates.
> 
>     Ethan (sf...@sf...)  
>     on behalf of the gnuplot development team
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Release 5.2 tarball now on SourceForge

[sfeam <sf...@us...>]

The final 5.2 release contains a couple of last-minute fixes for bugs reported
at the 11th hour.  Many thanks to everyone who helped with the release and
tested earlier release candidates.

	Ethan (sf...@sf...)  
	on behalf of the gnuplot development team

Re: rgbimage plots with linked axes

[sfeam <sf...@us...>]

On Friday, 01 September 2017 23:49:39 Dima Kogan wrote:
> 
> Ethan A Merritt <sf...@us...> writes:
> 
> > On Friday, 01 September, 2017 13:01:40 Dima Kogan wrote:
> >> Dima Kogan <gn...@di...> writes:
> >>
> >> > 2. Here I have pixels on x2y2 and latlon on xy. It also appears that
> >> > the thing that gets drawn on the plot is linear in xy, so the image
> >> > requires a nonlinear transformation (and thus we need the "pixels"
> >> > option). How is it decided what is drawn on the plot? What if I wanted
> >> > the drawn output to be linear in the pixels, but the rendered axes to
> >> > be nonlinear? Is this a specifiable choice, or does gnuplot always
> >> > pick the xy axes to render?
> >>
> >> To (partly) answer my own question: the x1y1 axis is rendered to the
> >> screen. So if I take the gnuplot script in question and
> >>
> >> 1. switch the forward/backward transforms in the 'set link' commands
> >> 2. change the plot command to 'axis x1y1' from 'axis x2y2'
> >> 3. change the range specs from touching the x1,y1 axes to the x2,y2 axes
> >>
> >> then the rendered plots look fine even without the "pixels". This is
> >> because in this case, the pixels live on the x1y1 axis, which is then
> >> linear with the output terminal axes, and the y2 axis is then the
> >> nonlinear one, but this doesn't directly affect the rendering.
> >
> > It may "look fine" but only one of the two treatments can be correct.
> > One places the pixels on an evenly spaced grid, the other does not.
> > The two rendered maps are different, although both now have a marker
> > on top of LA.   Both maps are distorted from what I am used to seeing
> > so I cannot say which is intended.
> 
> I guess there are 3 sets of coordinates that are being related to one
> another:
> 
> 1. Pixel coordinates in the rgbimage being plotted
> 2. Gnuplot x1/y1/x2/y2 coordinates
> 3. Terminal coordinates of the output
> 
> I THINK gnuplot always maps x1 and y1 linearly into the terminal
> coordinates, NOT x2 and y2; please tell me if this is wrong.

The x1 and y1 axes may also be nonlinear, but it requires a command
like
        set nonlinear x via f(x) inverse g(x)

The "set link" command will not by itself change the linearity of x1 or y1.

The x2 and y2 axes can also be made nonlinear by a "set link" command.

	Ethan



> At the beginning of this thread I was plotting the rgbimage into x2y2,
> this was nonlinearly mapped to x1y1, which was in turn linearly mapped
> into the terminal coords. I.e. the bitmap was being nonlinearly warped.
> 
> With the variation above, the rgbimage goes into x1y1, so the terminal
> output warps the image linearly-only, and the x1y2 axes instead show the
> nonlinearity.
> 
> The distortion you're seeing is likely due to the linear scaling of the
> x1y1 axes. If you 'set size ratio -1' then you should see exactly the
> images you see at openstreetmap.org, which look "normal" to me since
> I've been looking at them for many years.
> 
> Thanks for the help.

Re: rgbimage plots with linked axes

[Dima K. <gn...@di...>]

Ethan A Merritt <sf...@us...> writes:

> On Friday, 01 September, 2017 13:01:40 Dima Kogan wrote:
>> Dima Kogan <gn...@di...> writes:
>>
>> > 2. Here I have pixels on x2y2 and latlon on xy. It also appears that
>> > the thing that gets drawn on the plot is linear in xy, so the image
>> > requires a nonlinear transformation (and thus we need the "pixels"
>> > option). How is it decided what is drawn on the plot? What if I wanted
>> > the drawn output to be linear in the pixels, but the rendered axes to
>> > be nonlinear? Is this a specifiable choice, or does gnuplot always
>> > pick the xy axes to render?
>>
>> To (partly) answer my own question: the x1y1 axis is rendered to the
>> screen. So if I take the gnuplot script in question and
>>
>> 1. switch the forward/backward transforms in the 'set link' commands
>> 2. change the plot command to 'axis x1y1' from 'axis x2y2'
>> 3. change the range specs from touching the x1,y1 axes to the x2,y2 axes
>>
>> then the rendered plots look fine even without the "pixels". This is
>> because in this case, the pixels live on the x1y1 axis, which is then
>> linear with the output terminal axes, and the y2 axis is then the
>> nonlinear one, but this doesn't directly affect the rendering.
>
> It may "look fine" but only one of the two treatments can be correct.
> One places the pixels on an evenly spaced grid, the other does not.
> The two rendered maps are different, although both now have a marker
> on top of LA.   Both maps are distorted from what I am used to seeing
> so I cannot say which is intended.

I guess there are 3 sets of coordinates that are being related to one
another:

1. Pixel coordinates in the rgbimage being plotted
2. Gnuplot x1/y1/x2/y2 coordinates
3. Terminal coordinates of the output

I THINK gnuplot always maps x1 and y1 linearly into the terminal
coordinates, NOT x2 and y2; please tell me if this is wrong.

At the beginning of this thread I was plotting the rgbimage into x2y2,
this was nonlinearly mapped to x1y1, which was in turn linearly mapped
into the terminal coords. I.e. the bitmap was being nonlinearly warped.

With the variation above, the rgbimage goes into x1y1, so the terminal
output warps the image linearly-only, and the x1y2 axes instead show the
nonlinearity.

The distortion you're seeing is likely due to the linear scaling of the
x1y1 axes. If you 'set size ratio -1' then you should see exactly the
images you see at openstreetmap.org, which look "normal" to me since
I've been looking at them for many years.

Thanks for the help.

Re: rgbimage plots with linked axes

[Ethan A M. <sf...@us...>]

On Friday, 01 September, 2017 13:01:40 Dima Kogan wrote:
> Dima Kogan <gn...@di...> writes:
> 
> > 2. Here I have pixels on x2y2 and latlon on xy. It also appears that
> > the thing that gets drawn on the plot is linear in xy, so the image
> > requires a nonlinear transformation (and thus we need the "pixels"
> > option). How is it decided what is drawn on the plot? What if I wanted
> > the drawn output to be linear in the pixels, but the rendered axes to
> > be nonlinear? Is this a specifiable choice, or does gnuplot always
> > pick the xy axes to render?
> 
> To (partly) answer my own question: the x1y1 axis is rendered to the
> screen. So if I take the gnuplot script in question and
> 
> 1. switch the forward/backward transforms in the 'set link' commands
> 2. change the plot command to 'axis x1y1' from 'axis x2y2'
> 3. change the range specs from touching the x1,y1 axes to the x2,y2 axes
> 
> then the rendered plots look fine even without the "pixels". This is
> because in this case, the pixels live on the x1y1 axis, which is then
> linear with the output terminal axes, and the y2 axis is then the
> nonlinear one, but this doesn't directly affect the rendering.

It may "look fine" but only one of the two treatments can be correct.
One places the pixels on an evenly spaced grid, the other does not.
The two rendered maps are different, although both now have a marker
on top of LA.   Both maps are distorted from what I am used to seeing
so I cannot say which is intended.

	Ethan

Re: rgbimage plots with linked axes

[Dima K. <gn...@di...>]

Dima Kogan <gn...@di...> writes:

> 2. Here I have pixels on x2y2 and latlon on xy. It also appears that
> the thing that gets drawn on the plot is linear in xy, so the image
> requires a nonlinear transformation (and thus we need the "pixels"
> option). How is it decided what is drawn on the plot? What if I wanted
> the drawn output to be linear in the pixels, but the rendered axes to
> be nonlinear? Is this a specifiable choice, or does gnuplot always
> pick the xy axes to render?

To (partly) answer my own question: the x1y1 axis is rendered to the
screen. So if I take the gnuplot script in question and

1. switch the forward/backward transforms in the 'set link' commands
2. change the plot command to 'axis x1y1' from 'axis x2y2'
3. change the range specs from touching the x1,y1 axes to the x2,y2 axes

then the rendered plots look fine even without the "pixels". This is
because in this case, the pixels live on the x1y1 axis, which is then
linear with the output terminal axes, and the y2 axis is then the
nonlinear one, but this doesn't directly affect the rendering.

This popped up another behavior that looks like a bug: 'set y2tics auto'
doesn't work here, and even explicitly asking for y2tics positions
doesn't give me the requested tics, but I want to experiment a bit more
before saying much more about this one.

Re: rgbimage plots with linked axes

[Ethan A M. <sf...@us...>]

On Friday, 01 September, 2017 10:01:26 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > On Thursday, 31 August 2017 23:51:37 Dima Kogan wrote:
> >> sfeam <sf...@us...> writes:
> >>
> >> > On Thursday, 31 August 2017 22:44:01 Dima Kogan wrote:
> >> >> Hi. I just stumbled on another bug with rgbimages. If somebody knows
> >> >> what's causing it, that'd be appreciated.
> >> >
> >> > This is a very complicated one.
> >> > I'll look at it in more detail over the weekend.
> >
> > Never mind. I realized the problem overnight.
> > The "with image" family of plot styles (image rgbimage rgbalpha) use
> > a terminal-specific bitmap display routine if the terminal provides one.
> > This can be much faster than sending the pixels one-by-one.
> > But that only works correctly for linear coordinates, because the
> > only information sent is basically "fill this rectangle with this bitmap".
> >
> > You have nonlinear axes so you need to fall back to calculating the
> > pixel coordinates individually.  The keyword for this is "pixels".
> > So this morning's test is:
> >
> > set xrange [-120:-80] noextend
> > set yrange [20:60] noextend
> >
> > plot "montage_40_-99_1300miles_4.png" \
> >      binary filetype=png flipy axes x2y2 with rgbimage pixels notitle, \
> >      $POINT axes x2y2 with points pt 1 ps 2
> >
> > That seems to work correctly (although slower).
> 
> Aha. That makes it work for me too. Thanks! Two questions:
> 
> 1. Can we detect this failure and throw a warning, maybe? Or turn on
> "pixels" mode automatically?

We can detect if the axis is mapped by "set link" or "set nonlinear",
but not whether the mapping is truly linear or nonlinear.  If the
mapping is linear then the optimized bitmap transfer should still work.
So I don't think we want to fall back to pixels mode just because a
mapping exists.


> 2. Here I have pixels on x2y2 and latlon on xy. It also appears that the
> thing that gets drawn on the plot is linear in xy, so the image requires
> a nonlinear transformation (and thus we need the "pixels" option). How
> is it decided what is drawn on the plot? What if I wanted the drawn
> output to be linear in the pixels, but the rendered axes to be
> nonlinear? Is this a specifiable choice, or does gnuplot always pick the
> xy axes to render?

I don't understand the question.

When you specify coordinates for a drawable object or graph component
you have to tell the program what axial system the coordinates belong to.
See "help coordinates".
The x y x2 y2 axes are normally linear.  You can change this by providing
forward and reverse mapping functions, either mapping onto a hidden linear
axis  ("set nonlinear") or a paired visible axis ("set link").

In the current version of gnuplot you cannot use "set link" to make
both of the paired axes nonlinear;  you would have to manually set up
mappings for both using "set nonlinear" and then set the corresponding
range endpoints for both. 

Does that help?

	Ethan

Re: rgbimage plots with linked axes

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

> On Thursday, 31 August 2017 23:51:37 Dima Kogan wrote:
>> sfeam <sf...@us...> writes:
>>
>> > On Thursday, 31 August 2017 22:44:01 Dima Kogan wrote:
>> >> Hi. I just stumbled on another bug with rgbimages. If somebody knows
>> >> what's causing it, that'd be appreciated.
>> >
>> > This is a very complicated one.
>> > I'll look at it in more detail over the weekend.
>
> Never mind. I realized the problem overnight.
> The "with image" family of plot styles (image rgbimage rgbalpha) use
> a terminal-specific bitmap display routine if the terminal provides one.
> This can be much faster than sending the pixels one-by-one.
> But that only works correctly for linear coordinates, because the
> only information sent is basically "fill this rectangle with this bitmap".
>
> You have nonlinear axes so you need to fall back to calculating the
> pixel coordinates individually.  The keyword for this is "pixels".
> So this morning's test is:
>
> set xrange [-120:-80] noextend
> set yrange [20:60] noextend
>
> plot "montage_40_-99_1300miles_4.png" \
>      binary filetype=png flipy axes x2y2 with rgbimage pixels notitle, \
>      $POINT axes x2y2 with points pt 1 ps 2
>
> That seems to work correctly (although slower).

Aha. That makes it work for me too. Thanks! Two questions:

1. Can we detect this failure and throw a warning, maybe? Or turn on
"pixels" mode automatically?

2. Here I have pixels on x2y2 and latlon on xy. It also appears that the
thing that gets drawn on the plot is linear in xy, so the image requires
a nonlinear transformation (and thus we need the "pixels" option). How
is it decided what is drawn on the plot? What if I wanted the drawn
output to be linear in the pixels, but the rendered axes to be
nonlinear? Is this a specifiable choice, or does gnuplot always pick the
xy axes to render?

Thanks

Re: rgbimage plots with linked axes

[sfeam <sf...@us...>]

On Thursday, 31 August 2017 23:51:37 Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > On Thursday, 31 August 2017 22:44:01 Dima Kogan wrote:
> >> Hi. I just stumbled on another bug with rgbimages. If somebody knows
> >> what's causing it, that'd be appreciated.
> >
> > This is a very complicated one.
> > I'll look at it in more detail over the weekend.


Never mind. I realized the problem overnight.
The "with image" family of plot styles (image rgbimage rgbalpha) use
a terminal-specific bitmap display routine if the terminal provides one.
This can be much faster than sending the pixels one-by-one.
But that only works correctly for linear coordinates, because the
only information sent is basically "fill this rectangle with this bitmap".

You have nonlinear axes so you need to fall back to calculating the
pixel coordinates individually.  The keyword for this is "pixels".
So this morning's test is:

set xrange [-120:-80] noextend
set yrange [20:60] noextend

plot "montage_40_-99_1300miles_4.png" \
     binary filetype=png flipy axes x2y2 with rgbimage pixels notitle, \
     $POINT axes x2y2 with points pt 1 ps 2

That seems to work correctly (although slower).

I moved the "axes x2y2" to match what the documentation shows
but I didn't test whether that makes any difference by itself.
Probably not since the original command was accepted with no warning.
I put the point in a data block because I wanted to be able to
try various refresh/replot commands but again I didn't test whether
it makes any difference by itself. Probably not.

> > For now I'll just note:
> >
> > - The script basically does not work with 5.2 or current cvs, so I assume
> > you are using 5.0?
> 
> I was using "gnuplot 5.1 patchlevel 0", but it wasn't a release. It was
> built from the latest sources as of 2016/11/18. I just tried on the
> latest sources, and the problem is mostly the same.
> 
> 
> > - To make the script work with 5.2 I can move the range outside the plot command:
> >
> >     set xrange [-120:-80]
> >     set yrange [20:60]
> >     plot "montage_40_-99_1300miles_4.png" binary filetype=png flipy ...
> 
> Yep. I had to do this to make it work with the latest sources. Does that
> make sense? This smells like a bug too.

Yeah.   I was going to package up a final 5.2 release this
weekend, but now I'd like to pin that down first, if only to add it as a 
"known problem" in the release notes.

	Ethan

Re: rgbimage plots with linked axes

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

> On Thursday, 31 August 2017 22:44:01 Dima Kogan wrote:
>> Hi. I just stumbled on another bug with rgbimages. If somebody knows
>> what's causing it, that'd be appreciated.
>
> This is a very complicated one.
> I'll look at it in more detail over the weekend.
> For now I'll just note:
>
> - The script basically does not work with 5.2 or current cvs, so I assume
> you are using 5.0?

I was using "gnuplot 5.1 patchlevel 0", but it wasn't a release. It was
built from the latest sources as of 2016/11/18. I just tried on the
latest sources, and the problem is mostly the same.


> - To make the script work with 5.2 I can move the range outside the plot command:
>
>     set xrange [-120:-80]
>     set yrange [20:60]
>     plot "montage_40_-99_1300miles_4.png" binary filetype=png flipy ...

Yep. I had to do this to make it work with the latest sources. Does that
make sense? This smells like a bug too.


> - I'm not sure whether or not I see the same thing as you on zooming.
>   At first glance it looks to me that the zoomed-in placement is correct
>   (point is on top of LA) in the zoom view even though it was not in the
>   original full view.  The closer in I zoom the closer to perfect the superposition
>   becomes.   Is that what you see or do you see something else?

That's what I see too: I zoom on an area that does NOT have the circle
in it (but that SHOULD have it), and I see the zoomed circle post-zoom.


> - So I guess my question is, would it be a correct description to say that
>   the plot is correct but only after a zoom operation?  If so, that sounds
>   easier to track down than  "it's always wrong".

I can't tell. There could be a systematic error, but this is a low-res
map and doesn't have enough detail.


> - One possible problem occurs to me.  The coordinates mapped to an
>   image pixel describe the center of the pixel, not a corner.
>   You may have constructed your mapping with that in mind, or maybe not.
>   If not then perhaps adjusting the mapping function will fix everything.

It's true that I wasn't super careful about this distinction, but I
don't see 0.5 pixels of error, I see 35 pixels of error.

I was hoping that this one wouldn't be tough to track down since one
would expect the rgbimage to be plotted against y2 normally, and against
y2 via a mapping. But here the NORMAL y2 coordinates are becoming
broken. But admittedly I haven't spent much time in looking at the
sources on this one.

Re: rgbimage plots with linked axes

[sfeam <sf...@us...>]

On Thursday, 31 August 2017 22:44:01 Dima Kogan wrote:
> Hi. I just stumbled on another bug with rgbimages. If somebody knows
> what's causing it, that'd be appreciated.

This is a very complicated one.
I'll look at it in more detail over the weekend.
For now I'll just note:

- The script basically does not work with 5.2 or current cvs, so I assume
you are using 5.0?

- To make the script work with 5.2 I can move the range outside the plot command:

    set xrange [-120:-80]
    set yrange [20:60]
    plot "montage_40_-99_1300miles_4.png" binary filetype=png flipy ... 

- At that point I see (I think) the same thing you do in that the single explicit
  point lies North of rather than exactly on top of the Los Angeles marker.

- I'm not sure whether or not I see the same thing as you on zooming.
  At first glance it looks to me that the zoomed-in placement is correct
  (point is on top of LA) in the zoom view even though it was not in the
  original full view.  The closer in I zoom the closer to perfect the superposition
  becomes.   Is that what you see or do you see something else?

- So I guess my question is, would it be a correct description to say that
  the plot is correct but only after a zoom operation?  If so, that sounds
  easier to track down than  "it's always wrong".

- One possible problem occurs to me.  The coordinates mapped to an
  image pixel describe the center of the pixel, not a corner.  
  You may have constructed your mapping with that in mind, or maybe not.
  If not then perhaps adjusting the mapping function will fix everything.

	Ethan

> I'm plotting an image showing a map composed of stitched openstreetmap
> tiles (attached). The mapping between pixels in this image and lat/lon
> is linear in longitude and nonlinear in latitude. I'm plotting the image
> pixels onto x2y2, and using linked axes to get the latitude on y and
> longitude on x. The script is this:
> 
>   set x2tics auto
>   set y2tics auto
> 
>   lon0       = -123.5614
>   lon_offset = 180.0 + lon0
> 
>   zoom = 4.
>   px_to_lon(x) = x/(256. * 2.**4)*360. - 180. + lon_offset
>   lon_to_px(x) = (x-lon_offset+180.)/360. * 2.**zoom * 256.
> 
>   lat_offset_px = 1215.969
> 
>   s1_cos(x)     = (sin(x)+1)/cos(x)
>   inv_s1_cos(x) = asin( (x**2 - 1)/(x**2 + 1) )
> 
>   px_to_lat(x) = inv_s1_cos(exp((1 - (x + lat_offset_px)/(2.**zoom * 256) *2)*pi))*180./pi
>   lat_to_px(x) = (1 - log( (sin(x*pi/180) + 1.)/cos(x*pi/180) )/pi)/2. * 2.**zoom * 256 - lat_offset_px
> 
> 
>   set link x2 via lon_to_px(x) inverse px_to_lon(x)
>   set link y2 via lat_to_px(y) inverse px_to_lat(y)
> 
>   plot [x=-120:-80][y=20:60] "montage_40_-99_1300miles_4.png" binary filetype=png flipy with rgbimage notitle axis x2y2, '-' with points axis x2y2
>   60 419
>   e
> 
> 
> Note that the circle representing Los Angeles lies at pixel coordinates
> 60,419 and I'm plotting a point there. The corresponding latlon is
> roughly -118,34. The pixels are on x2y2 and the point is on x2y2, so
> this point should be rendered in that circle. I'm not seeing that at
> all, however. The point is at y2=419 as it should be, but the Los
> Angeles circle is roughly at y2=448. The x coordinates match properly.
> 
> Furthermore, zooming in makes it clear that gnuplot is confused:
> interactively zooming on the plotted point shows me the zoomed LA
> circle, even though visually the LA circle was elsewhere.
> 
> Any pointers?