You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've always wanted to use this executable instead of Kent's bedGraphToBigWig for several reasons, but probably the main one would be to avoid uncompressing the bedgraph file, which is a major limitation when dealing with big bam/cram files. Unfortunately, I've never been completely able to integrate it in our pipelines since the bigwig files generated sometimes didn't work when loading them in IGV.
I've just decided to have a deep look at it, and I've found a strange behaviour that I've traced down to this little example which you can replicate yourself:
I've always wanted to use this executable instead of Kent's bedGraphToBigWig for several reasons, but probably the main one would be to avoid uncompressing the bedgraph file, which is a major limitation when dealing with big bam/cram files. Unfortunately, I've never been completely able to integrate it in our pipelines since the bigwig files generated sometimes didn't work when loading them in IGV.
I've just decided to have a deep look at it, and I've found a strange behaviour that I've traced down to this little example which you can replicate yourself:
As you can see, line
chr1 11259857 11259933 1
gets reduced to
chr1 11259857 11259932 1
and a new erroneous line
chr1 11259932 11260007 1
appears.
Do you have any idea why this could be happening?
The text was updated successfully, but these errors were encountered: