 | 1 | initial version |
We have designed GenomeBrowse to scale wonderfully to whole genome DNA-seq data, and there are no hard-coded limits on file size or read density or pretty much anything.
What generally becomes the constrained resource in any big-data visualization system is how much data you can hold in RAM to render your plots in full detail.
Even here we have worked to make the worst-case scenario of millions and millions of reads in a small (<10kb) window at least not break GenomeBrowse. Instead, we drop some reads from the pile-up plot but continuing to count them in the coverage plot. You will get a little warning icon on the bottom of your pile-up plot if you do ever get to such a high-density region.
If you experience any failures to handle large files, we would consider it a bug. In such cases we ask for your help if at all possible to share your data security so we can reproduce and resolve the issue.
| | 2 | grammer fixes |
We have designed GenomeBrowse to scale wonderfully to whole genome DNA-seq data, and there are no hard-coded limits on file size or read density or pretty much anything.
What generally becomes the constrained resource in any big-data visualization system is how much data you can hold in RAM to render your plots in full detail.
Even here we have worked to make the worst-case scenario of millions and millions of reads in a small (<10kb) window at least not break GenomeBrowse. Instead, we drop some reads from the pile-up plot but while continuing to count them in the coverage plot. You will get a little warning icon on the bottom of your pile-up plot if you do ever get to such a high-density region.
If you experience any failures to handle large files, we would consider it a bug. In such cases we ask for your help if at all possible to share your data security securely so we can reproduce and resolve the issue.
