bugGNU Octave - Bugs: bug #48666, CLimMode/CDataMapping not quite...

 
 

bug #48666: CLimMode/CDataMapping not quite functioning correctly

Submitter:  Dan Sebald <sebald>
Submitted:  Mon 01 Aug 2016 06:52:56 AM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 09 Aug 2016 02:38:04 PM UTC, comment #7: 

The first issue is still a question.  I think we agree that Matlab seems like a bug in that regard, i.e., why should the first object with color get preference?  But it's not a pressing issue and a new bug report can be opened at a later time if someone complains about it.

The second issue is actually correct in FLTK/Qt toolkits and gnuplot toolkit is the one that isn't consistent, but that is corrected with the patch at https://savannah.gnu.org/bugs/index.php?48664.

Given that, there isn't a need to attach any patches to this bug report, so it might as well be closed.

Dan Sebald <sebald>
Tue 09 Aug 2016 12:52:12 PM UTC, comment #6: 

Dan, can this bug report be closed now? Or are there still any open issues?

Markus Mützel <mmuetzel>
Group administrator
Sat 06 Aug 2016 07:33:35 AM UTC, comment #5: 

I've updated the patch of bug 48664

https://savannah.gnu.org/bugs/index.php?48664

to make color map behavior consistent between gnuplot and Qt toolkits.

Dan Sebald <sebald>
Thu 04 Aug 2016 07:35:26 PM UTC, comment #4: 

Hmm.  OK, so image has a default 'cdatamapping' of 'direct', different from surface.  I think I get it now--sort of.

So, 'cdatamapping' 'direct' means to not even use the cmap.  It just indexes into the colormap, as you say in 1.  That is why 'image' is 'direct' by default because image processing applications often work that way.

Some different terms from 'direct' and 'scaled', e.g., 'none' and 'clim' or 'colormap' might have avoided the confusion.  Nonetheless, I will think this over and check things this evening again.

Dan Sebald <sebald>
Thu 04 Aug 2016 06:23:59 PM UTC, comment #3: 

Attached please find the results in Matlab for the two plots from the second example in comment #0.
The "all purple" in Qt might be very similar colors from Octave's default color map.

After some more tests and reading, I believe Octave's Qt behaves correctly (see also [1]):
1. For 'CDataMapping' set to 'direct', the 'CData' are used directly as indices into the colormap. Negative indices seem to be mapped to 0. Since the CData in your example has a maximum at around 8 it only maps into the first 8 elements of the 64 element color map. All of these colors are mostly purple.

2. For 'CDataMapping' set to 'scaled', the 'CLim' values are used to map to the extrema of the colormap. All 'CData' outside of the 'CLim' range are mapped to the first or last element in the colormap, respectively.

I did not check, but shouldn't 'CLim' be calculated from all objects whose 'CDataMapping' is set to 'scaled'?

[1] http://de.mathworks.com/help/matlab/creating_plots/the-image-object-and-its-properties.html#f2-14252


Markus Mützel <mmuetzel>
Group administrator
Tue 02 Aug 2016 02:45:21 AM UTC, comment #2: 

Perfect compatibility to Matlab hasn't been a major issue for me.  Making sense and the ability to configure things the way the user might want seems valid to me.

The second example is behaving correctly generally, it's just that if one looks at the data and the manual CLim range, the colors don't seem to make sense.

I'm attaching the gnuplot toolkit result to give you an example of what I think the colors should be:


octave:1> clf
octave:2> demo('surf', 1)
surf example 1:
 clf;
 colormap ('default');
 Z = peaks ();
 surf (Z);
 title ({'surf() plot of peaks() function'; 'color determined by height Z'});

octave:3> kids = get(gca,'Children');
octave:4> set(kids(1),'cdatamapping','scaled')
octave:5> set(gca,'climmode','manual')
octave:6> get(gca,'clim')
ans =

  -6.5466   8.0752

octave:7> print('-dpng', 'gnuplot_surf_cdatamapping-scaled_climmode-manual-computed-6.5466-8.0752_bug48666.png');
octave:8> set(gca,'clim',[0 1])  # This is a bug, should still look the same because 'scaled'
octave:9> print('-dpng', 'gnuplot_surf_cdatamapping-scaled_climmode-manual-0-1_bug48666.png');
octave:10> set(kids(1),'cdatamapping','direct')
octave:11> get(gca,'clim')
ans =

   0   1

octave:12> print('-dpng', 'gnuplot_surf_cdatamapping-direct_climmode-manual-0-1_bug48666.png');
octave:13>


The color for 'gnuplot_surf_cdatamapping-direct_climmode-manual-0-1_bug48666.png' looks correct to me.  The data of the surface ranges from -6.5466 to 8.0752 so only that data in the band from [0 1] has non-extremal values.  Everything from -6.5466 to 0 is mapped to purple.  Everything from 1 to 8.0752 is mapped to yellow.  This is what Qt is generating for the cdatamapping='scaled', climmode='manual' case, but I believe that is wrong.  The 'scaled' property should make the second plot appear similar to the first plot.  Where Qt is getting that all purple from in the last case I'm not sure.


Dan Sebald <sebald>
Mon 01 Aug 2016 12:28:07 PM UTC, comment #1: 

For what it is worth: Matlab and Octave produce the same plot for your first example: The left image in rainbow colors (jet) and the right one in maroon.
Even if the colors in the second (and third) example are slightly different (differences in default color maps), the results of Octave (before the patch from bug #48664) and Matlab are essentially the same.

Although the first example definitely looks like a bug in Matlab, fixing it in Octave would break compatibility to Matlab which imho should be considered before making any change to the behavior here.

I cannot comment on the second example. But just wanted to share what Matlab does in that case.

Markus Mützel <mmuetzel>
Group administrator
Mon 01 Aug 2016 06:52:56 AM UTC, original submission:  

In fixing a color map bug in the gnuplot graphics toolkit, I've discovered that more broadly color isn't scaling quite right.  The pertinent variables are


IMAGE/SURFACE/PATCH OBJECT
  'cdata'
  'cdatamapping'  [ {direct} | scaled ]

AXES
  'clim'
  'climmode'  [ {auto} | manual ]

FIGURE
  'colormap'


If the axes climmode is "auto", then clim is computed from the min and max of 'cdata' of all the color objects in the axes for which 'cdatamapping' is value 'direct'.  Here is an example which shows the bug:


clf;
colormap (jet (21));
img = 1 ./ hilb (11);
x = y = -5:5;
h = image (x, y, img);
hold on
h = image (x+15, y, img+30);
xlim([-8,23])
kids = get(gca,'Children')
get(kids(1),'cdatamapping')
get(kids(2),'cdatamapping')
get(gca,'clim')
get(gca,'climmode')


Notice that the second image is all maroon, i.e., the maximum value in the color map.  It appears that only the first object is being used to determine the max and min values of cdata.

In bug report https://savannah.gnu.org/bugs/index.php?48664 I have placed a patch for gnuplot that does a first pass through all the graphical objects to get the min/max for all cdata.  The resulting image that I believe is correct is attached here as a PNG.  Notice how the colors are now mapped across the wider range.  It actually makes things easier to program with the clim from the first pass because then 'clim' needs little extra treatment when setting the cbrange--it's already computed.

So, if you agree the above change for gnuplot is correct, the question becomes whether it should be the more general graphics routines that first run through all children looking for the proper clim.  If so, then I can back out what would otherwise be extraneous code in gnuplot toolkit (i.e., the portion near the top of the file).

OK, second issue is that Qt toolkit doesn't appear to scale properly in the following scenario


clf
demo('surf', 1)
kids = get(gca,'Children');
set(kids(1),'cdatamapping','scaled')
set(gca,'climmode','manual')
get(gca,'clim')
set(gca,'clim',[0 1])  # This is a bug, should still look the same because 'scaled'


Even though the 'climmode' is 'manual', the color for the surface (mostly purple for the negative values, but bright for positive values) should still be scaled to fit the 'clim' and look exactly the same as the original demo because 'cdatamapping' is 'scaled'.  Now continue with:


set(kids(1),'cdatamapping','direct')
get(gca,'clim')


but the plot should look like the previous example (mostly purple negative), but instead it appears to be almost all purple.  If one wants to understand what I'm describing (pasting PNGs would just be confusing), apply the patch from https://savannah.gnu.org/bugs/index.php?48664 and try the same example for the gnuplot toolkit and contrast the 'qt' toolkit result.

Dan Sebald <sebald>

 

(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 (Updated the item)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by sebald (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-06 rik5 Open/ClosedOpen Closed
    2016-08-04 mmuetzel Attached File- Added Matlab_surf_cdatamapping-direct_climmode-manual-0-1_bug48666.png, #38108
        Attached File- Added Matlab_surf_cdatamapping-scaled_climmode-manual-0-1_bug48666.png, #38109
    2016-08-02 sebald Attached File- Added gnuplot_surf_cdatamapping-scaled_climmode-manual-computed-6.5466-8.0752_bug48666.png, #38070
        Attached File- Added gnuplot_surf_cdatamapping-scaled_climmode-manual-0-1_bug48666.png, #38071
        Attached File- Added gnuplot_surf_cdatamapping-direct_climmode-manual-0-1_bug48666.png, #38072
    2016-08-01 sebald Attached File- Added gnuplot_cdatamapping_direct_bug48664.png, #38061

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code