Inconsistent Bigwig Track loading Mac IGV Desktop 2.17 onwards

[navinbr]

Hi Team

I have faced a perplexing issue with all bigwig files loading succesfully (and well-formated with colours/caling) on IGV versions <2.16.2, but some bigwig tracks consistently failing to show any peaks on IGV versions >2.17 (I tested 2.17.0, 2.17.4 and 2.18.2).

As an example with just a few of these bigwigs, this is the session that loads correctly in IGV 2.16.2:

And this is the same session in IGV 2.18.2 with the first 4 bigwig tracks not showing the peaks at all, but it retains the correct colour of the track just as a flat line. The last 2 bigwigs consistently show up normally. If i expand the height of the tracks - the expected numerical data range is shown (meaning it can read the data in the backend)- yet no peaks are seen. I cannot figure out why some tracks consistently do not show up in >IGV 2.17 and why some show up normally.

My apps are on the Macbook (MacOSX Sonoma 14.5) with M1 chip, and I have downloaded IGV versions with embedded Java. I also have Java running on my Mac with the following version "java version "1.8.0_431"
Java(TM) SE Runtime Environment (build 1.8.0_431-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.431-b10, mixed mode)".

I have also tested the bigwigs on the IGV Web App - they show up properly on there too.

Thank you for any help!

[jrobinso]

Could you share one of the bigwigs exhibiting this behavior?

[navinbr]

Thanks Jim, Ive just emailed igvteam@broadinstitute.org with 2 bigwigs in a dropbox link: 1 showing this behavior (not showing in versions >2.17), and another that shows up normally in all versions.

[navinbr]

Apologies, the email bounced. Would you have a preferred email address I may use? Thank you.

[helgathorv]

The email is igv-team@broadinstitute.org (note the "-")
Ignore the auto reply message that is sent.

[navinbr]

Email sent, thank you.

[jrobinso]

Thanks for the test data. I can't reproduce the issue with the latest release. Looking at the release notes there were some bigwig fixes for release 2.18.3. If you can reproduce the issue with the latest release give me exact instructions, e.g. where to zoom to.

[navinbr]

Hi Jim. Even With IGV 2.18.4 I see the same issue. Perhaps when you loaded the tracks your view was an "All" chromosomes. Indeed as below, on "All" the tracks load with peaks shown - with no issue at all.

However, the moment any zoom in is done e.g. "Chr1", the peaks diassapear for the problematic bigwig example I sent to you (ORANGE) (evethough autoscale is done), yet the data range remains shown as pictured. The bigwig track name beginning BLUE shows no issue.

Thus in this trial I learnt that the peaks can show up in the "All" view, but the moment any zoom is done, the peaks fail to show for some of these bigwig tracks, such as the file I shared beginning "ORANGE".
So to reproduce on your end, could you zoom into any region - e.g. specific chromosomes or any coordinates. The earlier example I had used was the GAPDH locus at chr12:6,528,762-6,544,125. May I ask if you're on the mac? If you're able to reproduce it, could you check against IGV 2.16 where all peaks show properly for me? Thank you!

This is the problematic view at the GAPDH locus as an example, on IGV 2.18.4, where the bigwig track ORANGE fails to show peaks, despite autoscale turned on and the datarange showing values 0-0.22 (invariant despite clicking autoscale, but peaks/signal should show at this scale):

As the "control" example, here is what the ORANGE-file peaks should look like when viewed in IGV 2.16.2, with autoscale and datarange of 0-1.19 shown (here the autoscale shows correct numbers):

Note that when I checked using data range of 0-0.22 (the invariant autoscale numbers shown in the IGV 2.18.4 example above), clear signal can still be seen in IGV 2.16.2 below, but not in 2.18.4 as above):

[jrobinso]

I think I can reproduce it now, by manually setting the scale in 2.18.4 to equal the scale from 2.16.2.

[jrobinso]

I mis spoke, on closer inspect I can't reproduce this with 2.18.4. Here's what I did

1. Load "Orange"
2. Jump to GAPDH

That's it, result shown below. I'm on a Mac. The next step would be to look for differences in our user preferences. I'm using defaults. To be sure you are using default settings do the following

1. Shutdown igv
2. Rename "prefs.properties" in you igv folder to "prefs.properties.bak". You igv folder is under your home directory.
3. Restart IGV and try again

[navinbr]

Hi Jim. Yes renamed to .bak then I opened IGV 2.18.4 and added the ORANGE track. I get the same issue with peaks showing only on "All" view but not upon zoom. I assume upon the rename, the IGV goes to default properties (As I see that a new properties file is generated).

However, I agree with you that the problem seems isolated to my Mac as when I tested on a colleagues Mac (IGV 2.17.3, Sonoma OSX 14.2) the peaks did show up. It may be related to me having multiple versions of IGV installed perhaps. Edit: I have removed all other versions leaving 2.18.4 only and also refreshed properties file and did a mac restart. I still get the same issue unfortunately.

[jrobinso]

It's a real mystery, I don't see how multiple version could affect this. I have at least a dozen installed.

There might be some information in your igv log file (in the igv folder, usually igv0.log).

[navinbr]

Had a look at the log for a simple opening of both files - one that shows and the other that does not:

Log (scrubbed):
INFO [Oct 24,2024 18:28] [Main] Startup IGV Version 2.18.4 10/03/2024 09:12 AM
INFO [Oct 24,2024 18:28] [Main] Java 17.0.9 (build 17.0.9+9) 2023-10-17
INFO [Oct 24,2024 18:28] [Main] Java Vendor: Eclipse Adoptium https://adoptium.net/
INFO [Oct 24,2024 18:28] [Main] JVM: OpenJDK 64-Bit Server VM Temurin-17.0.9+9
INFO [Oct 24,2024 18:28] [Main] OS: Mac OS X 14.5 x86_64
INFO [Oct 24,2024 18:28] [Main] IGV Directory: /Users/XXX/igv
INFO [Oct 24,2024 18:28] [OAuthUtils] Loading Google oAuth properties
INFO [Oct 24,2024 18:28] [CommandListener] Listening on port 60151
INFO [Oct 24,2024 18:28] [GenomeManager] Loading genome: /Users/XXX/igv/genomes/hg38.json
INFO [Oct 24,2024 18:28] [TrackLoader] Loading resource: https://hgdownload.soe.ucsc.edu/goldenPath/hg38/database/ncbiRefSeq.txt.gz
INFO [Oct 24,2024 18:28] [TrackLoader] Loading resource: /Users/XXX/Library/CloudStorage/Dropbox/IGV-1606/BLUE-H9-H3K27me3_Rep1.hg38.BPM.all.bw
INFO [Oct 24,2024 18:28] [TrackLoader] Loading resource: /Users/XXX/Library/CloudStorage/Dropbox/IGV-1606/ORANGE-H9_hESC_H3K4me1_REP2.bigWig

It appears to not show an error, but perhaps you may spot something amiss with the java utilised? Otherwise, this may be tricky to troubleshoot as it's localised to my mac and I wish not to trouble you too much (I can always use versions 2.16 and below to visualise these tricky tracks and 2.18 for the rest of my work for now). However, if you do come up with an idea of what I may troubleshoot, do go ahead to let me know. Thank you!

[jrobinso]

Everything looks normal there. In any event some bigwigs look normal for you, and other's don't, correct?

[navinbr]

Yes some bigwigs are always normal and some cannot show properly on versions >=2.17 (and this is consistent behaviour). Only happens on my Mac, but no issues on a colleagues Mac or on IGV web app. Already tried with default properties too and the log doesn’t flag any error.

[jrobinso]

All this aside, there is still the bug with IGV versions > 2.18.1. We will deploy a fix for that soon.

[jrobinso]

Sorry, accidentally close, mixed up with another issue

[navinbr]

Hi Jim, I managed to solve it. Instead of relying on the pre-exisiting hg38 selection on the dropdown (which technically should be all fine as I've used it all this while), I clicked on Genomes > SelectHosted Genome... and reselected hg38. This refreshed the hg38.json file timestamp, and with this, the odd behaviour from the problematic big wig files stopped. Thanks for all the help in the meantime - I hope this information helps!

[navinbr]

Alright I found the old hg38.json version from scouring my backup hard-drive.

New hg38.json file:
{
"id": "hg38",
"name": "Human (GRCh38/hg38)",
"fastaURL": "https://igv.org/genomes/data/hg38/hg38.fa",
"indexURL": "https://igv.org/genomes/data/hg38/hg38.fa.fai",
"cytobandURL": "https://hgdownload.soe.ucsc.edu/goldenPath/hg38/database/cytoBandIdeo.txt.gz",
"aliasURL": "https://igv.org/genomes/data/hg38/hg38_alias.tab",
"twoBitURL": "https://hgdownload.soe.ucsc.edu/goldenPath/hg38/bigZips/hg38.2bit",
"chromSizesURL": "https://hgdownload.soe.ucsc.edu/goldenPath/hg38/bigZips/hg38.chrom.sizes",
"chromosomeOrder": "chr1,chr2,chr3,chr4,chr5,chr6,chr7,chr8,chr9,chr10,chr11,chr12,chr13,chr14,chr15,chr16,chr17,chr18,chr19,chr20,chr21,chr22,chrX,chrY",
"tracks": [
{
"name": "Refseq Curated",
"format": "refgene",
"url": "https://hgdownload.soe.ucsc.edu/goldenPath/hg38/database/ncbiRefSeqCurated.txt.gz",
"indexed": false,
"order": 1000001,
"infoURL": "https://www.ncbi.nlm.nih.gov/gene/?term=$$"
}
]
}

Old hg38.json file timestamped Feb 2022:
{
"id": "hg38",
"name": "Human (GRCh38/hg38)",
"fastaURL": "https://s3.amazonaws.com/igv.broadinstitute.org/genomes/seq/hg38/hg38.fa",
"indexURL": "https://s3.amazonaws.com/igv.broadinstitute.org/genomes/seq/hg38/hg38.fa.fai",
"cytobandURL": "https://s3.amazonaws.com/igv.org.genomes/hg38/annotations/cytoBandIdeo.txt.gz",
"aliasURL": "https://s3.amazonaws.com/igv.org.genomes/hg38/hg38_alias.tab",
"tracks": [
{
"name": "Refseq Genes",
"format": "refgene",
"url": "https://s3.amazonaws.com/igv.org.genomes/hg38/ncbiRefSeq.sorted.txt.gz",
"indexURL": "https://s3.amazonaws.com/igv.org.genomes/hg38/ncbiRefSeq.sorted.txt.gz.tbi",
"visibilityWindow": -1,
"removable": false,
"order": 1000000,
"infoURL": "https://www.ncbi.nlm.nih.gov/gene/?term=$$"
},
{
"name": "Genes",
"format": "bed",
"url": "https://s3.amazonaws.com/igv.org.genomes/locations/geneLocations_hg38.bed.gz",
"hidden" : true,
"searchable": true
}
],
"chromosomeOrder": "chr1, chr2, chr3, chr4, chr5, chr6, chr7, chr8, chr9, chr10, chr11, chr12, chr13, chr14, chr15, chr16, chr17, chr18, chr19, chr20, chr21, chr22, chrX, chrY"
}

Maybe this may be helpful.

[jrobinso]

Wow, I never would have guessed that! Thanks for the followup.