dasmoth
commented
10 years ago Thanks very much for this contribution.
A few minor things:
- There seems to be a typo of "hotPink" vs "hotpink" in the colour names
- Is there any particular reason for changing the default colour for "G"s from black to orange? Black seems to be the common choice in chromatogram-viewing software. In the longer term, I agree that these ought to be editable!
- I don't really understand why the "colors" object needs to be constructed and passed to the SequenceGlyph constructor -- this seems like unnecessary overhead. You already know the orientation of the read at the time when the SequenceGlyph is constructed, so you can choose the plus or minus colour as appropriate and pass that in directly. Passing the baseColors object to the SequenceGlyph is fine (since there hopefully won't be too many of those objects in the process!) but I'd just add an extra argument to the SequenceGlyph constructor?
Are you happy to make those changes, or shall I?
Slightly longer-term things I think we should be considering (but let's not hold up this PR, which is clearly useful as is):
- It would be nice if it was possible to colour other types of feature by strand using the same UI.
-
Interaction with the rest of the stylesheet system: it's actually possible to make style rules which filter by orientation, e.g:
<STYLESHEET> <CATEGORY id='default'> <TYPE id='foo' orientation='+'> <BOX> <BGCOLOR>red</BGCOLOR> </BOX> </TYPE> <TYPE id='foo' orientation='-'> <BOX> <BGCOLOR>blue</BGCOLOR> </BOX> </TYPE> </CATEGORY> </STYLESHEET>
I've just realized that this Dalliance-specific stylesheet extension never made it into the docs (my bad, will fix shortly). Doing things this way is more general, at the expense of making it a little harder to hook everything up in the track editor. Just something to consider in the future.
mdrasmus
ymen
Addresses: https://github.com/dasmoth/dalliance/issues/67
Sorry for taking such a long time for the PR, and definitely let us know your opinions and suggestions. We would love to work with you to improve implementations and design choices, and make sure the changes align to the overall roadmap of Dalliance!
Changes
This PR implements coloring of BAM reads by strand, rendered using
_SEQUENCEglyphs.The option to color BAM reads is turned on by the option
Highlight mismatches & strands, piggybacking on the previous optionColor mismatches. This option is currently not turned on by default, but I believe it might be reasonable to make this turned on by default for Bam files.Specific changes as follows:
Changes to edit tier panel:
Color mismatchesrenamed asHighlight mismatches & strands.When checked, adds 2 color selector rows for selecting colors of plus strand (default:
lightsalmon) and the minus strand (default:lightskyblue)Changes to glyph rendering (when color strand option selected)
At close up view (defined as
scale> 8), draw rectangle for each base: bases that agree with ref bases are colored using strand colors, as selected in the tier-edit panel. Non-ref bases' rects are colored based on their base colors (defined in the objectbaseColorsincbrowser.js) and labelled with black text. Opacity is adjusted inverse to the read quality score, as previously.At high zoom without closeup (defined as
zoom=high&scale< 8), reads are first drawn as a solid rectangle based on strand direction with height corresponding to half of the tier height. Non-ref bases are drawn over with full height. From working with the browser, we have found this to 1) improve visibility of non-ref bases and 2) reduce rendering time, especially for high depth (>1000) sequencing results. Ref bases are fully opaque and not adjusted based on qual score.Changes to toSVG rendering (when color strand option selected)
SVG rendering always draw each base individually, at full height, with opacity adjusted to qual score, since rendering time is probably not a huge consideration in this case.