bugGNU Octave - Bugs: bug #48664, imshow for binary data: colormap...

 
 

bug #48664: imshow for binary data: colormap not handled correctly for gnuplot

Submitter:  None
Submitted:  Sun 31 Jul 2016 12:24:51 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 01 Sep 2016 08:26:15 PM UTC, comment #7: 

@Dan: I pushed your patch for color mapping here (http://hg.savannah.gnu.org/hgweb/octave/rev/be969d43d95f).

Closing report.

Rik <rik5>
Group administrator
Sat 06 Aug 2016 07:31:31 AM UTC, comment #6: 

OK, here's a new version of the patch, after having had some discussion on color mapping:

https://savannah.gnu.org/bugs/?48666

I did significant rework of the way scaling is done.  The code currently has gnuplot cbrange as [clim(1):clim(2)], but that actually makes things more difficult.  Instead, I set up the cbrange to [1:cmap_sz] which means that the linear mapping is pretty much as defined in terms of index value.

So, this new patch should fix the special logical-value images, and it should also make the examples at the above link consistent with Qt toolkit.  Try the examples below.


a = rand(10,10);
imshow((a > 0.5));
imshow((a > 0.5), [1,0,0;0,1,0]);
set(gca,'climmode','manual');
set(gca,'clim',[3 5]);

clf
demo('surf', 1)
kids = get(gca,'Children');
set(kids(1),'cdatamapping','scaled')
set(gca,'climmode','manual')
set(gca,'clim',[0 1]);
set(kids(1),'cdatamapping','direct');


(file #38124)

Dan Sebald <sebald>
Wed 03 Aug 2016 07:04:18 AM UTC, comment #5: 

I'm attaching an updated version of the patch to get rid of an introduced bug where the first demo of isosurface, i.e.,

demo('isosurface', 1)

failed.  The problem was that the surfaces had only one color, so the linear scaling formula failed because dividing by (cmax - cmin) is dividing by zero and created a NaN for the color.  The default is 'scaled' for 'cdatamapping', so what to do?  Just leave the color as is, I guess.

(file #38082)

Dan Sebald <sebald>
Mon 01 Aug 2016 06:54:25 AM UTC, comment #4: 

Attached is a patch that should fix this particular bug.  But it is actually more extensive than that.  I went through some demos for images, surfaces and patches and made the color data (i.e., 'cdata') scaling behave in a more logical way.  Whether it is what we are looking for, I'm not 100% sure, but it is certainly much better than it was.  I opened bug report https://savannah.gnu.org/bugs/index.php?48666 to address further issues.


(file #38062)

Dan Sebald <sebald>
Sun 31 Jul 2016 11:06:57 PM UTC, comment #3: 

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?

Dan Sebald <sebald>
Sun 31 Jul 2016 04:21:05 PM UTC, comment #2: 

Ups. I misread your bug report.  Your issue really is that the figure is all red.  I'm guessing you are using gnuplot.  I can reproduce it.

In the mean time, this should work correctly for you if you set graphics_toolkit to qt or fltk.

Carnë Draug <carandraug>
Group Member
Sun 31 Jul 2016 04:10:01 PM UTC, comment #1: 

I can't replicate this on Octave 4.0.1 or on the recent development sources (b8a3c5fc2b33). I'm using qt as graphics toolkit.  I see an issue if I change to gnuplot but it's different from what you reported (everything is red, and not black and white).

You reported this as using dev release.  Can you give more details on your configuration?

Carnë Draug <carandraug>
Group Member
Sun 31 Jul 2016 12:24:51 PM UTC, original submission:  

for binary data imshow will by default produce a black and white plot. The colors can be changed by specifying a colormap:


a = rand(10,10);
imshow(a > 0.5, [1,0,0;0,1,0]);
pause


with octave this will result in an all red plot. Matlab gives a red/green plot. (See attachment)

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-06 rik5 StatusNone Fixed
        Open/ClosedOpen Closed
    2016-08-06 sebald Attached File- Added octave-gnuplot_bug48664_cdatamapping-djs2016aug06.patch, #38124
    2016-08-03 sebald Attached File- Added octave-gnuplot_cdatamapping-djs2016aug03.patch, #38082
    2016-08-01 sebald Attached File- Added octave-gnuplot_cdatamapping-djs2016aug01.patch, #38062
    2016-07-31 carandraug CategoryPlotting Plotting with gnuplot
        Summaryimshow for binary data: colormap not handled correctly? imshow for binary data: colormap not handled correctly for gnuplot
    2016-07-31 None Attached File- Added imshow_R2015b.png, #38056

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code