bigtools
bigtools copied to clipboard
jackh726
visualizing methylation levels at individual CpG sites
When I run bedgraphtobigwig on this bedgraph file:
chr1 69590 69591 0.783515615800065
chr1 191549 191550 0.4875594150534202
chr1 259409 259410 0.7866381108397801
chr1 605419 605420 0.3955424153029119
chr1 633317 633318 0.11658784436577774
chr1 777871 777872 0.9435822827865346
chr1 777912 777913 0.9245702644897906
chr1 779896 779897 0.43717435961143386
chr1 803583 803584 0.451108712860254
chr1 817114 817115 0.1956207519829175
and visualize the resulting bigwig file in IGV (version 2.19.4), I get this visualization:
whereas I was expecting 10 bars, each 1bp wide. What am I doing wrong? Thanks.
I'm curious if IGV is maybe using zoom data or something. I don't have the time to dig into this right now, but you could try passing --nzooms 0 and see what you get.
So, that's potentially right? Not sure if IGV will display 1 BP regions at that resolution. If you zoom in, can you see them?
No, you can't. In this image, I'm expecting to see a single bar of height 0.783515615800065 at chr1:69590 ...
Interesting...thanks for hanging in, but one last thought: does 2bp-sized regions display? What about more? I just wonder if IGV renders such small regions weird.
I changed the second record to encompass 2bps, and the third record to encompass 3bps. Still nothing.
chr1 69590 69591 0.783515615800065
chr1 191549 191551 0.4875594150534202
chr1 259409 259412 0.7866381108397801
Okay, can you tell me exactly the command you're running? Running with --nzooms 0, I can't reproduce:
bedgraphtobigwig --nzooms 0 208567320164_R08C01.unique.sorted.no_nulls.no_bounds_errors.sorted.head.bed /scratch/ucgd/lustre-labs/quinlan/data-shared/constraint-tools/reference/grch38/chromosome-sizes/hg38.chrom.sizes.sorted a.bw
$ cat /scratch/ucgd/lustre-labs/quinlan/data-shared/constraint-tools/reference/grch38/chromosome-sizes/hg38.chrom.sizes.sorted
chr1 248956422
chr2 242193529
chr3 198295559
chr4 190214555
chr5 181538259
chr6 170805979
chr7 159345973
chr8 145138636
chr9 138394717
chr10 133797422
chr11 135086622
chr12 133275309
chr13 114364328
chr14 107043718
chr15 101991189
chr16 90338345
chr17 83257441
chr18 80373285
chr19 58617616
chr20 64444167
chr21 46709983
chr22 50818468
chrX 156040895
chrY 57227415
Can you share your output bigwig?
And, can you try this bigwig in your IGV? https://www.dropbox.com/scl/fi/flj40nvg7gbjrwsx5nz4h/regions.bigWig?rlkey=iosxxv79f4dredz9y8rm6eo8x&st=ha7plj6b&dl=0
Here's the bigwig I was using: https://www.dropbox.com/scl/fi/hrvtojv08ijcuy3wjbcu6/a.bw?rlkey=zmf4g34zmbzhl11io2da2s831&st=qo24cgab&dl=0
So...something is weird with IGV here...what version are you using? I am using 2.15.4.
One thing: can you manually set your data range to 0-1? I don't think this is the issue, but certainly something to double check.
I wonder if a regression was introduced in https://github.com/igvteam/igv/pull/1688
Opened an issue there. Really can't dig in more to this right now though. Sorry. I will get back to this when I get more time.
Hi @petermchale , I can't reproduce the issue with your original file. My test files are here: https://www.dropbox.com/scl/fi/27wueak6jfojdvf10794n/test.bedgraph?rlkey=uh3u9aemyxotsidu598jwszm6&dl=0, https://www.dropbox.com/scl/fi/4nqp7bhjk5zap7mqjwt4l/test.bw?rlkey=fx1b500fjiz0k1djmyipvf23f&dl=0. I created the bigwig as follows
bedGraphToBigWig test.bedgraph http://hgdownload.soe.ucsc.edu/goldenPath/hg38/bigZips/hg38.chrom.sizes test.bw
screenshot
There is an issue with nzooms == 0, which we will fix. In the meantime insure your file has at least 1 zoom level, unless you explicitly set nzooms = 0 it should.
Here's a comparisom between the bw and bedgraphs linked above with 2.19.4.
@jrobinso so, thanks for fixing the bug with nzooms == 0
It does seem like there is some other underlying weirdness here. I went ahead and made a bigWig with both bigtools and ucsc:
Bigtools bigWig: https://www.dropbox.com/scl/fi/4nps0cjfonpr95926fni4/regions_bigtools.bigWig?rlkey=0lyuvf6dv2uxkwu1cjftn10br&st=23bl6x4j&dl=0 UCSC bigWig: https://www.dropbox.com/scl/fi/cp5698c25dd1w4lhohsma/regions_ucsc.bigWig?rlkey=8q1dgrmekqdqc6zlf3s5fx8m9&st=q5k77v5b&dl=0
I'll have to dig in to figure out exactly what zoom intervals bigtools is emitting, but it does seem off.
At that zoom IGV is probably not using zoom levels. If you convert the bigtools bigwig back to wig or bedgraph using UCSC's tools do you get the original file?
Yes (other than a slight loss in float precision):
./bigWigToBedGraph regions.bigWig /dev/stdout
chr1 69590 69591 0.783516
chr1 191549 191550 0.487559
chr1 259409 259410 0.786638
chr1 605419 605420 0.395542
chr1 633317 633318 0.116588
chr1 777871 777872 0.943582
chr1 777912 777913 0.92457
chr1 779896 779897 0.437174
chr1 803583 803584 0.451109
chr1 817114 817115 0.195621
Ok, the difference then is probably something in zoom levels, as you suggest.
Yeah, it's just curious to me that IGV is picking the zooms anyways...even when zooming in to the base-level, it's still picking the zoom over the full data...
@jackh726 Its not doing this with the ucsc bigwig. You can see that if you zoom into base level.
It is deciding what zoom level to use, or whether to use a zoom level at all, based on the "reductionLevel" value for each zoom. This is compared with the current resolution.
I think the problem is with zoom level 0, which has a negative reduction level. I suspect you have an integer overflow bug.
So, the zooms provided by bigWigInfo do not show a problem in reduction level:
./bigWigInfo -zooms regions.bigWig
version: 4
isCompressed: yes
isSwapped: 0
primaryDataSize: 200
primaryIndexSize: 84
zoomLevels: 8
163840 149
655360 69
2621440 41
10485760 41
41943040 41
167772160 41
671088640 41
2684354560 41
chromCount: 1
basesCovered: 10
mean: 0.552190
min: 0.116588
max: 0.943582
std: 0.292382
./bigWigInfo -zooms regions_ucsc.bigWig
version: 4
isCompressed: yes
isSwapped: 0
primaryDataSize: 137
primaryIndexSize: 6,204
zoomLevels: 3
163840 123
655360 74
2621440 43
chromCount: 1
basesCovered: 10
mean: 0.552190
min: 0.116588
max: 0.943582
std: 0.292382
edit: well, actually the biggest zoom there is greater than an int... edit2: ah so it's greater than a signed int, but smaller than an unsized int, which is what the zoom reduction level is defined as edit3: though, these zooms are kind of just "wrong" (though valid) given that they are bigger than the chromosome size