2D Contour colormap too dark.

Hi.

I have a problem. I made a colormap matrix "b" by picking out the rgb colour codes using Photoshop.

However, the Matlab GUI contour appears to be a lot darker than the initial excel contour it is based upon.

I have managed to change the brightness as follows (.x, .y, .z etc. being the rgb codes)

b = [.x .y .z; .w .v .u;...];
colormap(b);
brighten(0.6) %anything lower is far too dark, 
              %anything higher is extremely bright

The brighten function only changes the brightness of the contour, but even with the ideal brightness it has this greyed out touch to it.

Here is a comparison:

- The colours as they should be: http://i1329.photobucket.com/albums/w552/mrcjkb89/excelColours_zps71ba107b.jpg

- The Matlab colours: http://i1329.photobucket.com/albums/w552/mrcjkb89/matlabColours_zpsd1ddbf0c.jpg

Any tips would be much appreciated!

Marc

[Sven]

Marc, can you paste in the actual (full) contents of b?

The best type of question will always have some code we can simply copy/paste/run to make a plot that shows your problem.

And are you just making a simple contour plot (like in your other question) or something 3d? If you're actually building, say, a 3d plot with lighting then colour brightness always depends on the lighting conditions in the scene.

[Image Analyst]

What does contour() have to do with anything? This looks like just a colormap only question, and nothing to do with the contour function. Or did you mean contour in that if you have just a few colors, the image will have uniform color "contours" or regions and sharp boundaries (edges) between those uniform regions? Also, why is there a black line in the MATLAB image but not in the Excel image? Add the colorbar() function to your code - that may help explain things.

[Sven]

@IA: The type of plot (well, maybe "type" isn't the right word here...) can have an influence in certain circumstances. For example:

figure, peaks, colorbar

will have the same colormap, same colorbar, but will still "look" very different to the user than:

figure, peaks, colorbar, camlight

You and I are familiar enough with MATLAB to know why this is the case (renderer, lighting). Marc's example image looked like a closely zoomed in version of some plot but it was too zoomed in to see if lighting was indeed involved. Also, the dulling effect from the 3d rendering looks like it "might" be at play here. The description (brightening does not much until the surface just about turns white) also points that way.

I only ask about contour() because I'd just helped Marc out with a question here. If he's getting the colour difference with the same example as there (which had no lighting/rendering), then we could at least rule out that option.

Anyway, my bet's on either this rendering issue, or the RGB values of b not actually being scaled between 0 and 1.

Well, Marc, you've got us all interested now :)

[Marc Jakobi]

Hi.

Thanks for the replies... And sorry for getting back to it so late. I didn't get a notification for some reason...

- Sven: Here are the contents of b:

b = [.091 .153 0;...
    .114 .159 0;...
    .137 .166 .001;...
    .160 .172 .001;...
    .184 .178 .001;...
    .207 .184 .001;...
    .230 .191 .002;...
    .253 .197 .002;...
    .253 .181 .003;...
    .253 .166 .005;...
    .253 .150 .006;...
    .254 .134 .007;...
    .254 .118 .008;...
    .254 .103 .010;...
    .254 .087 .011];
caxis([20 50]);
cmp = colormap(b);
brighten(0.6);
cbr = colorbar;
set(cbr,'YTick',20:2:50,'FontSize',13)

It is the same 2D contour plot as in my other question.

- Image Analyst: I created the colormap for a 2D contour. The figure I am coding started off as an unfinished macro-enabled excel spreadsheet and I have been transferring it to matlab. The black line in the matlab version is an added elevation of a specific isoline that was left out in the excel one.

Here is the code for the contour:

contour(handles.SKosten,x1,x1,p_sk,'LevelStep',2,'Fill','on')
hold on
contour(handles.SKosten,x1,x1,p_sk, [p_nb p_nb],... 'Color','k','LineWidth',1.45)

SKosten is the axes tag in my figure, x1 the x & y axis (with the same values), p_sk the isolines (costs). p_nb is a specific cost (the black line in the second image).

Again, thanks so much for the support!

[Marc Jakobi]

PS: here are two full-scaled images of the contour:

- with brighten(0.6):

http://i1329.photobucket.com/albums/w552/mrcjkb89/Capture_zpsf0e87512.jpg

- without brighten:

http://i1329.photobucket.com/albums/w552/mrcjkb89/Capture2_zps847b96a7.jpg

[Rachel Baker]

Hi,

I had a very similar problem, and ended up solving it with one line:

caxis([MIN MAX])

You can set your colormap over a specific range so that the colors that are "too" dark are associated with values outside of the range you are plotting. Hope this helps someone else!

-Rachel

Answer 1

[Sven]

Hi Marc,

Got it. The RGB values you're copying in are 8-bit RGB colours of integers ranging from 0 to 255. You're right that MATLAB defines its RGB colours as double values from 0 to 1, but in order to get a true conversion you should just divide the integers by 255, rather than copy them in as 0.xxx. Using 0.xxx, the "brightest" number you'll get is 0.255, which is still about one quarter as bright as the true brightest value of 1.

Try this:

b = [.091 .153 0;...
    .114 .159 0;...
    .137 .166 .001;...
    .160 .172 .001;...
    .184 .178 .001;...
    .207 .184 .001;...
    .230 .191 .002;...
    .253 .197 .002;...
    .253 .181 .003;...
    .253 .166 .005;...
    .253 .150 .006;...
    .254 .134 .007;...
    .254 .118 .008;...
    .254 .103 .010;...
    .254 .087 .011];

b2 = b*1000; % Get them back to whole numbers from 0 to 255
b2 = b2/255; % Transform them from [0 255] to [0 1]

figure, peaks; colormap(b)
figure, peaks; colormap(b2)

Or, more directly you can simply copy in your values without the leading decimal point (so that they will be whole integers up to 255), then divide them by 255.

Did that sort things out for you?

[Marc Jakobi]

Wow, thanks! That did it. I wondered why Matlab used decimals, but just dividing the true values never occurred to me.