Any time that cubehelix is used, a colorbar is shown. So I think it's clear to the user what is going on.
As to why we don't always use it, the fact is that when people load a grayscale (natural) image, they expect it to appear in grayscale. This is true of most of our examples, e.g., coins, camera. plt.imshow shows camera in jet by default, which is appalling *and* surprising to the user. Cubehelix would be merely surprising. =P
On the other hand, it's generally unlikely that an image that shows no perceptually distinguishable shades of grey is actually a natural image. In those cases, I think it's appropriate to show cubehelix. (Or another suitable colormap. But I didn't want to wait until mpl made their fancy new one.)
The key here is that imshow is a command made interactively to *explore one's data*. One wants to know at a glance what is going on. It's infuriating to load up an image and have it appear as a black rectangle because its range in 16-bit grayscale is really low. Then I have to go type a much longer command to get it to show the way I want. So I think in these cases a little magic is justified that will get people the result they want in one short command that will work as expected most of the time.
On Sun, Feb 22, 2015 at 7:32 PM, Stefan van der Walt <stefanv@berkeley.edu> wrote:
On 2015-02-21 15:53:47, Juan Nunez-Iglesias <jni.soma@gmail.com>
wrote:
> In the new MPL imshow plugin (which I recently wrote), we switch
> from grayscale to cubehelix when the dynamic range is too low to
> be displayed on a common monitor (1/255):
Importantly, it should be clear and intuitive to users when the
switch happens. Why do we not always use cubehelix? Apart from
that it is a rather ugly colormap.
Stéfan
--
You received this message because you are subscribed to the Google Groups "scikit-image" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.