Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2006-11-02 11:51:07
|
Here is a bug report from a user: In the following script, the map (for a 3D file) is shifted in the opposite (wrong) direction in the png output file compared to other terminals. set xrange [20:-20] #set xrange [-20:20] plot "a.dat" w image set terminal png; set output "s.png" replot set term postscript color; set out 'a.ps'; replot set term fig color; set out 'a.fig'; replot set out; set term pop Is it a bug in the gd terminal? --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-11-02 16:13:45
|
On Thursday 02 November 2006 03:50 am, Petr Mikulik wrote: > Here is a bug report from a user: > > In the following script, the map (for a 3D file) is shifted in the opposite > (wrong) direction in the png output file compared to other terminals wxt and pdf give the same output as png x11 and postscript give a different result, as you noted. Which is correct? So far as I can see, the documentation says nothing about shifting the image if the axis is rescaled. So strictly speaking I don't think it is a bug because there is no promise of any particular behavior. Having said that, I find the wxt/pdf/png behavior more expected. So if we change existing drivers to make them consistent, I vote for changing x11 and postscript to match the others ==> always place the lower left corner of the image at the requested coordinate origin. > set xrange [20:-20] > #set xrange [-20:20] > > plot "a.dat" w image > > set terminal png; set output "s.png" > replot > set term postscript color; set out 'a.ps'; replot > set term fig color; set out 'a.fig'; replot > set out; set term pop > > > Is it a bug in the gd terminal? > > --- > PM > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > 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 |
|
From: Petr M. <mi...@ph...> - 2006-11-02 17:01:30
|
>> In the following script, the map (for a 3D file) is shifted in the opposite >> (wrong) direction in the png output file compared to other terminals > > wxt and pdf give the same output as png > x11 and postscript give a different result, as you noted. The data are fixed once read from the datafile. Then they are plotted. If the x-axis is set to be reversed, the drawing should be reversed as well. Using 'binary1' file from demo/, try: reset set autoscale fix set xrange [3:-3] #set xrange [-3:3] plot 'binary1' binary u 1:2:($3+$1*0.1+$2*0.3) w image set terminal png; set output "s.png" replot set term postscript color; set out 'a.ps'; replot set term fig color; set out 'a.fig'; replot set out; set term pop There, only the postscript file gives an expected drawing, while x11 and png drawings are wrong. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-11-02 17:16:59
|
On Thursday 02 November 2006 09:01 am, Petr Mikulik wrote:
> >> In the following script, the map (for a 3D file) is shifted in the
> >> opposite (wrong) direction in the png output file compared to
> >> other terminals
> >
> > wxt and pdf give the same output as png
> > x11 and postscript give a different result, as you noted.
>
> The data are fixed once read from the datafile. Then they are
> plotted. If the x-axis is set to be reversed, the drawing should be
> reversed as well.
*None* of the drivers I have tested reversed the drawing.
The PostScript and x11 driver shift it over to the left, but
do not reverse it.
The wxt, png, and pdf driver neither shift nor reverse.
My test command was
set xrange [140:-20]
plot 'blutux.rgb' binary array=128x128 flipy \
format='%uchar%uchar%uchar' using ($1+$2+$3) with image
> Using 'binary1' file from demo/, try:
>
> reset
> set autoscale fix
>
> set xrange [3:-3]
> #set xrange [-3:3]
>
> plot 'binary1' binary u 1:2:($3+$1*0.1+$2*0.3) w image
>
> set terminal png; set output "s.png"
> replot
> set term postscript color; set out 'a.ps'; replot
> set term fig color; set out 'a.fig'; replot
> set out; set term pop
>
>
> There, only the postscript file gives an expected drawing, while x11
> and png drawings are wrong.
Huh? I get identical results in postscript and x11.
But you are correct that in this case the image is reversed in addition
to being shifted. So the various sub-modes of "with image" are
inconsistent as to whether they reverse or do not reverse the image,
even for the *same* output driver.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-11-02 17:35:08
|
On Thursday 02 November 2006 09:16 am, Ethan Merritt wrote:
>
> *None* of the drivers I have tested reversed the drawing.
> The PostScript and x11 driver shift it over to the left, but
> do not reverse it.
Ah, sorry. The change was too subtle for me to notice
using that test image.
Yes, you are right that the PostScript driver reverses
the image and the x11 driver does not. Both post and x11
shift the image to the left, however.
> The wxt, png, and pdf driver neither shift nor reverse.
So we have at least 3 different behaviors.
Here is a test script that makes it obvious what is
happening for any given driver:
#
# Test script for image + reversed x axis
#
set multiplot layout 2,2
set xrange [140:-20]
plot 'blutux.rgb' binary array=128x128 flipy \
format='%uchar%uchar%uchar' using ($1+$2+$3) with image
set xrange [-20:140]
plot 'blutux.rgb' binary array=128x128 flipy \
format='%uchar%uchar%uchar' using ($1+$2+$3) with image
set xrange [3:-3]
plot 'binary1' binary u 1:2:($3+$1*0.1+$2*0.3) w image
set xrange [-3:3]
plot 'binary1' binary u 1:2:($3+$1*0.1+$2*0.3) w image
unset multiplot
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: Petr M. <mi...@ph...> - 2006-11-02 18:01:58
|
> Ah, sorry. The change was too subtle for me to notice > using that test image. > > Yes, you are right that the PostScript driver reverses > the image and the x11 driver does not. Both post and x11 > shift the image to the left, however. > >> The wxt, png, and pdf driver neither shift nor reverse. Your test script is fine ... just now I needed to write "plot 'binary1' binary filetype=gpbin", I wonder why... But I don't agree with your conclusions. I can see that postscript, fig and svg are correct with reversed both x-axis and the image, while png gives shifted non-reversed image and x11 not-shifted not reversed. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-11-02 18:18:02
|
On Thursday 02 November 2006 10:01 am, Petr Mikulik wrote:
> >> The wxt, png, and pdf driver neither shift nor reverse.
>
> Your test script is fine ... just now I needed to write "plot
> 'binary1' binary filetype=gpbin", I wonder why...
>
> But I don't agree with your conclusions. I can see that postscript,
> fig and svg are correct with reversed both x-axis and the image,
> while png gives shifted non-reversed image and x11 not-shifted not
> reversed.
I didn't test fig or svg.
By the way, svg doesn't have native "with image" support,
so I am unclear exactly what code is being testing.
Dan: what other drivers use the fall-back approximation indicated
by this warning message:
NOTICE: Visible pixels form rectangular grid, but
there is no image matrix support for the
active terminal. Reverting to color boxes.
Anyhow, I think you *are* agreeing with my summary.
There are at least 3 different behaviors depending on the
driver type.
post fig svg(+others using same generic code?)
wxt png pdf
x11
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: Petr M. <mi...@ph...> - 2006-11-02 18:25:54
|
> I didn't test fig or svg. > By the way, svg doesn't have native "with image" support, > so I am unclear exactly what code is being testing. Neither fig. They revert to filled polygons, as in pm3d. > Anyhow, I think you *are* agreeing with my summary. > There are at least 3 different behaviors depending on the > driver type. > > post fig svg(+others using same generic code?) > wxt png pdf > x11 Yes, I agree. And the correct is post+fig+svg. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2006-11-02 18:40:37
|
didn't test fig or svg.
> By the way, svg doesn't have native "with image" support,
> so I am unclear exactly what code is being testing.
> Dan: what other drivers use the fall-back approximation indicated
> by this warning message:
>
> NOTICE: Visible pixels form rectangular grid, but
> there is no image matrix support for the
> active terminal. Reverting to color boxes.
Can't recall. All the major ones now have support. fig and svg seem like ones of less popularity but still probably used enough that don't have support. Then there is a big list of terminal drivers that probably don't see much use that have no support.
> Anyhow, I think you *are* agreeing with my summary.
> There are at least 3 different behaviors depending on the
> driver type.
>
> post fig svg(+others using same generic code?)
> wxt png pdf
> x11
Hard to believe I missed this. I recall testing output on several terminals.
Well, I'm having a hard time producing this problem. I'll keep investigating. But I do see a couple things that look different in the "image.dem".
>From a fresh launch of gnuplot (cvs version), this demo:
set title "Automatically recognizing file type and extracting file information"
plot 'demo.edf' binary filetype=auto with image
creates a plot that is square. That is, its as though "square" is active. But I can't recall it being that way. Also, if it is "square", I thought we changed that so the plot appears at the center of the window, not to the left side.
The last demo:
set xrange [-0.5:137.5]
set yrange [-0.5:137.5]
unset border
unset xtics
unset ytics
unset ztics
unset key
unset colorbox
set tmargin 0
set bmargin 0
set rmargin 0
set lmargin 0
set view 60, 45, 1, 1
set label 1 "\"Mirror mirror on the wall,\nwho's the GNUiest penguin of all?\"" at 140,0,40 center
splot 'blutux.rgb' binary array=128x128 flip=y rot=90d origin=(0,0,0) perp = (1,0,0) format='%uchar' using ($1+$2+$3) with image, \
'blutux.rgb' binary array=128x128 flipy rot=90d origin=(+137,+137,0) perp=(0,1,0) format='%uchar' using ($1+$2+$3) with image
has Tux at different angles and offset from what s/he normally is, now covering up the caption. Also, when I try running this last demo from a fresh gnuplot, it fails, saying:
GNUPLOT (plot_image): Image grid must be at least 2 x 2.
GNUPLOT (plot_image): Image grid must be at least 2 x 2.
That could be a long term bug, but one would think I'd have come across such a thing in all the testing that I once did.
So, I'm wondering if a bug has found its way into the code. Or possibly a change was made that now uncovers a bug that existed for a long time.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-11-02 18:57:41
|
Daniel J Sebald wrote: >> From a fresh launch of gnuplot (cvs version), this demo: > > set title "Automatically recognizing file type and extracting file > information" plot 'demo.edf' binary filetype=auto with image > > creates a plot that is square. That is, its as though "square" is > active. But I can't recall it being that way. Also, if it is > "square", I thought we changed that so the plot appears at the center > of the window, not to the left side. Yeah, on the demo gallery at www.gnuplot.info is an example of how I remember this one, i.e., the plots filling the whole space. > > The last demo: > > set xrange [-0.5:137.5] set yrange [-0.5:137.5] unset border unset > xtics unset ytics unset ztics unset key unset colorbox set tmargin 0 > set bmargin 0 set rmargin 0 set lmargin 0 set view 60, 45, 1, 1 set > label 1 "\"Mirror mirror on the wall,\nwho's the GNUiest penguin of > all?\"" at 140,0,40 center splot 'blutux.rgb' binary array=128x128 > flip=y rot=90d origin=(0,0,0) perp = (1,0,0) format='%uchar' using > ($1+$2+$3) with image, \ 'blutux.rgb' binary array=128x128 flipy > rot=90d origin=(+137,+137,0) perp=(0,1,0) format='%uchar' using > ($1+$2+$3) with image > > has Tux at different angles and offset from what s/he normally is, > now covering up the caption. Also, when I try running this last demo > from a fresh gnuplot, it fails, saying: And this one has two instances, oddly enough, on the web page. One is the way originally intended, and one is the incorrect example I'm now seeing in x11. Not sure what has happened, Dan PS: What's with all these fancy "coming attractions" plots? Like some kind of feature film or something. :-) |
|
From: Daniel J S. <dan...@ie...> - 2006-11-02 19:13:59
|
Ethan Merritt wrote: > On Thursday 02 November 2006 10:50 am, you wrote: > >>Well, I'm having a hard time producing this problem. I'll keep >>investigating. > > > You tried the script I posted? Oh yeah! Now I see. Well, this seems like something I probably never thought of testing. Kind of surprising that some drivers come out correct and some not. Where is axis reversal intended to be addressed, I mean generally? Is it supposed to be that the core knows it should invert data, i.e., the core assumes the driver always works from a Cartesian reference frame? (I'm guessing that is not the case based upon the multitude of behaviors.) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-11-02 19:20:40
|
On Thursday 02 November 2006 11:23 am, Daniel J Sebald wrote: > > > > You tried the script I posted? > > Oh yeah! Now I see. Well, this seems like something I probably > never thought of testing. Probably no one else thought of it either; that's why the different drivers implemented it differently. > Kind of surprising that some drivers come > out correct and some not. But what is "correct"? Probably the post/svg version, but let's at least make this a conscious decision. > Where is axis reversal intended to be addressed, I mean generally? Got me. I think it's a hack added in many different places, some of which fight each other. "with image" is not the only plot style to have problems with it. It breaks "filledcurve" also, and almost certainly "histograms" as well. One option is just to document that some plot styles do not work with reversed axes. At least until someone is inspired to clean it up and make sure all plot styles can handle it. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Petr M. <mi...@ph...> - 2006-11-02 21:44:05
|
> But what is "correct"? > Probably the post/svg version, but let's at least make this a > conscious decision. Yes, postscript is correct. Note: the buggy plot appeared when a colleague drawn map of intensity vs decreasing incidence angle (=reversed x-axis) and energy ... and the map was different to the same one but drawn with increasing incidence angle (normal x-axis). --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-11-02 22:11:20
|
On Thursday 02 November 2006 01:43 pm, Petr Mikulik wrote:
> > But what is "correct"?
> > Probably the post/svg version, but let's at least make this a
> > conscious decision.
>
> Yes, postscript is correct.
OK. I will open a bug report that includes the test script.
Since this affects a lot of drivers, and at this time we
don't have a proposed fix for any of them, I don't see that it
will be possible to include a full fix in version 4.2
On the other hand, it seems the driver-independent fall-back
code used by svg and fig does work. So maybe we can include
a work-around in 4.2 that just forces use of the fall-back
code? Something like:
# This is broken for some terminals due to a known bug
plot [3:-3] 'binary1' binary u 1:2:($3+$1*0.1+$2*0.3) \
with image
# However this is a work-around
plot [3:-3] 'binary1' binary u 1:2:($3+$1*0.1+$2*0.3) \
with image generic
where the "generic" keyword forces use of the terminal-independent
code rather than calling term->image()
Dan, is that something you can look into?
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: Daniel J S. <dan...@ie...> - 2006-11-02 22:33:17
|
Ethan Merritt wrote: > On Thursday 02 November 2006 01:43 pm, Petr Mikulik wrote: > >>>But what is "correct"? >>>Probably the post/svg version, but let's at least make this a >>>conscious decision. >> >>Yes, postscript is correct. > > > OK. I will open a bug report that includes the test script. > > Since this affects a lot of drivers, and at this time we > don't have a proposed fix for any of them, I don't see that it > will be possible to include a full fix in version 4.2 > > On the other hand, it seems the driver-independent fall-back > code used by svg and fig does work. So maybe we can include > a work-around in 4.2 that just forces use of the fall-back > code? Something like: > > # This is broken for some terminals due to a known bug > plot [3:-3] 'binary1' binary u 1:2:($3+$1*0.1+$2*0.3) \ > with image > > # However this is a work-around > plot [3:-3] 'binary1' binary u 1:2:($3+$1*0.1+$2*0.3) \ > with image generic > > where the "generic" keyword forces use of the terminal-independent > code rather than calling term->image() > > Dan, is that something you can look into? Another work around could be to just use the keyword "flipx", which already exists. As for a general fix, somehow I don't see this as too difficult if we can decide on where the inversion should be handled. I mean, the image is at least in the right location, its direction is wrong. I would think at worst a fix is a three or four line conditional test inside "plot_with_image..." in connection with changes in each of the drivers that looks incorrect. If it is a decision between adding a comment "known bug" and making an alteration to make that bug less egregious vs. simply fixing the bug even though it may mean twice the amount of work, I'd go with the latter. I can take a closer look and create a patch this weekend. Dan |
|
From: Petr M. <mi...@ph...> - 2006-11-02 22:39:28
|
> Another work around could be to just use the keyword "flipx", which already > exists. Yes, I think this would work as an easy fix which works immediately. > If it is a decision between adding a comment "known bug" and making an > alteration to make that bug less egregious vs. simply fixing the bug even > though it may mean twice the amount of work, I'd go with the latter. I also agree with the latter. > I can take a closer look and create a patch this weekend. We could have a rc2 released afterwards. Will the "ultrix sprintf" bug be fixed somehow? --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-11-02 23:10:49
|
On Thursday 02 November 2006 02:43 pm, Daniel J Sebald wrote: > Another work around could be to just use the keyword "flipx", which > already exists. Yeah, except then the burden is on the user to figure out when it is needed and when it isn't. If you don't already know what the plot is supposed to look like, how do you know whether or not to flip it? > As for a general fix, somehow I don't see this as too difficult if we > can decide on where the inversion should be handled. I mean, the > image is at least in the right location, for x11, not for the others > I would think at worst a fix is a three or four line conditional test > inside "plot_with_image..." in connection with changes in each of the > drivers that looks incorrect. Not sure I follow you. We know that one driver does it correctly when given the info already being passed down by the core. So why would there be any changes needed in the core code? The brokeness must lie in the individual drivers, or at least that's what it seems to me. > If it is a decision between adding a comment "known bug" and making > an alteration to make that bug less egregious vs. simply fixing the > bug even though it may mean twice the amount of work, I'd go with the > latter. I'm not so much concerned about the amount of [someone else's] work, but the chance of breaking other things while fixing this one. I am extremely wary of fixes that touch more than a line or two at the stage of the game. I'd rather go with a warning about a known bug than ship significantly revised code that has had minimal testing. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-11-03 01:47:29
|
Ethan Merritt wrote:
> Not sure I follow you. We know that one driver does it correctly
> when given the info already being passed down by the core.
> So why would there be any changes needed in the core code?
Because two wrongs sometimes make a right. (Not saying that there are two wrongs, just that we aren't certain yet.)
> The brokeness must lie in the individual drivers, or at least
> that's what it seems to me.
>
>
>>If it is a decision between adding a comment "known bug" and making
>>an alteration to make that bug less egregious vs. simply fixing the
>>bug even though it may mean twice the amount of work, I'd go with the
>>latter.
>
>
> I'm not so much concerned about the amount of [someone else's]
> work, but the chance of breaking other things while fixing this one.
> I am extremely wary of fixes that touch more than a line or two
> at the stage of the game. I'd rather go with a warning about a
> known bug than ship significantly revised code that has had minimal
> testing.
This is why I say first decide how the core should be. Make that one change in CVS. Then, everyone can make the appropriate adjustment in the terminal drivers.
Let me explain what I think the change to the core code would be. The following hunk of code figures out the starting point in the raw data along with the integer values to jump through that raw data to get the proper orientation:
/* Set up parameters for indexing through the image matrix to transfer data.
* These formulas were derived for a terminal image routine which uses the
* upper left corner as pixel (1,1).
*/
if (fabs(delta_x_grid[0]) > fabs(delta_x_grid[1])) {
line_length = K;
i_start = (delta_y_grid[1] > 0 ? L : 1) * K - (delta_x_grid[0] > 0 ? K : 1);
i_delta_pixel = (delta_x_grid[0] > 0 ? +1 : -1);
i_delta_line = (delta_x_grid[0] > 0 ? -K : +K) + (delta_y_grid[1] > 0 ? -K : +K);
} else {
line_length = L;
i_start = (delta_x_grid[1] > 0 ? 1 : L) * K - (delta_y_grid[0] > 0 ? 1 : K);
i_delta_pixel = (delta_x_grid[1] > 0 ? +K : -K);
i_delta_line = K*L*(delta_x_grid[1] > 0 ? -1 : +1) + (delta_y_grid[0] > 0 ? -1 : +1);
}
Basically, one has to sit down and think through all the various combinations. I wrote out a little logic table, which is probably in documentation somewhere.
The details of that aren't important. We are going to have axes reversals; that doesn't change the line length. But in this formulae are conditionals based upon sign of delta_x and delta_y. So, if this routine had access to information about the invertedness of the axes it could make the adjustment.
Say axis_x_polarity and axis_y_polarity are two variables reflecting reversedness. Say +1 means non reversed, -1 reversed. Then, in the above formulas change every
delta_x_grid[#] -> delta_x_grid[#]*axis_x_polarity
delta_y_grid[#] -> delta_y_grid[#]*axis_y_polarity
That will put the data in the correct orientation I think. Otherwise, it is going to be up to the terminal driver to reorder the data if that is not an option to the tools used by the driver. I'm fine with that, but let's make sure we want to go that route first.
Similarly, it wouldn't be too difficult to write a formula to send over the proper coordinate for the upper right corner.
Well, I'm curious how this behaves...
#define AXIS_MAP(axis, variable) \
(int) ((axis_array[axis].term_lower) \
+ ((variable) - axis_array[axis].min) \
* axis_array[axis].term_scale + 0.5)
Here's a little experiment. I've added an extra printf to the x11 driver as follows:
TERM_PUBLIC void
X11_point(unsigned int x, unsigned int y, int number)
{
fprintf(stderr,"P%d %d %d\n", number, x, y);
PRINT3("P%d %d %d\n", number, x, y);
}
And tried the following:
gnuplot> set xrange [-10:10]
gnuplot> plot x with points
P0 325 236
P0 362 274
P0 398 312
...
gnuplot> set xrange [10:-10]
gnuplot> plot x with points
P0 3961 236
P0 3924 274
P0 3888 312
...
The first plot is visually a positive sloped line. The coordinates coming over from gnuplot core are positive sloped.
The second plot is visually a negative sloped line. The coordinates coming over from gnuplot are now also negative sloped.
We're plotting the same function. Therefore, I'm concluding that the core routine assumes the terminal coordinate system is conventional Cartesian, and the core is where the axis direction is handled.
We should then have the image routine correctly orient data and choose the proper coordinate to correspond to the terminal driver image upper left corner.
Agreed?
I can do this over the weekend and make sure x11 is working. That would serve as an initial patch. Then we can fix others.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-11-03 04:07:47
Attachments:
image_orientation_djs_2nov2006.patch
|
Attached is a patch to adjust the orientation of the image as I suggested in the last email. Now, this isn't CVS quality. But it can give you an idea of how to fix this issue. I've checked x11, PNG, postscript. Please try other to check if the orientation is correct. You may notice there is a slight issue with pixel offset by one on depeneding on axis direction. This weekend I will look at fixing that. But since we are on this and looking at image innards, we could also address a crossroads Ethan and I came to with a couple things: 1) Flipping in the y direction according to the pixel 1,1 in the upper left corner versus lower left. It tied in with... 2) Exactly how should position the image? With respect to the pixel center or the outer edge of a pixel? That is imagine plotting an image so that it's lower left corner is at (0,0). Should pixel M,1 (in terms of matrices) center be at (0,0)? Or should the bounding box of the image be at (0,0)? To understand what I'm talking about, try this example that puts the borders tightly around the image: set xrange [-0.5:127.5] set yrange [-0.5:127.5] set tics out set label 1 "Selection of the input channels via \`using\`" at 140,160 center set title '"I do impersonations..."' offset 0,-0.5 plot 'blutux.rgb' binary array=128x128 flip=y format='%uchar' using 1:2:3 with rgbimage Zoom in real close with the mouse at the origin. Since there is no x,y info in this data, gnuplot assumes x=0,1,...,127. Same for y. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-11-03 07:20:48
|
On Thursday 02 November 2006 08:17 pm, Daniel J Sebald wrote: > Attached is a patch to adjust the orientation of the image as I suggested in the last email. > Now, this isn't CVS quality. But it can give you an idea of how to fix this issue. > I've checked x11, PNG, postscript. Please try other to check if the orientation is correct. Orientation is ok for wxt, svg, pdf as well. However, this change seems to have messed up the plot layout and estimated space requirements. All of the plots are now squished in the horizontal, leaving half the space on the canvas empty. I suspect there is some other place entirely in the code that also needs to be changed in parallel to this. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
