{"id":3634,"date":"2017-07-25T10:52:29","date_gmt":"2017-07-25T09:52:29","guid":{"rendered":"http:\/\/www.blopig.com\/blog\/?p=3634"},"modified":"2017-07-25T16:33:22","modified_gmt":"2017-07-25T15:33:22","slug":"in-matlab-its-colormaps-all-the-way-down","status":"publish","type":"post","link":"https:\/\/www.blopig.com\/blog\/2017\/07\/in-matlab-its-colormaps-all-the-way-down\/","title":{"rendered":"In MATLAB, it’s colormaps all the way down"},"content":{"rendered":"

My overriding emotion, working in R, has been incomprehension: incomprehension at the gallery of ugly gnomes that populate the namespace and worried puzzlement over the strange incantations required to get them to dance in a statistically harmonious way. But all that aside, I resolved, joining the group, to put aside my misgivings and give the gnomes another try.<\/p>\n

Soon, I found myself engaged in a reassessment of my life choices. I realized that life’s too short to spend it tickling gnomes – especially when only one of them knows how to do linear regression, but he won’t tell you your p<\/em> value unless you give him the right kinds of treats. I fired up MATLAB and I haven\u2019t looked back.<\/p>\n

However, there was issue of continued perplexity, and I\u2019m not referring to why MATLAB insists on shouting itself at you. I need to make a lot of 2-D plots of protein distance matrices. The trouble is that I like to highlight parts of them, and that’s not straightforward in MATLAB. Let\u2019s have a look at an example:<\/p>\n

>> dists=dlmread('1hel.distances');\r\n>> colormap gray;\r\n>> imagesc(dists>8);\r\n>> axis square;<\/pre>\n
\"Contact<\/a><\/p>\n
Now, let\u2019s load up a set of residues and try to overlay them on top of the first image:<\/p>\n
>> resn=dlmread('1hel.resn');\r\n>> mask = zeros(size(dists));\r\n>> mask(resn,resn)=1;\r\n>> hold on\r\n>> imagesc(1-mask, 'AlphaData',mask*.5);\r\n<\/pre>\n
\"\"<\/a><\/p>\n
So far, so easy. To review the main points:<\/p>\n
mask<\/code> is a matrix which has a one at all the pixels that we want to highlight. But we use imagesc(1-mask)<\/code> because the gray colormap displays black at 0 and white at 1. If we did imagesc(mask)<\/code>, we would end up with grey everywhere and white only where we hoped to highlight – the opposite effect from the one that we sought.<\/p>\n
AlphaData<\/code> is a property which sets the transparency of the image. We want the image to be fully transparent where mask<\/code> is 0 – so as not to fog out the underlying image – and partially transparent where mask<\/code> is 1. 0.5*mask<\/code> is a matrix which is 0.5 everywhere that mask<\/code> is 1 and 0 everywhere else.  If we set 0.5*mask<\/code> as the AlphaData<\/code> property, then the colour we add will be at half transparency and the white areas will be fully transparent.<\/p>\n
But this isn\u2019t a very pleasant image. We want to be able to highlight the regions in some colour other than grey. Let\u2019s try.<\/p>\n
>> close all\r\n>> imagesc(dists>8)\r\n>> colormap gray\r\n>> axis square\r\n>> imagesc(1-mask, 'AlphaData',mask*.3,'ColorMap','jet');\r\nError using image\r\nThere is no ColorMap property on the Image class.\r\n\r\nError in imagesc (line 39)\r\nhh = image(varargin{:},'CDataMapping','scaled');\r\n<\/pre>\n
No luck! What’s more, setting the colormap between calls to image()<\/code> and imagesc()<\/code> also doesn\u2019t work. Here\u2019s the problem: the colormap<\/code> is a property of the figure<\/em>, not the data. (More precisely, it is not a property of the MATLAB axes.) When you change the colormap<\/code>, you change the colors of every<\/em> datapoint in the image.<\/p>\n
The fix<\/strong><\/h1>\n
MATLAB\u2019s colormap<\/code> mechanism is just simple enough to be confusing. MATLAB stores colours as 1×3 vectors, where each element in the vector is the proportion of red, green, or blue, respectively. [1 1 1] is white, [0 0 0] is black, and [1 0 0] is a frightfully iridescent red. A colormap is just a list of colors \u2013 64 will normally do \u2013 which change smoothly from from one colour to another. To have a look at the built-in MATLAB colormaps, see here<\/a>.<\/p>\n
image<\/code> rounds every value in the matrix to the nearest whole number (call that number i<\/code>)  and plots that pixel with the color given by colormap(i,:)<\/code>. Zero or below gets the first entry in the colormap<\/code> and any index higher than the maximum is displayed with the last color in the colormap<\/code>. So: if we construct a new colormap<\/code> by concatenating two colormaps \u2013 the first running from rows 1 to 64 and the second running from 65 to 128 – if we scale our data so that the minimum is 65 and the maximum is 128, the data will never use the first set of colors. And, likewise, if we scale so that the lowest value is 1 and the highest is 64, we will use the first colormap. This seems like the sort of thing that we could manage automatically – and should, in fact. So I set myself to replace image<\/code> and imagesc<\/code> so that they would accept a ColorMap<\/code> parameter.<\/p>\n
How would it work?<\/p>\n
>> colormap bone\r\n>> imagesc(dists>8)\r\n>> hold on\r\n>> imagesc(mask,'ColorMap',[0.5 0 0.5],'AlphaData',0.5*(mask>0))\r\n>> axis square<\/pre>\n
\"\"<\/a><\/p>\n
Beautiful!<\/p>\n
Implementation notes<\/h1>\n