Re: Fast image markup?

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

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