NullPointerException while loading bigwig track

[Stuart Andrews]

Hi,

IGV is throwing a NullPointerException while retrieving zoom-level data (see below) for a bigwig file that I selected from the "Load from file ..." dialog.

I suspect my problem is with the bedGraphToBigWig utility used to create the file, however it could be an issue with how IGV loads certain bigwig files ...

Ultimately, I would like to generate a compressed coverage track corresponding to an bam alignment, and I am using the often-cited pipeline:

samtools view -b BAMFILE | bedtools genomecov -ibam stdin -split -bg -g CHROMSIZES > BEDGRAPH
sort -k1,1 -k2,2n BEDGRAPH > BEDGRAPH.sorted
bedGraphToBigWig BEDGRAPH.sorted CHROMSIZES BIGWIG

I would appreciate it if you could share any ideas or work-arounds.

Thanks,
- Stu

... details ...

I am running

bedGraphToBigWig test.bedGraph chrom_sizes.txt test.bw

with the following input file (test.bedGraph),

1 99213343 99213420 1
1 99213555 99213579 1
1 101812951 101813052 1
1 104285951 104285953 1
1 104285953 104285954 3
1 104285954 104285956 4
1 104285956 104285978 5
1 104285978 104285979 3

and a chromosome sizes file (chrom_sizes.txt),

1 135534747

the tool runs without error generating a BigWig file that is well-formed but appears empty, according to bigWigInfo:

> bigWigInfo test.bw
version: 4
isCompressed: yes
isSwapped: 0
primaryDataSize: 90
zoomLevels: 0
chromCount: 1
basesCovered: 0
mean: nan
min: 0.000000
max: 0.000000
std: nan

and will not load into IGV. To add to the mystery, I can duplicate the original file with bigWigToBedGraph test.bw test1.bedGraph . This has worked for me countless times before, and even works for the first 5 lines of the bedgraph input file shown above.

This is on a Mac computer running ML with up-to-date software.


ERROR [2013-02-27 18:10:49,973] [IGV.java:1491] [pool-1-thread-5] Error loading tracks
java.lang.NullPointerException
at org.broad.igv.bigwig.BigWigDataSource.getZoomLevelForScale(BigWigDataSource.java:179)
at org.broad.igv.bigwig.BigWigDataSource.initMinMax(BigWigDataSource.java:96)
at org.broad.igv.bigwig.BigWigDataSource.<init>(BigWigDataSource.java:70)
at org.broad.igv.track.TrackLoader.loadBWFile(TrackLoader.java:758)
at org.broad.igv.track.TrackLoader.load(TrackLoader.java:213)
at org.broad.igv.track.TrackLoader.load(TrackLoader.java:101)
at org.broad.igv.ui.IGV.load(IGV.java:1529)
at org.broad.igv.ui.IGV$10.run(IGV.java:1473)
at org.broad.igv.ui.IGV.loadResources(IGV.java:1500)
at org.broad.igv.ui.IGV$4.run(IGV.java:618)
at org.broad.igv.util.LongRunningTask.call(LongRunningTask.java:54)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
INFO [2013-02-27 18:10:49,974] [MessageUtils.java:60] [pool-1-thread-5] Error loading /Users/stu/Research/Pathology/Axin/TanHang/UNMAPPED/tohuman/HS85/SamplesPlusfiltered_thout-1/test.bw: null

[Jim Robinson]

Hi,

It looks like this bigwig file does not have any precomputed "zooms" stored, which is surprising.  I actually didn't think it was possible to create a bigwig without zooms.   A workaround would be to create and load a "tdf" file with igvtools from the .bedgraph file (be sure the extension is .bedgraph).    Alternatively you could create a compressed coverage track directly from igvtools,   igvtools count <input.bam> <output.tdf> <genomeId>.

Jim

[Stu]

Thanks Jim, igvtools is working well so far .

[Greg Baillie]

Hi Jim.

I'm getting the exact same NullPointerException when trying to open a bigWig (derived from a bedGraph).

Mac OS X (10.8.2)

IGV Version 2.2.7 (10)

bedGraphToBigWig v 4 (macOSX.i386)

The uncompressed bedGraph loads fine, but not the bigWig. The bigWig does load in UCSC genome browser, however, as does a tdf generated from the bedGraph using igvtools.

Thanks,

Greg.

[Jim Robinson]

Hi,

Yes, same problem. There are no "zoom levels" recorded in these files,
which for us is unexpected. I have a query in with UCSC, I'll post here
when I learn more. Did this work at one time (bigwigs generated from
bedgraphs)?

Jim

[Stuart Andrews]

Greg, Jim,

Are you seeing the same behavior in the output of bigWigInfo?
Could this behavior be Mac-specific?

For ease of testing, I have uploaded my files linked below.

- Stu

https://dl.dropbox.com/u/1603420/debug-bedGraphToBigWig/test.bedGraph
https://dl.dropbox.com/u/1603420/debug-bedGraphToBigWig/test_chrom_sizes.txt

> --
>
> --- You received this message because you are subscribed to the Google Groups "igv-help" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to igv-help+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jim Robinson]

Hi,

Yes, I'm seeing the same results in bigWigInfo (see below). I've
emailed UCSC, I think its probably a bug in bedgraphToWig but at this
point I'm not sure. I have made some modifications in my dev
environment to read these, but performance will be quite poor on large
files as there is no zoom level data to rely on. We could put in a
"zoom in to see data" threshold. First I want to hear back from UCSC,
I doubt they are intentionally creating bigwig files without zoom levels.

Jim

version: 4
isCompressed: yes
isSwapped: 0
primaryDataSize: 90
zoomLevels: 0

chromCount: 3

basesCovered: 0
mean: nan
min: 0.000000
max: 0.000000
std: nan

[Jim Robinson]

Just to follow up,  I've confirmed with UCSC that this appears to be a problem with bedgaphToBigWig,  bigwig files should always have zoom levels.  They are looking into the problem.   When and if I get an update I will post here.  

Jim

[Greg Baillie]

Thanks Jim.

For the record, yes, I'm seeing the same results from bigWigInfo:

version: 4

isCompressed: yes

isSwapped: 0

primaryDataSize: 61,433

zoomLevels: 0

chromCount: 25

basesCovered: 0

mean: nan

min: 0.000000

max: 0.000000

std: nan

[Jim Robinson]

From Jim Kent at UCSC.  They found the bug, this problem occurs when there are not gaps in your data,  see his example below.   I expect they will have an update with a fix soon.

"I mean if you have all items right next to each other:

chr1 100 200

chr1  200 300

chr1 300 400

you'll get the problem,  while if you have

chr1 100 200

chr1 300 400

you won't.

Most of our test cases have gaps in the centromeres and the like, so we didn't catch it in testing.  Thanks for reporting it.  

"