DEXSeq vs htseq-count/DESeq counting model

[jdsv]

Okay, thanks for the reply. I will stick with generating separate count tables.

[Simon Anders]

Your analysis is correct. This is why we still have two script and recommend not using dexseq_count.py to produce input for DESeq. Maybe we should put a more explicit warning about this in the help page for 'geneCountTable' (or, better, simply remove this function; it was only an experimental one anyway that serves little purpose in DEXSeq).

[jdsv]

I have found DESeq very useful and am giving DEXSeq a spin. After reading through the DEXSeq vignette, I thought the most efficient path would be to do read counting with the included 'dexseq_count.py' script, use the output for DEXSeq analysis, and then use the 'geneCountTable' function to get per-gene counts for DESeq.

I already have counts tables for some of these replicates generated using 'htseq-count' with the union model. A quick look through the 'dexseq_count.py' source suggests that it also uses the same union model, so I did some quick comparisons to make sure the results were consistent. However, the number of counts generated for each gene by 'htseq-count' are usually less than the sum of the exon counts generated by dexseq_count.py for the same dataset.

It appears that when reads are split over exon boundaries, 'dexseq_count.py' includes the read in each exon count. This results in a summed read count for the gene that is higher than the actual number of reads mapping to it. As far as I can tell, 'geneCountTable' simply sums up the exon counts, and so its per-gene output for genes with spliced mapped reads with be artifically high.

I'm wondering if Simon or the other authors of DEXSeq and DESeq (or anyone else) has any input on this?

Thanks,
Jeremy