Case sensitive feature fails

version: MATLAB R2018a

surf(peaks)
>> colormap BlueDarkOrange18
Error using feval
Cannot find an exact (case-sensitive) match for 'bluedarkorange18'
The closest match is: BlueDarkOrange18 in /usr/local/MATLAB/R2018a/toolbox/matlab/ncl_rgb/BlueDarkOrange18.m
Error in colormap (line 91)
        arg = feval(arg);

My question is that, what I typed is 'BlueDarkOrange18', the error hints translated it into 'bluedarkorange18', this operation doesn't make sense.

[Joel Handy]

You can actually pop open the colormap function and take a look. The color map you input is indeed converted to all lower case, presumably for convenience since all of the built in, predefined maps are lower case.

Where did this BlueDarkOrange18 colormap come from? Did you make it or is it from an external source? I'm wondering if it comes from something written for an older version of matlab that was less case sensative.

You have two options as a workaround, You can change the BlueDarkOrange18 function to be all lower case, or you could create a custom colormap function.

[fuchang wang]

Thanks for replying so quick.

Indeed, I checked MATLAB/R2018a/toolbox/matlab/graph3d/colormap.m,

53 arg = lower(arg1);

this line switches all chars into lower case. I comment it out. It works now. So it would be great to update colormap.m in new version.

About BlueDarkOrange18, it is one of 269 colormaps of NCAR Command Language (NCL). I wrote a function /toolbox/matlab/ncl_rgb/BlueDarkOrange18.m imitating toolbox/matlab/graph3d/spring.m, and export MATLABPATH=/usr/local/MATLAB/R2018a/toolbox/matlab/ncl_rgb

[Guillaume]

"I checked MATLAB/R2018a/toolbox/matlab/graph3d/colormap.m [...] I comment it out"

"I wrote a function /toolbox/matlab/[...]"

Neither of these are a good idea. You should leave files in matlabroot alone.

In particular, it's totally pointless to modify colormap. Only you will be able to use your toolbox properly, the users of your toolbox won't (unless they also modify their matlab installation, I assume many will refuse).

The simplest workaround is to rename your colormap file to lower case. And possibly submit a bug report to matlab complaining about the behaviour of colormap.

[Joel Handy]

"In particular, it's totally pointless to modify colormap. Only you will be able to use your toolbox properly, the users of your toolbox won't (unless they also modify their matlab installation, I assume many will refuse)"

I wouldn't say its pointless, but it is a bad idea for the reasons cited as well as the fact that it may prevent you from using other people's toolboxes properly.

Changing "BlueDarkOrange18" to "bluedarkorange18" is indeed the best solution if that's viable. If there are factors that make changing the name difficult, a better solution to modifying files in matlabroot would be to make a new function "myColormap" which has your desired functionality. You can then use that function in your application, distribute it as needed, and not break a matlab installation.

[Steven Lord]

There is another alternative than changing the case of the function that defines your new colormap, and that is to change how you call colormap. The colormap function can accept the name of a colormap or an M-by-3 matrix that defines the colormap. Instead of calling colormap like this:

colormap BlueDarkOrange18

call it like this:

colormap(BlueDarkOrange18)

To support this, the BlueDarkOrange function should handle being called with either 0 or 1 inputs. With 0 inputs, it should return a matrix with a number of rows equal to the number of rows in the current figure's Colormap or the number of rows in the default colormap if there is no figure open. See the block of code at the start of the parula function for an example of how to obtain this information. With 1 input, if that input is a nonnegative scalar integer value it should return a colormap with that many rows.

[fuchang wang]

For some diagnosis packages that use multiple sofwares like matlab and NCL,

they set the enviromental variable in main shell script :

export COLORMAP=BlueDarkOrange

and get this variable in both matlab scripts and NCL scripts like:

color = getenv('COLORMAP')

thus the consistency of colormap names is important here. that's the reason I prefer to keep BlueDarkOrange.

Joel Handy's myColormap.m is a perfect solution, in this way people who use my package don't have to change their own colormap.m. appreciate it. Also thanks to other comments, reminding me that it's not good to change matlab's own codes.