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