Map files are currently (up to) 256 lines of r/g/b values intended for loading into a hardware color lookup table. However, lots of maps get generated and because they all have to be in separate files, this leads to a profusion of color map files.
It would be better if they could be organized into named entries in a catalog with a single file per catalog, like we have for parameters, formulas, IFS definitions and L-system definitions.
[ ] Upgrade existing .map files to recognize an extended format that acts as a catalog of colormaps.
[ ] Adjust colormap file selection screens to pick maps from a catalog.
[ ] Create a simulated catalog for all the loose colormaps with the colormap name just being the item name and the directory shown as [<dir>], e.g. the directory name in square brackets.
[ ] Extend command-line parameters to allow you to specify map items within a map catalog file
[ ] Extend parameter files to allow map items to be specified with map:? You can already do colors= but that only stores the low 6 bits of the color channel (see #47)
Map files are currently (up to) 256 lines of r/g/b values intended for loading into a hardware color lookup table. However, lots of maps get generated and because they all have to be in separate files, this leads to a profusion of color map files.
It would be better if they could be organized into named entries in a catalog with a single file per catalog, like we have for parameters, formulas, IFS definitions and L-system definitions.
.mapfiles to recognize an extended format that acts as a catalog of colormaps.[<dir>], e.g. the directory name in square brackets.map:? You can already docolors=but that only stores the low 6 bits of the color channel (see #47)