search

TomLav / ncmaps

ncmaps brings scientific colormaps to ncview
GNU General Public License v3.0
52 stars 3 forks source link

Control what colormaps ncview will show (also the native ones) #5

Closed TomLav closed 3 years ago

TomLav commented 3 years ago

Once all the colormaps from ncmaps are installed, is there a way for the user to:

  1. disable (or make low priority) the "native" colormaps of ncview (also some of the ncmaps colormaps he/she dislikes);
  2. control the order in which the colormaps are browsed through by ncview.

Of course we want a solution that is recorded for next time we open ncview, hence the idea to play with .ncviewrc...

@samhatfield

samhatfield commented 3 years ago

There is the option of turning off colourmaps one-by-one in Opts -> Enable, and you can also reorder colourmaps in the same menu. This seems to create the .ncviewrc file for you. Do you think we need more functionality on top of that?

TomLav commented 3 years ago

on my system (Ncview 2.1.8 David W. Pierce 8 March 2017, Ubuntu Bionic) ncview would not restart after the .ncviewrc was created.

Error message: Error, too many colormaps -- max is 200

(but we still have less than 200 colormaps).

It was late, I need to investigate more. Did you try disable colourmaps from ncview, closing and reopening ? Does it work?

samhatfield commented 3 years ago

Yeah I think this is a bug. I sometimes see this, sometimes not, but I don't know why yet.

Are you using ncview loaded from a module on your work computer or something? I was doing this originally, but loading that module was changing the value of $NCVIEWBASE to /usr/local something. I may have fixed this problem by ignoring that module and building my own ncview from scratch.

TomLav commented 3 years ago

I am using the ncview from the apt-get on Ubuntu Bionic:

<pc4897|~> =:D apt show ncview
Package: ncview
Version: 2.1.8+ds-1build1
Priority: optional
Section: universe/science
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Debian GIS Project <pkg-grass-devel@lists.alioth.debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 2 287 kB
Depends: libc6 (>= 2.14), libnetcdf13 (>= 4.0.1), libpng16-16 (>= 1.6.2-1), libudunits2-0 (>= 2.2.14), libx11-6, libxaw7, libxt6
Homepage: http://meteora.ucsd.edu/~pierce/ncview_home_page.html
Download-Size: 433 kB
APT-Manual-Installed: yes
APT-Sources: http://no.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
Description: X11 visual browser for NetCDF format files
 You would use ncview to get a quick and easy, push-button look at
 your NetCDF files. You can view simple movies of the data, view along various
 dimensions, take a look at the actual data values, change color maps, invert
 the data and other simple visual operations.

I think I managed to circumvent the issue by deleting the lines in the .vimrc file that had the legacy colormaps (and re-numbering the colormaps). Hence the idea we could write our own .ncviewrc file.

(caveat: it was late, I might have mixed things up in my short investigations)

samhatfield commented 3 years ago

Yes I see. Hmm, I guess we should try to figure out why this problem occurs and then we can proceed from there.

TomLav commented 3 years ago

I gave it a try in this branch: https://github.com/TomLav/ncmaps/tree/vimrc

It works for me, but I had to de-activate cmasher for the time being (to avoid the Error, too many colormaps -- max is 200 error).

Can you give it a try ? Also try to stress-test by changing the order / disable, etc... in Opt, closing, and re-opening ncview.

samhatfield commented 3 years ago

Nice work! This is in the right direction. However I've been looking at the ncview code and I have a couple of comments:

As far as I know we cannot turn off the built-in 20 colormaps permanently as they're in the source code. That gives us 80 colormap slots to play with. Also, there seems to be another bug in the ncview code in that the line 0 "NCVIEW_STATE_FILE_VERSION" INT 1 at the top of .ncviewrc is counted as a colormap. So we actually have 79 colormap slots. If you want to check this yourself, make it so that there are less-than-or-equal-to 79 .ncmap files in $NCVIEWBASE. You should find that ncview always opens successfully without the 200 max error (assuming that you've deleted .ncviewrc to allow ncview to create a new one).

My suggestion is that for now we "curate" 79 colormaps and only support them. Of course we can recommend bug fixes to the ncview developers but those changes will take years to filter through to our users.

TomLav commented 3 years ago

Thank you, Sam.

It is excellent that you can read the ncview code. I fetched it too, and tried to find my way, but I admit I failed.

So we must reduce the number of colormaps we support to ensure the users will not bump into the "max 200 colormaps" bug. We could remove cmasher (not known in my community). Matplotlib+cmocean+cmcrameri takes us to 62 colormaps. Since we have some spare, we could also bring some of the diverging and/or cyclic colormaps from matplotlib and/or crameri, as they are useful for some quick data visualization.

Then about the .ncviewrc feature. Adding it brings complexity to our code (and user documentation). I am not sure it is justified when users can create their own configuration with just a few clicks in ncview. But we should tell them how to do that.

The only advantage in shipping our own .ncviewrc file is that we nudge the users away from the legacy colormaps (they have to willingly enable them). Is it our role?

I think I'll continue in main now, remove the cmasher, add the diverging colormaps, while we give the .ncviewrc feature some more thoughts.

samhatfield commented 3 years ago

That sounds good! Yes as long as there are fewer than 80 .ncmap files in ncmaps then I think we'll be fine. But I also struggled to follow the ncview sourcecode 😓

We could always have a optional installation step, to copy our .ncviewrc file for those users that don't want to use the legacy colormaps?