Terminal exons with exclude_counts?

[qsonehara]

Hello, and thank you for developing and maintaining this excellent tool.

I have a question regarding the exon counts file. I came across the question (#160), and if I understand correctly, the most upstream or downstream exons are expected not to have any exclude_counts. However, when I examined my data, I noticed that even the first exon shows non-zero exclude_counts.

Could you please clarify what types of reads can contribute to these exclude_counts?

Thank you!

[andrewprzh]

Dear @qsonehara

You are right, in this file X corresponds to terminal exons according to the provided annotation.
So, a terminal exon is spanned by a read that, for example, represents a longer isoform, it will counted as skipped (excluded).

Isoform 1:
[ 1 ]---[ 2 ]---[ 3 ]
Isoform 2:
[ 1 ]---[ 2 ]----------[ 4  ]
Read:
[ 1 ]---[ 2 ]----------[ 4  ]

In this example exon 3 will marked as terminal and will have 1 in exclude counts.

Best
Andrey

[qsonehara]

Dear @andrewprzh

Thank you for your clarification. Upon examining the read alignment bam file using IGV, I noticed that some reads that did not overlap but spanned the gene appeared to be counted as exclude_counts, like the example below.

Gene 1:
        [ 1 ]---[ 2 ]--[ 3 ]
Read:
[ A ]----------------------------[ B ]

As a result, for example, in the screenshot I posted in the previous comment, ENSG00000223972.5 has 5 exclude_counts, but when I looked into the read_assignments file, there was only one read assigned to this gene. Does that sound correct?

I wondered if it would be great to have an option to generate exon/intron counts only using the reads assigned to the gene having the exon/intron since it would better reflect the actual splicing events.

Best,
Kyuto

[andrewprzh]

Dear @qsonehara

Thanks a lot for bringing this up. I kinda thought about this when I posted my reply.
I will try to implement the new way of counting exons in the next version (and maybe keep the old one as optional).

Best
Andrey

[qsonehara]

Dear @andrewprzh

That sounds great!
Thank you for developing and enhancing this tool.

Best,
Kyuto