It is strange and counterintuitive to see converting WIG to BigWig on loading simple WIG file.

[olegs]

Can we do the same as with plain BED files?

[iromeo]

We can implement *.wig track view from the scratch but what for? Bed files are widely available, and *.wig files are less popular

[iromeo]

Existing impl was the easiest way to support wig files using existing infrastructure and already exist trackview. At the moment we don’t have any user request to change this behaviour. Bigwig track view uses big library to summarise signal by region, as for *.wig files we will have to implement all summarising features in track view. Bed files are much easier to render.

[olegs]

Okay, so that can we create in-memory BIG file instead of creating physical one?

[iromeo]

Big library doesn’t support such feature at the moment. Normally it doesn’t make sense because big files are supposed to be big

[iromeo]

Please reopen this issue after we have got real use cases, users complain or perfomance issues.

[olegs]

I don't agree, when I open wig file locally it's really strange to see some extra activities creating some intermediate cache files.

[iromeo]

Ok, let's move it to the back log.

The fix requires a lot of work related to reimplementing Wig track view or hacking BigWig library to write/read Big files to RAM instead of regular files.

The profit of all these work is not evident for me. Conversion step is ours internal implementation details we don't ask users to convert files manually.

[dievsky]

IGV creates an index for FASTA files on opening (and the index is in a file, not in RAM), so preprocessing (in the form of indexing and caching) is not unheard of in the genome browser world. Conversion to bigWig does exactly that: it creates an index and caches various resolution levels. I think that most people working with wigs know that, so we won't even be confusing them that much.