Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Downsampling of data points in wig points graphs #1516

Open
AlesMaver opened this issue Jun 3, 2022 · 7 comments
Open

Downsampling of data points in wig points graphs #1516

AlesMaver opened this issue Jun 3, 2022 · 7 comments

Comments

@AlesMaver
Copy link

AlesMaver commented Jun 3, 2022

Hi!
We are using IGV.js to plot CNV estimates genome-wide - we are plotting WIGs for this purpose. We noticed, however, that (unlike the Desktop version) IGV.js does some form of aggregation of the WIG points, when in the genome-wide view.
This is challenging because sometimes CNV calls get obfuscated in the genome-wide view and you fail to spot a CNV that would be easily caught in the desktop version of IGV (aggregation averages out some interesting, but short regions with copy number gains or losses).
I understand that this aggregation is done to prevent loading too much data in the browser, but I wanted to nevertheless check if there is an option that regulates the way data is aggregated in the genome-wide view? Is it possible to decrease the level of aggregation or disable it?

Thank you very much in advance for any help with this issue!

@jrobinso
Copy link
Contributor

jrobinso commented Jun 3, 2022

In the genome wide view it downsamples in general, but you can turn it off by setting "maxWGCount" to some large number in the track config, e.g.

maxWGCount: Number.MAX_SAFE_INTEGER

Apologies this should be documented.

@AlesMaver
Copy link
Author

This is absolutely wonderful! Thank you so much - for the instant answer and - IT WORKS!

@jrobinso
Copy link
Contributor

jrobinso commented Jun 3, 2022

You're welcome. Some background, the need for this arose from the interaction track, drawing arcs is expensive and drawing hundreds of thousands of them was bogging down the browser. The data is already loaded. I imagine drawing points is free and you don't notice any difference in speed. So I'm thinking of making this parameter a function of the track type. Also it should be documented, of course, so leave this issue open until I resolve these questions.

@AlesMaver
Copy link
Author

Indeed there is almost no difference in speed - perhaps 1-2 seconds for displaying two tracks with about 200.000 points each so it is unnoticeable. Thank you very much again!

@AlesMaver
Copy link
Author

Just a small add-on question. We have now also tried to do the same with bigWig tracks (to reduce the network traffic used by wigs), however the maxWGcount does not seem to have an effect on bigWig file format. I know that you have already discussed this issue earlier (issue), but I just wanted to check if this is still the case? Thank you!

@jrobinso
Copy link
Contributor

jrobinso commented Jun 7, 2022

You cannot get the raw data points at whole genome view, or any zoom level, with bigwig. It aggregates data points into buckets at all but the most zoomed in region. That is the whole point of it, if it did not do that you would not reduce network traffic. What you can do is gzip your wig, if you aren't already.

@AlesMaver
Copy link
Author

Oh, I understand now - thank you for clarification and for the heads up regarding the ability of igv.js to display gzipped files - we will definitely try this option too!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants