octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: images


From: Daniel J Sebald
Subject: Re: images
Date: Fri, 09 Feb 2007 03:24:11 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

John W. Eaton 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've done this.  Since there is to be color components and a colormap, they 
differ very little.  Limits are similar.  Seems worth doing right now.


| 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.

Yes, cdata can probably be three dimensional for the RGB components.  I've done 
that.


| 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?

Gnuplot can handle multiple images in the same command as far as I know.  
However, for now I'm leaving just one image per axis.  So, there can be 
multiple images via subplot.  That seems useful enough to satisfy most right 
now.  Multiple images on the same axis shouldn't be difficult.

With that in mind.  For the time being I'm keeping the colormap as part of the 
axis array.  Doesn't it seem logical that in one subplot we could have one 
colormap and in another subplot a different colormap?  Well, I've implemented 
this, but unfortunately there seems to be a bug in gnuplot where the color map 
changes for both images.  I thought I'd fixed that quite a while ago.  I'll 
investigate.


| 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.  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.

Yes, I came to that same conclusion.  I'll leave that for not.  Not too much at 
one time.

Dan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]