Tweet
I want to run HTSeq on count number of mapped mRNA reads on Human genes (GENCode GTF file). However, I have to modify this gtf file because I want to allow a search region of an offset of -200 bp upstream of each gene. I think I need to add exon of length 200bp to each gene, so, HTSeq can count the reads that overlap such regions. Do you know if there is some script (code) which can do that?
-
-
Just extend the bounds of each exon #1. I'm not aware of a premade script to do this, but you could write one in python or R (import the GTF as a GRanges object, split by transcript, and apply an appropriate function) easily enough. -
Thank you very much @dpryan. I think I will write this code. I guess it is simple but needs more careful analysis. This is because we need to check for each gene (or transcript) if the new upstream region will not hit any upstream gene. If such case happens, then we need to shrink the upstream region accordingly. Is this right? or we let genes overlap with each other (then HTSeq will identify reads as ambiguous)Comment
-
There's no reason to shrink regions if they overlap another gene. If you're going to grow a genes extent and that causes an overlap then so be it. Having a few more ambiguous alignments in such cases is a non-problem.Comment
-
Thanks @dpryan. I agree with you that we do not need to shrink, however, I suggested this to avoid eliminating reads from being counted by HTSeq count. Actually, I do not like the ambiguity approach in HTSeq count because it artificially changes the way the expression count is defined. I just posted a question about this.Comment
-
There's nothing artificial about how htseq-count handles that. It's the correct solution for the downstream analyses for which it's intended.Comment
-
I agree with you if you mean that HTSeq-count is intended to generate expression matrix for detection of differentially expressed genes. Unfortunately, this is just one single applications, while, many applications need expression matrix that reflect the actual expression mechanism. Please correct me if you think this is not true and/or not accurate.Comment
-
Correct and there's no need to bother modifying htseq-count when there are so many existing tools that are intended for those purposes.Comment
-
Thanks very much @dpryan for your replies and the suggestionsComment
-
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.07-01-2026, 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