5
$\begingroup$

I generate bigWig files using bamCoverage from deeptools, in part for my colleagues to visualize their mapped libraries in the IGV viewer.

A problem is that the displayed track name is apparently the file name, which is not convenient because some files for different libraries have the same name. The reason is that the files are organized with one directory per library. I would prefer to avoid changing the way I name and organize the files.

Is there a way to edit my bigWig files in order to have control of the track name independently from the file name?

As far as I understand, bigWig format derives from wiggle format, which have a track definition line that can contain a name and a definition attribute: https://genome.ucsc.edu/goldenpath/help/customTrack.html#TRACK.

Maybe there is a way to convert a bigWig file back to wiggle, edit the track definition, and then rebuild an updated bigWig file.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
4
$\begingroup$

There's no equivalent to the wiggle header in bigWig (or bigBed) files, which is why UCSC uses the file name. This is actually the reason for the track line stuff that you linked to, since you can then specify a name and just point to where the bigWig (or other format) file is on the internet.

BTW, you can certainly convert your bigWig to wiggle, add the track line, and convert it back with UCSC tools (e.g., bigWigToWig and wigToBigWig). It shouldn't change the track name when you display it in UCSC (though if it does, then let me know, since I'll modify pyBigWig and libBigWig to support that then).

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ Using bigWigToWig, I can indeed obtain a wig file from the bigwig and add a custom track name that is displayed in IGV. Then, rebuilding a bigwig using wigToBigWig indeed looses the track name and I get the file name instead in IGV. This is for biwig files obtained directly with bamCoverage. I failed at reconverting wig to bigwig when the initial bigwig file was "manually" generated using pyBigWig. wigToBigWig complained as follows: line 1507430 of tests/tmp.wig: chromosome I has 15072434 bases, but item ends at 15072440. I guess I should post another question regarding this issue. $\endgroup$
    – bli
    Commented Jun 14, 2017 at 12:49
  • $\begingroup$ Thanks for the update, at least my understanding of bigWig headers was correct :) $\endgroup$
    – Devon Ryan
    Commented Jun 14, 2017 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.