New Colormaps about forcolormap HOT 15 OPEN

These 4 Matplotlib colormaps are for example clearly in public domain / CC0 license:
https://github.com/BIDS/colormap/blob/master/colormaps.py

I think we must be sure for all included colormap.

from forcolormap.

Sorry, I didn't consider this. I will revert the last changes and, if necessary, remove this issue as well. We can start a new discussion.

from forcolormap.

Note also that the file scientific_colour_maps.f90 was generated automatically by the program scripts/generate_scmap.f90 from the text files available in the https://www.fabiocrameri.ch/colourmaps/ collection. It could be regenerated if the collection is expanded. Or if I succeed importing some missing colormaps not available in .lut format.

So other collections of colormaps should be defined in other module files. We could have a module for each collection plus one module miscellaneous for example.

from forcolormap.

These 4 Matplotlib colormaps are for example clearly in public domain / CC0 license: https://github.com/BIDS/colormap/blob/master/colormaps.py

I think we must be sure for all included colormap.

I can work on this on Sunday. Should I create a matplotlib_colormaps for that?

from forcolormap.

Before submitting my pull request, I made the following changes:

You can view the changes at this link: main...gha3mi:forcolormap:main.

1. Addition of Matplotlib Colormaps: I have added four new Matplotlib colormaps.

2. Redundant Code Removal: I removed redundant lines of code from the forcolormap module. Specifically, I removed the following lines as the module forcolormap is private by default:

! Other subroutines defined in this module:
! Elaborated colormaps are defined in their own subroutines:
private :: cubehelix_colormap
! Auxiliary functions used by the test method:
private :: write_ppm_test, write_ppm_colorbar

3. Changes in scientific_colour_maps Module: I made the scientific_colour_maps module private to avoid duplicate definitions of colormap_name_length across multiple modules. Consequently, I changed all colormaps in scientific_colour_maps to public. Alternatively, another solution could be defining a constant module to handle shared constants like pi, wp, colormap_name_length, etc.

from forcolormap.

I have found the bug in the viridis colormap:

            96,     202,     96,&
            99,     203,     95,&
            01,     203,     94,&
            03,     204,     92,&
            05,     205,     91,&
 ...
            94,     223,     35,&
            97,     224,     33,&
            00,     224,     32,&
            02,     225,     31,&
            05,     225,     29,&

The first digit "1" or "2" of the red value is absent.
I am going to correct that and commit it.

from forcolormap.

@gha3mi I have fixed it thanks to the regex ^[ ]{12}(\d\d,) in my text editor. It is committed.

from forcolormap.

Thanks, @vmagnin! This happened because of code formatting.

from forcolormap.

Hi Ali @gha3mi
be careful with the colormaps licenses. I think Matlab colormaps are copyrighted (I think I read things about it in StackOverflow while developing my project, I will search again the link...). And ForColormap is under MIT license. That is why I added the "Scientific Colour Maps" collection which is also under MIT license and the Cubehelix colormap which is in public domain.

from forcolormap.

But these Matlab palettes are copyrighted:
https://fr.mathworks.com/matlabcentral/fileexchange/28943-color-palette-tables-cpt-for-matlab
I have no access to the files, but they say "please see the header of each file for copyright information".

from forcolormap.

How about these colormaps?
https://github.com/holoviz/colorcet/blob/main/assets/colorcet.m
https://github.com/planetarymike/IDL-Colorbars
https://github.com/hhuangwx/cmaps
https://github.com/1313e/CMasher

from forcolormap.

I can work on this on Sunday. Should I create a matplotlib_colormaps for that?

Thanks for contributing! Yes, matplotlib_colormaps sounds good. It will mean something for users. I have encountered these four maps on many sites about colormaps.

Just follow the model of scientific_colour_maps.f90 and in the colormap_class.f90 add the list in colormaps_list and the corresponding cases in the set method and it should work.

from forcolormap.

How about these colormaps?
https://github.com/holoviz/colorcet/blob/main/assets/colorcet.m
https://github.com/planetarymike/IDL-Colorbars
https://github.com/hhuangwx/cmaps
https://github.com/1313e/CMasher

The second and third ones are under GPL license, not compatible with our MIT license.

The first one is under CC-BY 4.0, so I think it is possible to use it. Although we should verify further the compatibility.

The fourth is under BSD 3-clause license, which says for example "Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission".

I think that for the time being we should just import colormaps under MIT license or in public domain. In those cases, things are clear...

We should also select colormaps considering their quality, and/or their complementarity to the colormaps already included. We probably don't need several too similar colormaps, except maybe if they are classical colormaps in a famous software (a user may be happy to find its preferred maps in ForColormap).

from forcolormap.

Thanks, that looks good!

Alternatively, another solution could be defining a constant module to handle shared constants like pi, wp, colormap_name_length, etc.

Probably that will be the way to go as we add more modules...

from forcolormap.

• Black Body colormap (CC0 license / public domain) by Kenneth Moreland: "Color Map Advice for Scientific Visualization".

from forcolormap.