Specify read colour by lookup table

[davidlougheed]

Right now, I see that alignments can colour reads by a specific tag in the alignment file. If I do not wish to modify the original alignment file, it would be nice to provide some kind of lookup table (e.g. read names -> colour) to avoid on-the-fly BAM rewriting. Is this something that exists in some form? If not and it's a worthwhile request, I can look into implementing it in some capacity.

My use case here is to be able to highlight reads by some (arbitrary, from the browser's perspective) 'importance' colour scale.

[jrobinso]

You can color by arbitary tag, but the colors themselves are chosen for you. This would be easy to extend, search for "colorByTag" and "tagColors" in js/bam/BamTrack.js, and the function getAlignmentColor(alignment). The idea would be to supply the tagColors table in the config.

This would work for tags, but not read name. There are potentially as many read names as there are alignments, so this would probably not be a common use case, but it could be supported in a similar way.

[davidlougheed]

thanks for the pointers, it looks doable! in my case, the 'as many read names as alignments' is the idea, since I can then use a scalar "colour bar"-type colour scale to display an additional scalar dimension on the aligned reads.

an alternative, more flexible interface might be instead a way to provide a function with a signature like alignment => "rgb(...)" to an alignment track which could handle myriad uncommon use cases – getAlignmentColor could then delegate to that if said option was chosen.

[jrobinso]

Most tracks will take a function for the "color" property, which takes the feature as an argument and returns a color. It looks like alignmentTrack doesn't but it should, for consistency. So at line 1380 something like this should be inserted

if(typeof this.parent.color === 'function') {
    color = this.parent.color(alignment)
}

Yes this is very flexible, the downside is you cannot extract json to save session state when functions are used.

I'm undecided if the color function should be determinative, or interpreted as a function for the default color if no options are chosen (such as "strand"). I think it should probably be the default color as that is how a static value for "color" is interpreted.

If it is to set the color irrespective of other options it should return after the function call, however the color-by menu options then become inoperative and a source for confusion.

[jrobinso]

PR is merged, thanks for that. So the "color" property of the alignment track can now be a function.