I have implemented another alternative quantificat...
# riboseq
s
I have implemented another alternative quantification method for Ribo-seq reads. Details here in case anyone has capacity to review: https://github.com/nf-core/riboseq/pull/141
j
I think this needs someone with a better view of the science than me. Incidentally, I'm not sure if this comment:
Copy code
I meant to add a test for this new quantification method, but the inputs to the module are not deterministic to begin with which means the outputs aren't either, making a test rather pointless.
... relates to the discussion above, but we can set seeds for testing specifically via test-specific nextflow.config files. Let me know if you need a hand.
s
This comment was only incidentally related. Following your examples I know in principle how to set RNG seed parameters for the tests. But it think the tool that is to blame in my case (salmon) does not have such a parameter.
👍 1
t
> ... the outputs aren't either, making a test rather pointless. Can you have a test and ignore the content of the outputs, but focus on the fact that they were actually produced (without error)? I'm also very annoyed that a tool like Salmon that is basically counting cannot be forced to be deterministic ... The rounded outputs should be mostly the same, but perhaps not completely in every case.
j
The only issue with this idea is that it ties counts to periodicity. This will make the counts useful within sample but not between samples because the proportion of reads we expect to see in frame 0 of the CDS will change with this property
i
just thought i'd mention riboWaltz also outputs this type of files: • `*.cds_coverage_psite.tsv`: TSV file with CDS P-site in-frame counts for each transcript • `*nt_coverage_psite.tsv`: TSV file with CDS P-site in-frame counts for each transcript, excluding P-sites within defined distances to start and stop codons (defined by passing
--exclude_start
and
--exclude_stop
with the number of nucleotides). I know some people use these P-site counts, but I prefer to use all counts and use periodicity mostly as a QC metric when appropriate (e.g. RNase I libraries). I agree with Jack that this property will be sample-dependent, so not really comparable. Maybe it would be more comparable for all samples within the same experimental run 🤔
s
> • `*.cds_coverage_psite.tsv`: TSV file with CDS P-site in-frame counts for each transcript > • `*nt_coverage_psite.tsv`: TSV file with CDS P-site in-frame counts for each transcript Are you sure only in-frame p-sites are counted? Initially, I though so, too, but then I found this issue on GitHub, which led me to conclude otherwise.
i
well, their docs claim so "CDS and transcript coverage
cds_coverage
computes the number of P-sites mapping on annotated coding sequences or whole transcripts. Such data can be used as starting point for downstream quantitative analyses (e.g. differential analyses) based on ribosome protected fragments. By default, only in-frame P-sites falling in annotated coding sequences are considered and no nucleotides at the beginning or at the end of the CDSs are excluded for restricting the analysis to a portion of the original coding sequences. These settings can be modifyed through the parameters _in_frame_, _start_nts_ and _start_nts_. Moreover, the parameter _whole_transcript_ specifies if whole transcripts should be considered instead of the annotated coding sequence. The basic command
Copy code
cds_coverage_example <- cds_coverage(reads_psite_list, mm81cdna)
" https://github.com/LabTranslationalArchitectomics/riboWaltz so if this is not correct, they need to fix their docs accordingly. made a note, but I am afraid I do not have capacity in the next few weeks to chase this...
s
I will investigate this ...
i
wait a second
the issue you posted is related to
codon_coverage
not
cds_coverage
function
so we're fine, there's no issue here
riboWaltz works as expected, and the docs are fine, no need to chase
of course, if you wish, you can go into the functions and check if they work as expected, but in my experience with riboWaltz, I think the
cds_coverage
function does indeed only count in-frame P-sites
s
Yes, I can confirm.
cds_coverage
counts only in-frame P-sites (see code here), whereas
codon_coverage
does not. The cds_coverage file should thus be equivalent to my PR, with the difference being that one is based on RiboWaltz and the other on Plastid.
This will make the counts useful within sample but not between samples because the proportion of reads we expect to see in frame 0 of the CDS will change with this property
@Jack Tierney Would you argue that this is fundamentally different than any other bias that is inherent to a sample, thus making inter-sample comparisons pointless? The same argument could be made about RNA-seq samples having different biases. No RNA-seq sample will ever be like the next one, even if they are prepared in the same batch. Yet, it is common practice to group them together and perform differential expression analysis. Would you say this is not valid for Ribo-seq data?
One idea behind counting in-frame p-sites is to identify overlapping ORFs shifted by only one or two bases. This may be a microprotein-specific question, which is where the idea comes from, and not applicable to a wider Ribo-seq audience.
j
I do think it is fundamentally different because its basically incorporating the bias directly into the feature count calculation. Other technical biases are mostly independent of the biological signal we are trying to measure but this is directly implicated. Definitely not to say its a wholely bad idea. Lets just make sure we are very clear what assumptions we are making about library properties if we are going to expose the option of differential translation analysis with these counts to users. Most ORF callers are already doing this so I am not sure what value will be added by providing these counts for that purpose Relative quantification of two overlapping translated regions would be very useful but developing that is probably a research project of its own.
s
because its basically incorporating the bias directly into the feature count calculation. Other technical biases are mostly independent of the biological signal
I see. That makes sense. It depends on the biological question then I guess. If your experiment impacts periodicity, then I agree it's a bad idea to use these counts. If your question is unrelated to periodicity (e.g., quantifying novel ORFs), then you should be fine?
Most ORF callers are already doing this
Can you kindly give me a pointer to where to find this info? In the outputs of Ribotish, the counts column is all 0. In the output of Ribotricer, there are counts, but the tool also counts out-of-frame reads as far as I can tell from the source code.
j
All ribo-seq will have variable periodicity though? and anything that tries to do anything frame specific will be sensitive to that. That just needs to be communicated clearly I took
identify overlapping ORFs
to mean annotation of novel translated regions. If you are just talking about quantifying things you have already annotated then this is what I referred to in my third paragraph. Unfortunately it is not as simple as just counting in frame reads. For example, imagine two overlapping translons, A and B, where half of A overlaps B. A is translated by 5% of ribosomes and B by the remaining 95%. If periodicity is 70% in-frame, then the majority of the in-frame counts assigned to A are actually likely to come from bleed-through of the much more highly translated B rather than from true translation of A itself.
s
All ribo-seq will have variable periodicity though?
Much like RNA-seq will have variable sequencing depth and other QC metrics. Or am I missing something?
j
No you are correct. I probably unfairly zero'd in on "If your experiment impacts periodicity"
i
I still think it depends. The key case is when the experimental condition itself can plausibly shift periodicity or frame-assignment across samples (e.g., harringtonine time-courses, stress/drug treatments that alter initiation/elongation dynamics, or anything that perturbs footprint length distributions). The difference from typical RNA-seq QC is that a lot of RNA-seq technical variation (depth, duplication, GC bias, etc.) mainly affects how well you observe the underlying signal, and we usually don’t define the count by applying a sample-specific “biological-looking” pass/fail gate (rather, tools like salmon model these biases rather than hard-gating). We might also drop a catastrophically bad sample, but we’re not typically saying “only count reads that pass property X,” where X could systematically differ by condition. With Ribo-seq in-frame P-site counts, we are explicitly doing that: a within-sample filter whose pass rate can vary across samples/conditions. It’s affected by (i) which read lengths are retained, (ii) any periodicity/length thresholding during P-site calling, and (iii) frame-assignment accuracy. If frame calling is imperfect, true frame-0 signal can leak into apparent frame 1/2, and that leakage rate can differ between samples. So I’m not saying inter-sample comparisons are invalid, just that in-frame-only counting effectively makes “frame-0 capture efficiency” part of the measurement. Differential analysis then implicitly assumes the fraction of true signal that lands in called frame 0 is stable across samples. That assumption feels more fragile to me in Ribo-seq than the usual RNA-seq QC assumptions, especially in experiments expected to perturb periodicity. I am still not opposed to this approach, we just need to be aware of some of the assumptions.
s
Thank you all for this insightful input. I have circled this back to colleagues and am collecting feedback. In any case, I will amend the documentation, i.e., remove the mention of the use case for overlapping ORFs and explicitly warn about biologically founded biases which would become distorted by this counting method. I will report back in a few days.
From the feedback I have received from colleagues, I have understood that this method of counting is mostly relevant to the study of non-canonical ORFs coding for microproteins. They agree that the issues that you brought up in this Slack conversation complicate the interpretation, but they say the quantification is useful in the context of microproteins nonetheless. I have amended the documentation to reflect this specialized use case and also pointed out the caveats associated with the method. The warnings should safeguard against misuse of the method. With these warnings in place, would you feel more comfortable incorporating the feature into the pipeline?
j
Hi Sebastian, thanks for following up with them. Would it be possible for a brief summary of why they like this quantification? I am happy to have it included with the caveats once reviewed
n
Hi Jack, Sorry for not coming back to you earlier. I will work on a brief summary and come back to you shortly.
Hi Jack, Regarding the frame restricted quantification: In the context of the non-canonical translatome, frame is far more than a QC metric—it is the defining feature of the biological signal. While standard total-count methods are robust for well-separated canonical CDSs, they collapse the frame dimension, making them fundamentally incapable of distinguishing the overlapping ORFs that characterize the hidden landscape of the dark proteome. The primary justification for this method is its unique ability to distinguish between multiple translation events occurring on the same transcript. In the non-canonical translatome, we frequently encounter: • Overlapping ORFs: Dual-coding regions where one sequence translates two different proteins in different frames (e.g., a canonical protein in frame 0 and a microprotein in frame +1). • Upstream and Downstream Overlapping ORFs (uoORFs and doORFs): Which physically overlap with the boundaries of the main CDS. • Internal ORFs: Microproteins encoded entirely within the sequence of a larger CDS but in a different reading frame. Without frame-specific P-site counting, the signal from a highly translated canonical protein would mask the signal of a lowly translated overlapping microprotein. By restricting quantification to the fixed in-frame position (Frame 0) relative to each specific ORF, we apply a biological filter that isolates the relevant translation from the surrounding 'noise' of other reading frames This approach is not a fringe methodology; it is a specialized tool used by researchers specifically to gain the resolution needed for microprotein discovery and quantification. Landmark papers identifying thousands of novel ORFs—such as van Heesch et al. (2019, Cell), Hofman et al. (2024, Mol Cell) , and Ruiz-Orera, J., et al. (2024, Nat Cardiovasc Res)—rely on frame-restricted quantification.
Technical Note: Assumptions and Limitations of Frame-Specific Counting While frame-0 P-site quantification is essential for resolving overlapping or non-canonical ORFs, users must account for "frame-0 capture efficiency" when performing inter-sample comparisons. Unlike standard RNA-seq counts, which are largely independent of transcript structure, frame-specific counts are sensitive to the global periodicity of the library. If an experimental condition or library preparation method alters the distribution of ribosome footprints (e.g., changing the ratio of in-frame to out-of-frame reads), the resulting changes in counts may reflect shifts in P-site assignment accuracy rather than true changes in translational output. This is particularly relevant in treatments that perturb ribosome movement, such as elongation inhibitors or cellular stress, which can "blur" the 3-nucleotide periodicity and lead to signal leakage between frames. To mitigate these risks, it is strongly recommended to use this quantification method in conjunction with rigorous periodicity QC metrics (such as those provided by
riboWaltz
or
multiqc
). If the percentage of in-frame P-sites varies significantly between experimental groups, differential expression results should be interpreted as a composite of translational regulation and frame-occupancy shifts. For studies focused on microproteins or overlapping ORFs, this method remains the most viable path to signal isolation; however, users should validate that their findings are not artifacts of capture efficiency by verifying that global frame distribution remains stable across the compared biological replicates.
Let me know what you think please. Thank you!
j
Hey Naiara, Thank you for such a thorough reply! Its very clear and I appreciate the biological motivation and why it has been used extensively to date. I never meant to block this from getting merged and maybe I'm being overly pedantic anyway but the sake of discussion... My remaining concern is that taking only in-frame counts doesn’t truly separate translation of a given feature from signal arising from overlapping translated regions. The observed P-site counts for a translated region effectively become: Observed in-frame counts = True in-frame translation + bleed-through from overlapping frame(s) If a highly translated region overlaps a lowly translated one in a different frame, even modest frame leakage (e.g. imperfect periodicity or frame assignment) could mean that a substantial fraction of the in-frame counts assigned to the low translon originate from the higher one. So while frame-restricted counting increases resolution compared to total counts, it doesn’t fully isolate translation in the way the framing might suggest. Anyway, lets push ahead with getting this merged
n
Hey Jack! Thanks for the thoughtful pushback! I’ve actually really appreciated you challenging the framework—it’s in the true spirit of the community and keeps the code high-quality. I mean it. I totally acknowledge the limitation regarding overlapping frames; even with P-site assignment, it's not a perfect 'isolation' of the signal. I definitely see this as 'Phase 2. I’d love to dive deeper into developing a more robust deconvolution method as a research project down the road.
s
Shall we proceed with the merging then? https://github.com/nf-core/riboseq/pull/141
f
just fyi, Jon is on leave this week. Happy to approve the PR, let me know
j
Just submitted a review. Nothing major in it
thankyou 2
i
I added a comment on the docs and a question
thankyou 1
hi, I am on annual leave and wont be able to review the changes to this PR. i'd highly encourage a review from a maintainer, maybe Jon is available now?
f
@Jonathan Manning, are you? 😛
j
Happy to review it from the engineering side, others here better placed on the science obviously
Reviewed. Main thing is that I think the looping within the new process should be delegated to nextflow for scalability.
s
@Jack Tierney You probably did not get the GitHub notification. Could you kindly re-review/approve the PR (https://github.com/nf-core/riboseq/pull/141) now that Jonathan has reviewed it and all his improvement suggestions have been implemented? Thanks!
j
Agh no I did not. Sorry Sebastian. On my To Do list now