[Octave-bug-tracker] [bug #48664] imshow for binary data: colormap not handled correctly for gnuplot

[Dan Sebald]

Follow-up Comment #3, bug #48664 (project octave):

OK, I agree this is a bug, and I know where to fix the problem.  However,
making the change seems to break a few other demos in the image() and imshow()
scripts for the gnuplot toolkit.

Let's first agree on the meaning of the properties related to color and
mapping.  For this little red/green color map example, I see:


octave:21> get(get(gca,'children'),'cdata')
ans =

  1  1  1  1  0  0  0  0  1  1
  1  0  1  1  1  0  0  0  0  0
  1  1  0  1  0  1  0  1  1  1
  0  1  0  0  0  1  1  1  1  1
  0  0  0  0  1  0  0  1  0  1
  1  0  1  1  0  1  0  1  0  0
  0  0  0  0  0  0  1  1  1  1
  1  0  0  1  0  1  0  0  0  0
  0  1  1  1  1  0  0  0  0  0
  0  0  1  1  1  1  1  1  0  0

octave:22> get(get(gca,'children'),'cdatamapping')
ans = direct
octave:23> get(gca,'clim')
ans =

   0   1


The above makes sense, in that the data is supposed to placed directly into
the clim range.  A 0 corresponds to clim(1), i.e., 0 or red.  A 1 corresponds
to clim(2), i.e., 1 or green.

However, if I look at demo 1 for image(), I'm seeing


octave:24> demo image
image example 1:
 clf;
 colormap (jet (21));
 img = 1 ./ hilb (11);
 x = y = -5:5;
 subplot (2,2,1);
  h = image (x, y, img);
  ylabel ("limits = [-5.5, 5.5]");
  title ("image (x, y, img)");
 subplot (2,2,2);
  h = image (-x, y, img);
  title ("image (-x, y, img)");
 subplot (2,2,3);
  h = image (x, -y, img);
  title ("image (x, -y, img)");
  ylabel ("limits = [-5.5, 5.5]");
 subplot (2,2,4);
  h = image (-x, -y, img);
  title ("image (-x, -y, img)");

octave:25> get(get(gca,'children'),'cdata')
ans =

    1    2    3    4    5    6    7    8    9   10   11
    2    3    4    5    6    7    8    9   10   11   12
    3    4    5    6    7    8    9   10   11   12   13
    4    5    6    7    8    9   10   11   12   13   14
    5    6    7    8    9   10   11   12   13   14   15
    6    7    8    9   10   11   12   13   14   15   16
    7    8    9   10   11   12   13   14   15   16   17
    8    9   10   11   12   13   14   15   16   17   18
    9   10   11   12   13   14   15   16   17   18   19
   10   11   12   13   14   15   16   17   18   19   20
   11   12   13   14   15   16   17   18   19   20   21

octave:26> get(get(gca,'children'),'cdatamapping')
ans = direct
octave:27> get(gca,'clim')
ans =

   0   1


So, why should that work?  Well, this is a case of another property having an
influence on matters, the "climmode".  If "climmode" has a value "auto", then
apparently a scaling is do be done as well.  So, regardless of what I said
about the first example, the clim shouldn't have a bearing on the result.

The subtlety here lies in where the responsibility for determining "clim"
should be.  If the "climmode" is auto, shouldn't something be setting the
"clim" automatically?  In the jet-map example, shouldn't "clim" be showing


 ans =

   1   21


if it automatically adapts?  (Or does one think the toolkit should just be
computing the [1 21] on its own?)

Here's where this question is important.  If the current axes has the
"climmode" auto, and then there are multiple items, it should adapt to that
whole range of cdata.  Consider slightly altering the example by placing two
images side by side and one of the images has color values in a different
range.  (Use, graphics toolkit 'qt' if you like):


octave:46> clf;
octave:47> colormap (jet (21));
octave:48> img = 1 ./ hilb (11);
octave:49> x = y = -5:5;
octave:50> xlim([-8,25])
octave:51> h = image (x, y, img);
octave:52> hold on
octave:53> h = image (x+15, y, img+30);
octave:54> xlim([-8,25])
octave:55> kids = get(gca,'Children')
kids =

  -18.784
  -19.925

octave:56> get(kids(1),'cdatamapping')
ans = direct
octave:57> get(kids(2),'cdatamapping')
ans = direct
octave:58> get(gca,'clim')
ans =

   0   1

octave:59> get(gca,'climmode')
ans = auto


I'm seeing an image on the left which is the typical jet pattern, but on the
right is an all-red pattern, i.e., the highest value of the color map. 
Shouldn't the jet pattern be more distributed about both images?

I'm trying different clim/mode settings for 'qt', and nothing changes:


octave:60> set(gca,'climmode','manual')
octave:61> set(gca,'clim',[0 1])
octave:62> set(gca,'clim',[0 41])
octave:63> set(gca,'clim',[0 51])


So, I'm thinking there are multiple bugs here:

1) The gnuplot bug, which I can fix.

2) A 'qt' bug in which climmode of 'manual' appears to have no effect.

3) A more general climmode 'auto' bug in which the clim scaling doesn't appear
to take in cdata values for all objects on the axes.  I suppose the toolkits
can address this as well, but it seems better for the more general graphics
code to determine this and update "clim" appropriately.

Thoughts?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48664>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/