bar() function broken for large data sets when bar color is changed?

Hi, I am using the bar() function to plot detailed histograms of 12-bit image data, e.g. using 4096 bins. But I am having some problems when I change the bar color. It seems that the bar plot gets corrupted when there are a large number of data points; but there is no problem if (a) the bar color is left as default and/or (b) fewer data points are used.

Here's an example that reproduces the problem (figure 2 is the corrupt one):

% Create a detailed histogram 
x = 128*round(32*rand(1,100^2)); % <- Some random data with histogram gaps
[n,b] = hist(x,128*32); % 128*32=4096

figure;
bar(b,n); % This one looks ok, using default color
figure;
bar(b,n,'r'); % Should look the same as the first one (only red), but is an unreadable mess.

% Compare to plotting only a subset of the histogram:
subrange = 1:400;
figure;
bar(b(subrange),n(subrange));
figure;
bar(b(subrange),n(subrange),'r'); % Only 400 data points, looks fine!

Am I doing something wrong or is this a bug? I am using R2014a (8.3.0.532)

Thanks, BG

[the cyclist]

All four figures look fine to me. (I'm using the same MATLAB version, on a Mac running OS X 10.9.3.)

Could you also post images of the figures, so we can get a better idea of what the messed-up one looks like?

[BG]

The messed-up image looks like this to me:

Interestingly, if I do Edit->Copy Figure, the correct version of the image briefly flashes up in the figure window; then is replaced again by the corrupted image. If I then paste the copied image from the clipboard into another program, the pasted image looks fine.

I am running 64-bit Matlab on Windows 7 (R2014a), in case that matters.

[BG]

Additionally, I can mess up figure 4 by adding the following lines to the previous code:

hold on;
bar(b(subrange+400),n(subrange+400),'g');

which makes figure 4 look like this:

[the cyclist]

The difference might also be the renderer. What do you get from

get(gcf,'Renderer')

when the focus is on this figure? (Mine is 'OpenGL'.) I am not an expert in this regard, but other folks on this forum know a lot about rendering.

[dpb]

As always on such funky things, you can try changing the 'renderer' option to see if it matters and check for updated video drivers...

Probably worth submitting to official TMW support as well at mathworks.com

[BG]

Ok, I added a call to get(gcf,'Renderer') after each figure was drawn. The result is that figures 1 and 2 were 'OpenGL' (figure 1 was ok, figure 2 was corrupt); figures 3 and 4 were 'painters' (not corrupt), and the modified (corrupted) figure 4 was 'OpenGL'.

So all the corrupted ones were using 'OpenGL', but so was figure 1, which was not corrupted...

[dpb]

Did you try resetting it to something other than 'OpenGL' on the corrupt ones to see if that had any bearing? Seems strange that it's different by default...

[BG]

Yep, if I change the renderer to 'painters' the corrupt figures are fixed.

I just updated my graphics drivers and it made no difference to the 'OpenGL' rendered figures, so perhaps it is still a Matlab bug? I'll file a bug report and let the maintainers have a look.

Answer 1

[BG]

I've been informed by MathWorks support that this is a hardware OpenGL issue. Updating the graphics driver may fix it, or running the command

opengl software

to switch to software rendering.

Updating the graphics drivers did not make a difference for me, but switching to software OpenGL rendering did.