[tfenne]

igv.js can't read big-endian bigWig files (#786). When the magic number doesn't match little-endian, BWReader.loadHeader re-reads it big-endian, which yields the same value as a little-endian file, but compares it against BIGWIG_MAGIC_HTL, which is both the wrong constant to use there and mistyped (0x26FC8F66 rather than 0x26FC8F88). So the file's type is never set. Once that is fixed, the wig and zoom decoders still read big-endian blocks as little-endian, because they take a littleEndian argument that is never passed; they now use this.littleEndian, as the bigBed decoder already does. The unused _HTL constants are removed. The magic-number fix also applies to big-endian bigBed files, which I haven't tested separately.

The new test in testBigwig.js reads raw and zoom data from test/data/bb/bigEndian.bw (1,040 bytes). kent's tools only write the host's byte order, so the file was written with bigwig-rs, whose interop tests found this bug; kent's bigWigInfo and bigWigToBedGraph read it correctly. npm test passes.

Program that wrote the test file (bigwig-rs 8898bbc)

use bigwig::{ByteOrder, ChromInfo, WriterOptions, ZoomPolicy};

fn main() -> bigwig::Result<()> {
    let chroms = [ChromInfo::new("chr1", 2_000)];
    let intervals: Vec<(u32, u32, f32)> =
        (0..20u32).map(|i| (i * 100, i * 100 + 50, (i + 1) as f32)).collect();
    let mut writer = WriterOptions::new()
        .byte_order(ByteOrder::Big)
        .zoom(ZoomPolicy::Explicit(vec![800]))
        .index_block_size(4)
        .create("bigEndian.bw", &chroms)?;
    writer.push_intervals("chr1", &intervals)?;
    writer.finish()?;
    Ok(())
}