Re: pngcairo: suggestion for additional option

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

On Wednesday 26 December 2007 14:11, Allin Cottrell wrote:
> On Tue, 25 Dec 2007, Ethan A Merritt wrote:
> 
> > On Wednesday 19 December 2007 08:16, Allin Cottrell wrote:
> > > I'm attaching a new .tgz file with 3 small patches, to 
> > > term/cairo.trm, src/eval.c and src/term_api.h.  Jointly these 
> > > implement the writing of plot pixel bounds, with a possible scale 
> > > factor, using a new scalar variable rather than a new function 
> > > pointer.
> > 
> > I like the idea, but unfortunately this code isn't working.
> > If you look closely, you will find that the y coordinates being
> > reported by this code are off by 17 pixels in the default 640x480
> > ouput from either 'set term png' or 'set term pngcairo'...
> 
> Hmm, could you explain how you're coming to that judgment?  

I read out mouse coordinates using either display (ImageMagick) or GIMP
while displaying the png image output by gnuplot.  The true pixel coord
of the lower border of the plot area is 

> The way I'm testing this is (in my program, gretl) is by 
> displaying the PNG (at present, produced by the pngcairo term) in 
> a GTK window, with a mouse-over feedback mechanism that prints the 
> data coordinates.  

If you write your own mouse read-out then of course you can
apply whatever mapping you want.
 
> Anyway, I find that the readback is perfectly accurate: the data 
> coordinates seem right and they kick out just at the very edge of 
> the plot.  I've tried this with plots of 640x480 and 680x400.

Sure, I'm not questioning the accuracy.  The problem is in the
convention that defines y.  If I create a plot using
   set term pngcairo
   set output 'cairo.png'
   plot sin(x)/x
   show var all
I get 
        TERM_XMIN = 64
        TERM_XMAX = 615
        TERM_YMIN = 37
        TERM_YMAX = 460
If I now open up cairo.png in GIMP or ImageMagick, I get y pixel
readouts:
	bottom of plot	443             (= 480 - 37)
	top of plot      20		(= 480 - 460)
Notice that the convention is that Y=0 at the top of the image.
The problem comes if one tries to interpret the bounds [37:460]
as refering to the offset in pixels from the bottom of the image.
If you do that, then the values are off by 17 pixels.

Maybe that's OK.  But it puts the burden on the program that
eventually interprets pixel coords to know what convention is being
used.   The messier case is for PostScript, where so far as I can see
there is no obvious place to pick up the coordinates of the origin of
the plot relative to the origin of the page.


	best regards,

		Ethan



 
> Here's the function I'm using to compute the data coordinates, 
> given integer x and y as reported by GTK from the mouse pointer,
> relative to the window holding the PNG:
> 
> static void get_data_xy (png_plot *plot, int x, int y, 
> 			 double *data_x, double *data_y)
> {
>     double dx, dy;
> 
>     *data_x = plot->xmin + ((double) x - plot->pixel_xmin) / 
> 	(plot->pixel_xmax - plot->pixel_xmin) * 
>         (plot->xmax - plot->xmin);
> 
>     *data_y = ymax - ((double) y - plot->pixel_ymin) / 
> 	(plot->pixel_ymax - plot->pixel_ymin) * 
>         (plot->ymax - plot->ymin);
> }
> 
> where the relevant members of the my png_plot structure have the 
> following relationships with gnuplot variables (as read from an 
> auxiliary test file produced using gnuplot's print command):
> 
> plot->pixel_xmin <- TERM_XMIN
> plot->pixel_xmax <- TERM_XMAX
> plot->pixel_ymin <- plot->pixel_height - TERM_YMIN
> plot->pixel_ymax <- plot->pixel_height - TERM_YMAX
> 
> plot->xmin <- GPVAL_X_MIN
> plot->xmax <- GPVAL_X_MAX
> plot->ymin <- GPVAL_Y_MIN
> plot->ymax <- GPVAL_Y_MAX
> 
> plot->pixel_height is, e.g. 480 for a 640x480 PNG, as you might 
> expect!
> 
> Allin Cottrell
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

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