Smart display should use different colors for chains

[Tom Goddard]

Opening 4hhb (and other molecules with < 5) chains causes all the chains to be given the same color. When there are 5 or more chains (e.g. 2bbv) the smart display code colors each chain with a different color. I think using different colors for chains for models with less than 5 chains is a much more useful initial use of color. This of course depends on the intended use -- if a second model is open for comparison it can be useful to have each mode have a single color. But I think it is more common that a single model is open and not compared to a second model so we should optimize the most common case. If a second model is open we might change its smart display chain colors to be lighter variants of the first model colors.

[Eric Pettersen]

I guess I disagree. Users, especially casual users, tend to stick to the defaults. I've seen many dozens of images of Chimera-superimposed structures in publications that look good because each model has its own single color (almost always the default tan and light blue), which would have been confusing and ineffective if each model were per-chain colored. That was one of the main drivers to switching our initial depiction from white wireframe to something more esthetic -- terrible looking publications. And though per-chain coloring _might_ be the more common use case (and I'm not 100% convinced it is), I feel a big win for the somewhat less common use case outweighs the smaller win for the more common case.

What I would be in favor of is two things:

• A wide variety of presets to get to useful views quickly

• Good control over where the smart-display thresholds are, so you could easily crank down the per-chain coloring threshold to 1 chain if you always wanted per-chain coloring

Now, that's my opinion. I'm not adamant -- I could be persuaded. I've added Elaine to the CC on this ticket so she could possibly weigh in if desired.

[Elaine Meng]

Have to say I lean against changing it too, since in the few-chains cases it is common to be comparing multiple models. Even if the chains were some lighter shade in the subsequent models, then all the chains with a particular ID would be visually grouped, rather than the chains within a single model. I REALLY wouldn't to use this on single-chain models... then just about everything would be the "A" color (unless we went to "byseq" coloring as mentioned below).

It would also mess with easily identifying by eye which model is which. For SFLD I often compare 5-6 homologous structures and rely on their model colors vs. the Model Panel as a color key to remind me which one is which, since they look pretty similar otherwise. Usually they are monomeric but some are dimers or multimers, and active sites can be in the interfaces.

Also important is that when ribbons plus sticks of selected sidechains are shown, the hetatm coloring is needed for rapid comprehension of the residue types and chemical environment around ligands and ions. It's integral to viewing binding sites (or interfaces or active sites even without ligands) of a single model or multiple superimposed models, while the model-colored carbons make it easy to see which sidechains are from which model. If we combined coloring bychain with hetatm coloring, then even in a single model (if >1 chain) there would be two coloring schemes going on and more visual complexity.

In Chimera it was more of a problem that you wouldn't realize there were multiple chains in a model, but in ChimeraX we have helpful logging of entity information when the structure is opened.

I'm OK with the current coloring, but if you feel strongly about making chains different colors, here's one idea for the 2-4 chains case:
In combination with hetatm coloring, use model color for first chain but variations of that color for other chains, or something similar except with same entities colored the same. So, for example the ribbons and carbons of #1 4hhb A,C would be tan and B,D would be a different shade of tan (and probably any surfaces should match instead of coming up in the bychain colors). Downside is that "color bymodel" would no longer get you back to the starting model colors. We'd have to have some kind of fancier preset to go back to the initial display.

...and for the >4 chains case:
It might be more useful to color larger heterocomplexes byseq (byentity) instead of bychain too. Reasoning is that it shows which chains are the same, and different models would then get different colors, albeit multiple per model but at least they wouldn't be identical to each other. However, drawbacks could be:
(1) requires some calculation
(2) requires separating homo- and heterocomplexes, makes initial display rules more complicated and harder to explain
(3) not good for comparing multiple structures of same entity (how often is that done with models of >4 chains?)
(4) ligands/small mols not included in byseq coloring, but could propagate color from biopolymer to small mols with same chain ID (doesn't cover models with small mols only but I don't see such models having >4 chains anyway)
(5) byseq colors can be dark and ugly (however, many of the chain colors are dark and ugly, and model colors for higher numbers of models may get that way too because one runs out of distinguishable pastels)

[goddard@…]

The key issue here is that there are two main use cases, one where only a single atomic structure is opened, and another when 2 or more atomic structures are open.  Our current coloring is poor for working with single single structures.  I think that is the most common case.  Of course it depends on which users you are talking about.  I am thinking about the EM users who typically have many chains, and often are working on a single structure.  Eric and Elaine’s previous arguments rightly point out that if you use coloring that favors single atomic structure users, then you make it worse for multi-structure users.  That is true an unavoidable.  Given that both single and multi-model cases are common and we don’t know when a user opens the first structure what they intend to do we have to make a guess, then make it as easy as possible to change modes.  Basically if I started with different colors for chains I’d load a second structure and want a single button click to make structures single colored for better multi-structure comparison.  Alternatively if the first model starts single color I could have a button that says make chains multiple colors since I’m only going to work with a single structure right now.  I consider this second alternative somewhat dumb — I’ve opened one structure and now the code colors as if I’m going to open more structures and I have to tell it I’m not going to open more structures.  Of course if you are a user whose main application is comparing structures then you want the program to color for multi-structure comparison, and I sense the tools Elaine and Eric use are mostly that case, where as the Chimera uses I focus on for the EM people is mostly single structures with many chains.

One idea to try to get the best results for everyone would be that the first time you run ChimeraX it gives you a panel with some options that depend on how that user intends to use the program, for example, a choice of “Different colors for molecule chains, best for single molecule analysis” or “Single molecule color, best for multi-molecule comparison”.  These settings would also be available in later ChimeraX sessions through a preferences panel, but would appear the one time when you first install and run ChimeraX.

[Elaine Meng]

I don’t agree that the model colors are worse than chain colors when you have a single model open.  I think they may be better than chain colors because of less visual complexity when combined with the hetatm coloring (which I strongly feel should be part of the initial display).
Elaine

[goddard@…]

I think this reflects the types of structures you primarily look at.  In my use which is oriented to EM systems the het-atoms are still important but tiny compared to the overall structure, so their coloring is not a dominant feature.  You are advocating for specific Chimera users (those comparing comparing small proteins) and I am advocating for a different set of users, EM researchers.  Chimera has been poorly suited for EM users, somewhat understandable since the EM capabilities were added years after Chimera was released.  But they are an important group of users, the ones I mostly interact with, so I want ChimeraX to work better for them.

[Elaine Meng]

Maybe we really need “New Molecules” preferences instead of trying to put all our hopes and dreams into initial smart display.  It would be nice if these preferences allowed some layering on top of our default smart display, as opposed to the all-or-none approach we have in Chimera1.  Currently we just have that keyword option in “open” that turns it off entirely.

[Eric Pettersen]

Just a couple of points. For "...EM users who typically have many chains...", well, structures with 5 or more chains _are_ colored on a per-chain basis. I tried to estimate what size of structures would typically be used in structure comparison vs. typically analyzed on their own and my best guesstimate 4 or less chains for comparisons and 5 or more for standalone analysis. It was a guess but seemed pretty reasonable.

Coloring by entity is unlikely to be added to smart display because it's slow to compute and we want initial structure display to be snappy. It would make for a good preset though.

--Eric