Tweet
Those aren't raw counts, they're estimated raw counts.
Hint: don't try to coerce cufflinks data into DESeq.
Hint: don't try to coerce cufflinks data into DESeq.
-
-
So, you saw that since these are estimated raw counts and they are coming from cufflinks which are infact considering noise for duplicate read counts as well. However for DESeq we donot consider the duplicate read counts right? For DESeq each counting unit is evidence of one sequencing read. So we should not consider this estimated raw count and rather generate the raw count using HT-Seq for my data and then use them for DESeq analysis? Is that what you want to mean?Comment
-
The validity of the statistical model used by DESeq depends on its input being integer read counts directly from individual samples. Trying to use anything else will just produce unreliable results.
So yes, use htseq-count to generate your count matrix.Comment
-
Love this - good data definitely starts from good input, and poor input can only give relatively poor data. I particularly like the mention of Nanodrop/absorbance based methods for quantification. It's such a toss up if you'll get an accurate reading or what amounts to a randomly generated number, and a lot of library/sequencing related issues can be traced back to poor quant.Yesterday, 11:43 AM
-
I’m not a sequencing expert. I’m a purification scientist who uses NGS to evaluate workflows my group develops. With this perspective, we think about the sample first and the NGS workflow second. The sequencer is an exceptionally honest reporter, but it can only report on what you give it, so whether you get clean, interpretable data from an NGS workflow is largely determined before you begin.
Here are nine questions we think about, in roughly the order they matter, before...
Comment