Keep the reference colours consistent between runs and/or have some control over reference colour.

[aineniamh]

Potentially by indexing reference colour from the sample sheet rather than order of appearance in csv or making it customisable like the sample colours.

[jameshadfield]

making it customisable like the sample colours

It is (or was). Let me look into this...

[rambaut]

We had a talk about this and think the solution is to have a references_config.json or some similar name which optionally contains a list of reference names (possibly colours and other labels). If this list exists then those references are always shown in the heatmap and are given the same colours.

[jameshadfield]

You should be able to change sample / ref colours in the UI. But that doesn't really address this issue. (I plan to work on this today.)

Our current implementation (by design) means that RAMPART doesn't know about the references FASTA -- I guess the path is saved in the config object, but it's intended as simply a parameter passed to the annotation script. As "new" references appear in the annotation results, rampart updates its display (and currently generates a new colour). Not sure what's the best design here, as I do think that consistency between runs is desirable.

[rambaut]

Yes. That is what I meant. We should have an optional config in the protocol folder which allows you to pre-specify the set of reference names (perhaps a mapping to a higher taxonomic order - i.e. a genotype), an ordering and a colour (optioning). If this is present then all of these references are present in heatmap (even if zero reads). I would prefer to avoid rampart reading and parsing fasta files.

[rambaut]

Another option would be to hash the reference name rampart sees it and take some bits of the hash to index the colour?

[rambaut]

I also think we don't need colour editing in GUI for references.