{"action":"created","issue":{"url":"https://api.github.com/repos/igvteam/igv/issues/277","repository_url":"https://api.github.com/repos/igvteam/igv","labels_url":"https://api.github.com/repos/igvteam/igv/issues/277/labels{/name}","comments_url":"https://api.github.com/repos/igvteam/igv/issues/277/comments","events_url":"https://api.github.com/repos/igvteam/igv/issues/277/events","html_url":"https://github.com/igvteam/igv/issues/277","id":165011532,"number":277,"title":"Improved support for PacBio reads","user":{"login":"amwenger","id":7155109,"avatar_url":"https://avatars.githubusercontent.com/u/7155109?v=3","gravatar_id":"","url":"https://api.github.com/users/amwenger","html_url":"https://github.com/amwenger","followers_url":"https://api.github.com/users/amwenger/followers","following_url":"https://api.github.com/users/amwenger/following{/other_user}","gists_url":"https://api.github.com/users/amwenger/gists{/gist_id}","starred_url":"https://api.github.com/users/amwenger/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/amwenger/subscriptions","organizations_url":"https://api.github.com/users/amwenger/orgs","repos_url":"https://api.github.com/users/amwenger/repos","events_url":"https://api.github.com/users/amwenger/events{/privacy}","received_events_url":"https://api.github.com/users/amwenger/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-07-12T07:28:09Z","updated_at":"2016-07-12T22:11:06Z","closed_at":null,"body":"IGV is a very useful viewer for PacBio long read data, but it could be even better with a few modifications.  Ideas to improve support for PacBio data are:\r\n\r\n1. **Add a \"quick consensus\" mode** that only shows mismatches at positions with a consistent alternative variant.  The coverage track has logic that uses an allele threshold to determine whether to show variation at a position.  Add a \"quick consensus\" option and apply the same logic to mismatches within a read.  This would greatly hide the \"random errors\" in long reads and make it possible to see haplotype structure by eye.  It would look something like this:\r\n![quick-consensus](https://cloud.githubusercontent.com/assets/7155109/16758576/3c93dd42-47c7-11e6-9b58-b23794c0b0f6.png)\r\n\r\n\r\n2. **Hide small indels** at low zoom.  Individual PacBio reads have random small deletions errors that show as a series of black dots at low zoom (see picture below).  Hide deletions that occupy <3px of at the current zoom.\r\n<img width=\"631\" alt=\"many-deletions\" src=\"https://cloud.githubusercontent.com/assets/7155109/16758579/41e5b414-47c7-11e6-98ac-0ba1819c1960.png\">\r\n\r\n\r\n3. **Label the size of large insertions and deletions**.  Modify the \"Flag insertions large than N bases\" option to be \"Label insertions and deletions larger than N bases\".  \"Large\" insertions and deletions would show at all zoom levels.  One idea for how to show the variant size is to use a filled upward pointing trapezoid for insertions and a hollow download pointing trapezoid for deletions:\r\n![insertion-size](https://cloud.githubusercontent.com/assets/7155109/16758582/45b03312-47c7-11e6-9470-dcfe8f6ee86c.png)\r\n![deletion-size](https://cloud.githubusercontent.com/assets/7155109/16758585/47bc7a62-47c7-11e6-874f-b25df68cf3be.png)\r\n\r\n\r\n4. **Show clipping information at the end of reads**.  Read clipping can indicate the presence of a structural variant.  Show the number of clipped bases in a \"cap\" at the end of reads:\r\n![cliipping-cap](https://cloud.githubusercontent.com/assets/7155109/16758588/4c2b6536-47c7-11e6-89b6-93328386527d.png)\r\n\r\n\r\n5. **Show variation at low zoom** to enable viewing haplotype structure.  I would prefer to see SNVs and large indels even when zoomed out to 100kb+.\r\n\r\n6. **Add a \"group by SNV\" feature** to provide a \"quick phasing\" of reads.  Right click on a position would provide the option to group reads based on the basepair at that position.  By selecting a position with a heterozygous SNV, the reads could be \"phased\" into haplotypes:\r\n![group-by-snv](https://cloud.githubusercontent.com/assets/7155109/16758589/51384698-47c7-11e6-9fb8-65d4c2efbe00.png)\r\n\r\n7. **Color basepairs based on interpulse distances**, which indicate methylation status.  The interpulse distance is provided in the [\"ip\" SAM annotation] (http://pacbiofileformats.readthedocs.io/en/3.0/BAM.html).  Instead of the standard \"gray\" background color, this would show a different shade at each basepair as a function of IPD.\r\n\r\n8. **Improve performance**.  Rendering PacBio alignments in IGV is often slow, and it is not practical currently to render read information at low zoom.  One cause is that PacBio reads have frequent indel errors that break the alignment into many, many CIGAR blocks.  Some of the rendering logic is performed per CIGAR block, not per alignment.  Thus, rendering PacBio reads is much more expensive than the equivalent coverage in Illumina reads, which are often 1-2 blocks per alignment. For example, 40-fold coverage over 1kb would be something like 40 PacBio reads, each broken into ~100 CIGAR blocks for a total of 4,000 CIGAR blocks; it would require 400 Illumina reads, each broken into ~1 CIGAR block for a total of 400 blocks.  So, the estimated cost is 10x higher for PacBio reads when operations are performed per block and not per alignment.\r\n\r\n9. **Add a generic \"Send read to URL\" feature** that is like the \"Blat read sequence\" option but supports user-defined URLs.  Some data representation (e.g. read v ref dotplot) is difficult to show within IGV but could be built as a separate web application. The user should be able to add new URLs and define which information is sent with a request: read name, read sequence, reference span, reference sequence, and CIGAR string, and others.\r\n\r\n10. **Color / shade basepairs based on percent identity with the reference sequence in a sliding window** (say +/-10bp).  This would serve as a simple empirical base QV score and would identify low-quality regions of a read.\r\n\r\nI have a version of many of these changes in a personal fork.  I am happy to clean them up and contribute them to the main project."},"comment":{"url":"https://api.github.com/repos/igvteam/igv/issues/comments/232197541","html_url":"https://github.com/igvteam/igv/issues/277#issuecomment-232197541","issue_url":"https://api.github.com/repos/igvteam/igv/issues/277","id":232197541,"user":{"login":"jrobinso","id":933148,"avatar_url":"https://avatars.githubusercontent.com/u/933148?v=3","gravatar_id":"","url":"https://api.github.com/users/jrobinso","html_url":"https://github.com/jrobinso","followers_url":"https://api.github.com/users/jrobinso/followers","following_url":"https://api.github.com/users/jrobinso/following{/other_user}","gists_url":"https://api.github.com/users/jrobinso/gists{/gist_id}","starred_url":"https://api.github.com/users/jrobinso/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jrobinso/subscriptions","organizations_url":"https://api.github.com/users/jrobinso/orgs","repos_url":"https://api.github.com/users/jrobinso/repos","events_url":"https://api.github.com/users/jrobinso/events{/privacy}","received_events_url":"https://api.github.com/users/jrobinso/received_events","type":"User","site_admin":false},"created_at":"2016-07-12T22:11:06Z","updated_at":"2016-07-12T22:11:06Z","body":"I don't understand (8),  what do you mean by \"operations are performed per block\".    Could you elaborate with cpu profiling data?   The solution we applied earlier to this problem was to set a filter and ignore indels < some size,  combining the adjacent blocks.   I think the cpu cost is in the drawing operations, it doesn't matter if you loop through 40,000 blocks or 400 blocks if you draw the same elements you will incur the same cost.   At least that is my recollection of previous profiling,  some hard data is needed here and anywhere where performance is being discussed."}}
{"actor":{"display_login":"jrobinso"}}