<p>I haven't used these long-read RNA-seq tools so I could be wrong here. Transcript reconstruction combines reads from the same transcript and should be robust to partial transcripts. In addition, Nanopore direct RNA-seq produces a lot of partial transcripts. I tend to believe many transcript reconstruction tools can deal with them.</p>
<p>As to what tool to use, <a href="https://github.com/gpertea/stringtie" rel="nofollow noreferrer">StringTie</a> is a popular one and has been shown to be better than Flair. <a href="https://github.com/ablab/IsoQuant" rel="nofollow noreferrer">IsoQuant</a> seems promising. Its developers <a href="https://www.researchsquare.com/article/rs-1571850/v1" rel="nofollow noreferrer">argued</a> it is more accurate than StringTie, Bambu, Talon and Flair. Squanti only works for iso-seq.</p>

CC BY-SA 4.0
2022-11-14T15:01:39.223Z
2022-11-14T15:01:39.223Z
user172818
<p>You could have a go using LAST. I've been developing and using a protocol for mapping cDNA reads that is based around LAST-mapping since 2017. The most recent RY model addition in LAST seems to clean up the majority of the random gene counting noise issues that we were having.</p>
<p>See the gene counting part of the protocol here. If you're working from direct/native RNA rather than cDNA (or don't care about strand-specific mapping), then the strand correction in previous steps is not needed:</p>
<p><a href="https://dx.doi.org/10.17504/protocols.io.5qpvonn2bl4o/v17" rel="nofollow noreferrer">https://dx.doi.org/10.17504/protocols.io.5qpvonn2bl4o/v17</a></p>

CC BY-SA 4.0
2022-11-14T11:53:49.947Z
2022-11-14T11:53:49.947Z
gringer
<p>What will be the best tool to call isoforms from long read data generated from partially degraded RNA. By mistake we processed some samples with poor quality RNA to generate long read. Now we are looking for some tool which can merged the reads for the potential degraded transcripts. I think majority of the available tools like Squanti, Talon, bamboo, flair considered independent read as full length. Do the community has any suggestions?</p>
<p>Thanks</p>

<rna-seq><assembly><long-reads><isoform>
Calling isoforms from long read data generated from partially degraded RNA
# Calling isoforms from long read data generated from partially degraded RNA

(Asked by: username_0 on 2022-11-13)

What will be the best tool to call isoforms from long read data generated from partially degraded RNA. By mistake we processed some samples with poor quality RNA to generate long read. Now we are looking for some tool which can merged the reads for the potential degraded transcripts. I think majority of the available tools like Squanti, Talon, bamboo, flair considered independent read as full length. Do the community has any suggestions?

Thanks

**Tags:** rna-seq, assembly, long-reads, isoform

---

## 2 answers

### Answer by username_1 on 2022-11-14. Score: 2

I haven't used these long-read RNA-seq tools so I could be wrong here. Transcript reconstruction combines reads from the same transcript and should be robust to partial transcripts. In addition, Nanopore direct RNA-seq produces a lot of partial transcripts. I tend to believe many transcript reconstruction tools can deal with them.

As to what tool to use, [StringTie](https://github.com/gpertea/stringtie) is a popular one and has been shown to be better than Flair. [IsoQuant](https://github.com/ablab/IsoQuant) seems promising. Its developers [argued](https://www.researchsquare.com/article/rs-1571850/v1) it is more accurate than StringTie, Bambu, Talon and Flair. Squanti only works for iso-seq.


---

### Answer by username_2 on 2022-11-14. Score: 1

You could have a go using LAST. I've been developing and using a protocol for mapping cDNA reads that is based around LAST-mapping since 2017. The most recent RY model addition in LAST seems to clean up the majority of the random gene counting noise issues that we were having.

See the gene counting part of the protocol here. If you're working from direct/native RNA rather than cDNA (or don't care about strand-specific mapping), then the strand correction in previous steps is not needed:

<https://dx.doi.org/10.17504/protocols.io.5qpvonn2bl4o/v17>


---

