Unexpected results with HTseq-count

[drdna]

I am getting very low counts for genes that I know to be represented by multiple RNAseq reads. I suspect this is because the genes are multi-copy in the genome. In reading how HTseq-count treats such instances, I find the explanation a little confusing: "ambiguous - reads which could have been assigned to more than one feature and hence were not counted for any of these"; and "alignment_not_unique - reads with more than one reported alignment. These reads are recognized from the NH optional SAM field tag. (If the aligner does not set this field, multiply aligned reads will be counted multiple times.)" As I interpret the documentation, "ambiguous" reads are not counted but "alignment-not-unique" reads are counted multiple times. However, to me it seems like alignment-not-unique reads ARE ambiguous and should therefore be treated the same way. I find it a little disconcerting that one cannot count reads matching repeated genes that occur as few as five times in a genome because this precludes any kind of differential expression analysis. Is there a good reason not to count alignments for multicopy sequences?

[dpryan]

Heh, while the "alignment_not_unique" reads are, indeed, ambiguously mapped, "ambiguous" here has a slightly different meaning that can most easily been seen visually. Basically, "ambiguous" here means it can be assigned to overlapping genes (there are a bunch of those). I can see how that wording can be confusing, though I can't easily think of a better term that could have been used.

Regarding not counting reads mapped to duplicate genes, yeah, that can be an issue. If you're interested in comparing gene families that are highly similar, then you'd need to use a different script (or perhaps the python interface, I've never used it). htseq-count has no way to know that a multi-mapped read maps into a conserved part of a gene family rather than just randomly into a repetitive (or generally low complexity) region.