I've recetly discovered that IGB (9.0.1) doesn't show the the splicing of a read alignment correctly (as per the cigar string int eh bam file) if there is a deletion immediatly prior to the splice.

Attached is a screenshot showing the issue. The three reads in the screenshot that end with 'ATG__T' appear to begin their splice immediatly downstream of the T and indicate a non-canonical splicing event from an A.

Parsing the read alignment directly however indicates that the splicing even is the same for all these reads! The cigar string for this region of these reads gives:

...M2D1M1D296N...

Note the '1D' immediately after the '1M' that is the T base for these reads. IGB is not showing this base as a D (with an underscore), instead rolling it into the Ns. N and D here have a different meaning and not showing the D is both misleading and has consequences. Notably, including the D here then result in these reads splice events beginning with the canonical splicing motif.

I really think IGB needs to report the bam alignment faithfully here and show the deleted 1bp as a deletion....

Reporter: Nick Schurch
E-mail: nschurch@dundee.ac.uk