You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
following #220, we have a use case with reads coming out of the sequencer in both orientations. We do several cleaning steps including primer trimming with cutadapt using --revcomp to look for primers in both orientations. However, we would like to output reads in the original orientations, so as to not modify this information and be able to use it in our downstream analyses. Is this something that could be considered in a future version?
Thanks a lot in advance!
Leonor
The text was updated successfully, but these errors were encountered:
leonorpalmeira
changed the title
Allow -revcomp to output original orientation reads
Allow --revcomp to output original orientation reads
Apr 19, 2023
Hi, thanks for the suggestion. I won’t have time to implement this soon, but it is definitely something to consider.
I wonder how one would write this on the command line. Perhaps --revcomp=original would work. Or just --revcomp=yes or so and the current --revcomp would be a shorthand for --revcomp=normalize (as suggested in #220).
@marcelm Thanks for your comment. You probably want to keep backwards compatibility so you could have --revcomp pointing to --revcomp=normalize by default and then have an extra --revcomp=original option to keep the original version of the read orientation. That would be great for our use case with NGS amplicons where we want to use the read orientation proportions as part of our internal quality control metrics.
Dear cutadapt,
following #220, we have a use case with reads coming out of the sequencer in both orientations. We do several cleaning steps including primer trimming with
cutadapt
using--revcomp
to look for primers in both orientations. However, we would like to output reads in the original orientations, so as to not modify this information and be able to use it in our downstream analyses. Is this something that could be considered in a future version?Thanks a lot in advance!
Leonor
The text was updated successfully, but these errors were encountered: