Re: imshow.m

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: imshow.m

Daniel Sebald
Daniel J Sebald wrote:

> Are the "zoom" parameters in the image routines necessary anymore?

I ask because I see that the ImageMagick plots can be zoomed manually.  Anyway...

John, attached is a short patch to restore the colormap after using imshow().  If the colormap changes using imshow(R,G,B), then future use of image(A) is messed up.

As you might guess, the imshow() routine builds an RBG image by creating a value in the palette for each pixel.  Not the best of approaches.  I wonder if the image routines could leave things open for the graphics driver to determine how to implement.

Related to that is how to implement selecting the graphics driver to use.  Has anyone thought that out yet?  If so, please let me know.

My thoughts are that there could be __image__.m, __image_rgb__.m, __imshow__.m, __imshow_rgb__.m, etc. used within the generic image.m, imshow.m, etc. files.  Just like as was done with __plot__.m, etc.  Now it would be up to the graphics driver to supply the files __image__.m, __plot__.m, etc and they could be kept in a separate subdirectory, e.g., "gnuplot".  Then, in order to choose the graphics engine, one sets a variable like

GRAPHICS = "gnuplot";

to choose the subdirectory name for where to look for these scripts.

If there is already an existing structure, I'd be happy to know the concept.

Dan

--- imshow_gp.m.old 2006-02-21 21:33:31.000000000 -0600
+++ imshow_gp.m 2006-02-22 02:47:39.070091408 -0600
@@ -172,8 +172,10 @@
     endfor
   endif
 
+  T = colormap();  ## Temporarily save map
   colormap (M);
   image (I, zoom);
+  colormap(T);     ## Restore map
 
 endfunction
 
Reply | Threaded
Open this post in threaded view
|

Re: imshow.m

Daniel Sebald
Daniel J Sebald wrote:

> John, attached is a short patch to restore the colormap after using
> imshow().  If the colormap changes using imshow(R,G,B), then future use
> of image(A) is messed up.

I've been informed that other programs like Octave behave this way.  But that doesn't mean Octave doesn't have to operate the right way.  Why should the global color map change unless I type "colormap(ocean(64))" or some such?

Dan

Reply | Threaded
Open this post in threaded view
|

Re: imshow.m

Stéfan van der Walt
On Wed, Feb 22, 2006 at 04:04:56AM -0600, Daniel J Sebald wrote:

> Daniel J Sebald wrote:
>
> >John, attached is a short patch to restore the colormap after using
> >imshow().  If the colormap changes using imshow(R,G,B), then future use
> >of image(A) is messed up.
>
> I've been informed that other programs like Octave behave this way.  But
> that doesn't mean Octave doesn't have to operate the right way.  Why should
> the global color map change unless I type "colormap(ocean(64))" or some
> such?

I agree.  imshow shouldn't touch the colormap.

Stéfan