Hello,
I'm new to working with RNAseq data and have a question about counting reads with HTSeq.
I have stranded data that was mapped using the default parameters in STAR. I am counting the reads using HTSeq with the parameters:
--type=exon
--mode=intersection-nonempty
--idattr=Parent
--format=bam
When I use the --stranded=yes option, fewer than 10% of reads are counted; the majority have "no feature." But when I use the --stranded=reverse option, over 80% of the reads are counted. Similarly, when I use the --stranded=no option, over 80% of the reads are counted.
I'm just wondering what could explain this pattern. Is this a typical outcome? Should I be concerned? I think that as a newbie I must be missing some key information about the stranded RNAseq protocol. Which, in this case, was the Illumina TruSeq Stranded protocol.
I'm pretty stumped so any insight into this matter would be greatly appreciated!
Thanks,
SM
I'm new to working with RNAseq data and have a question about counting reads with HTSeq.
I have stranded data that was mapped using the default parameters in STAR. I am counting the reads using HTSeq with the parameters:
--type=exon
--mode=intersection-nonempty
--idattr=Parent
--format=bam
When I use the --stranded=yes option, fewer than 10% of reads are counted; the majority have "no feature." But when I use the --stranded=reverse option, over 80% of the reads are counted. Similarly, when I use the --stranded=no option, over 80% of the reads are counted.
I'm just wondering what could explain this pattern. Is this a typical outcome? Should I be concerned? I think that as a newbie I must be missing some key information about the stranded RNAseq protocol. Which, in this case, was the Illumina TruSeq Stranded protocol.
I'm pretty stumped so any insight into this matter would be greatly appreciated!
Thanks,
SM
Comment