Moving out of the current sprint. Also closing, as the majority of the index hacking work is done.
Creating a new ticket for the next steps mentioned in the previous comment.

After testing with additional files I noticed that there are odd discrepancies in the output when compared to IndexCov and BioVizBase. When I compared the bedgraph output between IGB, IndexCov, and BioVizBase to the bam file itself, it was clear that BioVizBase produced the only output that perfectly matched the bam data.

I checked the output generated by IGB when calculating the scores using just the offsets, the chunk sizes, or the combined chunk sizes. It did not appear that any of these approaches matched the BioVizBase output exactly. After examining the BioVizBase R code (estimateCoverage), it appears the process of calculating the bin sizes is more complex than we initially thought.

The next step is to debug the BioVizBase R code to fully understand how each bin size is calculated: https://github.com/jorainer/biovizBase/blob/master/R/coverage.R

Note that debugging the coverage.R code requires C code.

Please see my changes in the commit below:
https://bitbucket.org/pbadzuh/igb_pbdev/commits/cf9c32ec1c2465dac6c03d6b9e46244a1dea2647?at=IGBF-2482

These:

• Make normalization based on the genome level rather than chromosome level mean bin size.
• Remove unused code/imports.
• Add/modify comments for clarification.

I was unable to find a way to circumvent the use of a dummy bam file in order to access index information using htsjdk, so the dependency as modified by Charan has been maintained.

Some notes on investigating the organization of bai contents:

• Chunks from different bins overlap, suggesting that read data applies to both bins (e.g. 1 and 3). This, in turn, suggests that reads span the bins, implying that 5th level bin chunks include data from higher level bins.

• Based on the above, it seems as if the first chunk is the primary data pertaining to a bin and consecutive chunks are those from higher level bins, however, I don’t understand how a read can span distant bins e.g. 1 and 3. This would imply the read length is > 16,384 bp (the span of a single bin), which doesn’t make sense for illumina, the sequencing method used in the alignment I analyzed.