On 2/9/07, John W. Eaton <address@hidden> wrote:
On 8-Feb-2007, Daniel J Sebald wrote:
| Ok, some more questions. I see the issue with imshow(r,g,b).
| Legacy code converts those r,g,b components to a color map. That's
| not required and probably not preferred. Gnuplot can handle r,g,b
| components.
|
| Should there be a general function, say __img__.m to handle all the
| cases of imshow, image, and imagesc?
If there is duplication functionality, then yes it wouldn't hurt to
handle common cases in a single function.
| I guess a more basic question is should there be another "image"
| type, e.g., "rgbimage", or do both fall under the class "image"?
| I.e., another case?
|
| case "image"
| if (have_img_data)
| warning ("an axis can only display one image");
| endif
| have_img_data = true;
| img_data = obj.cdata;
As far as I know, there is only one "image" graphics object type in
Matlab, so for compatibility that's what we have.
| Having multiple images shouldn't be too difficult.
What is needed to do that? Do you mean it would not be too hard to do
this in Octave now, or that it would not be hard to make gnuplot
handle multiple images on the same plot?
| However, one thing the file __uiobject_draw_axes__ loses is the
| order in which things are plotted. Right now it is always image on
| the bottom, but I'd think that the user may not always want that.
| Why not retain the order of plotting? I'd think it wouldn't be too
| difficult to build the plot string when going through the for loop.
OK, but I think we have to go through the list of all data to be
plotted at least twice to handle autoscaling of axes. And so that
Octave knows what the autoscaled axis limits are since we are not
leaving that to gnuplot since we currently have no good way to get
that information back from gnuplot.
Although "Premature optimization is the root of all evil", the way I handle this in octplot is that at object creation it's max & min are calculated and stored in the object, and this is used each time to get axes limits -- thus you do have to traverse the object tree to get the axes limits, but you do need to cal max/min of (possibly) very large datasets each time you want to draw.
Also, why not do it in one for loop:
construct the plotting string and get the limits in the same loop. At the end of the loop, append the limits statement.
I am sorry that I am not submitting a patch -- I did not go into the code yet.
And yes, I know about the print
feature, but we don't have two-way communication with gnuplot, and
that is more than I want to deal with at the moment. But hey, I'd
take a clean patch.
jwe