Error loading a bigWig generated by bedgraphtobigwig into IGV

[williamrowell]

Thanks for the tool! Trying to work it into our flow as a much faster replacement for UCSC tools.

I'm trying to create bigWigs for basemod data, starting with pileups generated by other tools. I'm using a container I built by compiling from commit 3844b58 with the Dockerfile below:

FROM rust:1.93.0

WORKDIR /opt
RUN git clone https://github.com/jackh726/bigtools.git \
	&& cd bigtools \
	&& git checkout "3844b58" \
	&& cargo build --release

	ENV PATH "${PATH}:/opt/bigtools/target/release"

Here's some example code that's completing without any errors/warnings/messages:

cut -f 1,2 ${ref_fai} > chromsizes
zcat ${bedgraph} \
| cut -f 1,2,3,${col_num} \
| grep -v '^#' \
| sort -k1,1 -k2,2n \
> temp.bedgraph

bedgraphtobigwig \
    --nthreads ${threads} \
    temp.bedgraph \
    chromsizes \
    ${samp_name}.${feature}.bw

But when I try to load any of these files in IGV, I get the error message below. Any thoughts or hints as to what could be going wrong?

Error loading http://path/to/my.bw: newPosition 0: (-154032140 0)

[jackh726]

Thanks for the report. Not entirely sure on the issue, but there have been cases prior (namely #85) where IGV has been a bit wonky because of int sizes. Do you happen to have a bigwig (and/or input bedGraph) that triggers the error? I could look into it a bit more easily that way.

[williamrowell]

Thanks for taking a look. I generated some smaller examples below (against GRCh38), and the error message is:

Error loading http://path/to/out.bw: newPosition > limit: (489468 > 284)

Archive.zip

[jackh726]

Hmm, not sure - I can load in your file just fine:

What version of IGV are you using? I am using 2.19.4.

I also went through the source for a bunch of different IGV versions and grepped for "newPosition" and there were no results. I may have found where the error is emitted based on "Error loading", which I can trace a bit. But hard to do much without being able to reproduce.

[jackh726]

So, I'm seeing that IGV made some (related) changes prior to the 2.19.0 release:
igvteam/igv@8b364e7
igvteam/igv@1bb1bd1

Curiously, I went ahead and downloaded 2.18.4 and 2.10.3, and could not reproduce on either. However, if this "newPosition > limit" error is the same as orientechnologies/orientdb#9694, it seems related to java nio. I'm wondering if there's maybe a platform-specific or java-specific behavior here.

If you aren't using 2.19+, could you try that and see if it works?

Ultimately, I think the issue is that the chrom index comes after the data, because it's a (spec-compliant) change to be more efficient when writing. IGV did handle this wrong prior to the commits linked above (but seemingly it still works for me?).

[jackh726]

Curiously, I went ahead and downloaded 2.18.4 and 2.10.3, and could not reproduce on either. However, if this "newPosition > limit" error is the same as orientechnologies/orientdb#9694, it seems related to java nio. I'm wondering if there's maybe a platform-specific or java-specific behavior here.

tbh, I'm really not sure why these older version don't break - I'm reading through the old source and they really should.

[williamrowell]

Good call! I was running ancient 2.17.3 (mixture of inertia and using a version blessed by IT). I upgraded to 2.19 and everything works correctly. Sorry for the false alarm, and thanks for looking into it!

[jackh726]

Well, thanks for the report nonetheless. I had speculated on a potential way to rearrange the chrom index section back to the front without reducing the perf benefits - maybe I need to seriously take a look at it.