Closed mestaki closed 5 years ago
This would just save the user from having to re-import their reverse reads separately.
Is this really a burden though? Correct me if I'm wrong, but to achieve this, the user just has to import the reverse reads as if they were forward reads, and then run denoise-single
. My initial reaction is that seems straightforward enough for the edge case of reverse reads >> forward reads.
You're certainly right that it is very straightforward and it totally would be a convenience thing only in the case of using the manifest importing. Currently I would import paired-end reads and make a decision about which reads to use after looking at the quality score plots. If I wanted to use both reads or forwards only, no problem, I carry on with denoise-single/paired. If I wanted the reverse reads however, I would have to remake the manifest file to either switch the forwards with reverse labels or include the reverse reads only, then re-import. It's no priority to be sure, just saves an extra step in the case of reverse reads.
Actually the SingleEnd types don't care if they are forward or reverse. It should be possible to simply drop the forward rows from the manifest and re-import as SingleEnd. They will be recorded as being the reverse direction, but no tooling actually cares.
If that doesn't work, then I think we should make it work better, since that's going to be a lot easier than working out a way to pass parameters to transformers.
(Right now denoise-single handles paired-end reads because there's a transformer in q2-types to convert paired-end to single-direction, where that transformer assumes you're more interested in the forward reads since it is being invoked at all.)
In some rare cases where the reverse reads are of better overall quality than the forwards, it would be convenient to be able to direct denoise-single to process the reverse reads instead of the default forward. This would just save the user from having to re-import their reverse reads separately.