Reversing color palettes

[olibclarke@…]

The following bug report has been submitted:
Platform:        Darwin-18.6.0-x86_64-i386-64bit
ChimeraX Version: 0.9 (2019-06-05)
Description
Minor feature request re palettes:

The Colorbrewer palettes are great, and I love that we can easily select how many colors to interpolate through by changing the name.

Would it be possible to add a similar modifier (e.g. "R") to the end to reverse the palette? This would be useful when using these palettes for rainbow coloring - e.g. I like the RdYlBu-5 palette for rainbow coloring protein molecules, but it is the wrong way around for the conventional N=Blue --> C=Red coloring.

(or maybe a "reverse" keyword for the rainbow or color sequential command would do the trick)

Cheers
Oli

Log:
> camera ortho

> cofr centerOfView

> alias crosshairs_on cofr centerofview showpivot 10,0.3

> alias crosshairs_off cofr centerofview showpivot false

UCSF ChimeraX version: 0.9 (2019-06-05)  
© 2016-2019 Regents of the University of California. All rights reserved.  
How to cite UCSF ChimeraX  

> help alias

> alias ^rainbow_ryb rainbow $1
"#2F7AB4","#ACD9E8","#FFFFC2","#FCAF68","#D62328"

> open
/Users/oliverclarke/Dropbox/last_frame_rsr_ligands_real_space_refined_ss_annotated.pdb

Chain information for
last_frame_rsr_ligands_real_space_refined_ss_annotated.pdb #1  
---  
Chain | Description  
A B G I | No description available  
C D E K | No description available  
F H J O | No description available  
  

Unknown command: rainbow_ryb  

Unknown command: rainbow_ryb chain  

> alias rainbow_ryb rainbow $1
"#2F7AB4","#ACD9E8","#FFFFC2","#FCAF68","#D62328"

> rainbow_ryb chain

Expected a keyword  

> rainbow_ryb chains

Expected a keyword  

> help rainbow

Expected one of 'chains', 'polymers', 'residues', or 'structures' or a keyword  

Expected a keyword  

> rainbow chains palette rdylbu-5

> rainbow palette rdylbu-5

> rainbow palette rdylbu-5

Fetching compressed palette BuYlRd-5 from
http://www.colourlovers.com/api/palettes?keywords=BuYlRd-5&format=json&numResults=100  
Could not find palette BuYlRd-5 at COLOURlovers.com using keyword search  

> rainbow palette rdylbu-5




OpenGL version: 4.1 ATI-2.9.26
OpenGL renderer: AMD Radeon Pro 580 OpenGL Engine
OpenGL vendor: ATI Technologies Inc.

[Conrad Huang]

Added in 086f8d83b.

The "rainbow" and "color sequential" commands now have a boolean keyword argument "reversed" that will reverse the palette, e.g., rainbow palette rdylbu-5 rev t. This should be in daily builds dated 2019-06-08 or later. Please let me know if that is what you wanted.

[olibclarke@…]

This is exactly what I wanted - thank you!

Oli

[Elaine Meng]

Hi Conrad,
Yay! I also wanted this. However, palettes are also used for coloring by attribute, map value, and distance (not just sequential aka rainbow), so I’m hoping it also works for those color subcommands as well … or that you could make it do so without too much trouble (pretty please?)

​http://rbvi.ucsf.edu/chimerax/docs/user/commands/color.html

Thanks,
Elaine

[Conrad Huang]

Maybe we should go with Oliver's first suggestion of making it a modifier for the colormap? I added the "reversed" code into "rainbow" and "color sequential", but if we have a modifier syntax for palettes (like mapname:R) then the code can be centralized in ColormapArg and all commands gets the benefit automatically. The only downside is that you would not be able to use the reversed default palette (where the user does not specify a palette at all). What do you think?

[Elaine Meng]

My 2 cents’ is that the centralization plan sounds much better than replicating code or having the option available only for some palette-using commands and not others.  Didn’t really understand why it wouldn’t work with default palette, but maybe you meant if the palette name was omitted from the command?  At least people could explicitly specify the default palette by name, since all of the default palettes of the various commands do have names, I believe.
Elaine

[Conrad Huang]

User omitting the palette name from the command is exactly what I meant by "not working with the default palette".

I don't think ":" appears in any standard palette name. so my proposal is for the palette modifier syntax is "palette:modifier", where "modifier" is a string of single character modifiers. Initially, "R" or "r" is the only supported modifier. Unrecognized modifiers generate an error. So the example above would become: rainbow palette rdylbu-5:r. Does that sound reasonable?

[Elaine Meng]

wait, why can’t it just be an option “reverse true” like you said before?

I have a documentation section “palette options” because in addition to “palette palette-spec” there is a “range” option that applies only to palettes. The commands that use palettes can use both of these options.
​http://rbvi.ucsf.edu/chimerax/docs/user/commands/color.html#palette-options

[Conrad Huang]

It may have been documented that way, but I don't think "range" is implemented for anything but color by attribute. For example, rainbow pal Spectral range full fails with "Expected a keyword".

Centralizing the code may not be possible, since each command has to register its own syntax. Currently, the standard commands that support the "palette" keyword are "color byattribute" (which includes "color bfactor" as an alias), "color sequential", and "measure convexity". "range" is a valid keyword for "color byattribute" and "measure convexity" but not for "color sequential". "reversed" is (will be) valid for "color sequential" and "rainbow" but not for the others. I will just make both keywords work for all those commands. Do you know of any other commands (presumably from other bundles) that support the "palette" keyword?

[Elaine Meng]

As the documentation says :-) the “range” option works for coloring by numerical stuff, not sequential coloring. Sequential always uses the whole range (all the residues in a chain for example).

[Elaine Meng]

To answer more fully, “range” works for palettes in the commands “mlp”and “measure convexity” and for several “color” subcommands (sample, electrostatic, gradient, radial, cylindrical, height).

[Conrad Huang]

Then I'm going say that adding a modifier to the palette specification is the way to go. It is way too messy to track down where all those commands are registered and fixing all of them to support a "reversed" keyword. Not to mention that the next command that supports "palette" probably won't support "reversed" automatically.

Since ":" is already used in palette syntax, do you have any suggestions on what other syntax might be acceptable?

[Elaine Meng]

Well, it’s just three if you lump the color subcommands together: color-by-value (color subcommands), mlp, and measure convexity. However, if you’re going to munge the palette specifier, maybe Tom Goddard needs to weigh in how to do it without stepping on his previously implemented multiple ways of specifying palettes.

[Conrad Huang]

No. The available color subcommands are:

• color (standard)
• color bfactor (standard)
• color byattribute (standard)
• color cylindrical
• color delete (standard)
• color electrostatic
• color gradient
• color height
• color list (standard)
• color modify (standard)
• color name (standard)
• color radial
• color sample
• color sequential (standard)
• color show (standard)
• color zone (standard)

So a substantial portion are not standard commands, i.e., code for them are in bundles other than std_commands. For completeness, "measure convexity" is a standard command, but "mlp" is not. If "reversed" is implemented as a keyword, each and every command registered with "palette" needs to be checked/updated, and every new command using "palette" (code that uses ColormapArg) will need to know to support the "reversed" keyword. (I'm ignoring the "range" keyword since it does not apply universally to all commands that support "palette".)

I agree that Tom should weigh in because code for adding modifiers for palette must be in the ColormapArg class. I'm willing to write the code if we all agree on a syntax for modifiers. In the mean time, should I back out the "reversed" arguments from the "rainbow" and "color sequential" commands?

[Elaine Meng]

I have no concept of how the code was arranged, so I definitely defer to you guys on the final approach.

As to backing anything out, I don’t feel strongly (can be overruled) but my mild leaning is to leave them in until we figure out syntax for the broader implementation. If we don’t want people to become too attached, it could be left out of the help documentation and would only show up in usage, I presume.

[Tom Goddard]

Using some modifier in the palette name seems ok to me. I don't know what the syntax should be. Since ":" and "," are already used to specify palettes like red:white:blue and 0,red:.5,white:1,blue Eric suggested prepending with a '-'. I guess that could be confused with a negative number "-1,red:0,white:1,blue". So I don't know what syntax to use.

[olibclarke@…]

Maybe %? Or maybe that’s already used for something too...

[Conrad Huang]

I'm blaming this on Eric :-)

How about a leading tilde (~)? I have the code ready to commit. Is this acceptable?

[olibclarke@…]

Leading tilde seems confusing to me given use elsewhere for negating an action (e.g. ~clip, ~disp). What about “+”? Conveys that you’re adding a modifier, and I don’t think it’s used for anything else?

Oli

[Conrad Huang]

+ will look strange if the leading value is negative: "+-0.5,red:...". 
How about ^?

Conrad

On 6/10/2019 11:16 AM, ChimeraX wrote:

[olibclarke@…]

Fair point - I have no objection to “^”

Oli 

[Conrad Huang]

Okay. Caret (^) it is (ignore the exclamation point you see in plain text; it's a wiki thing). Should be in tomorrow's build. The "reverse" keyword will be removed from rainbow and color sequential.

[Conrad Huang]

Implemented in c29223bd.