Bioconductor 3.22 is being released on October 21, 2025. Among bug fixes, this release will include some useful additions to Cardinal for MSI, specifically the addition of contrast testing for linear models. I added this and wanted to detail some of my thoughts and decisions below.
Some real quick background: I do statistical analysis of mass spectrometry imaging (MSI) data. Basically the stuff after the data are collected, preprocessed, and ROIs selected - like modeling and hypothesis testing. In order to make population-level statements from a sample of MSI images (e.g., “on average, exposure to this drug increases the abundance of this analyte”) you have to specify the relationships using a statistical model and use them to estimate the signal and variance. MSI data have many sources of variance so we need multiple samples (biological replicates). Also to make statements about the population effect from our sample we need models that specify what we think is happening (linear models), a way to test the signal we observe (the effect) against the noise of the effect (the variance), and an empirical way to compare that signal-to-noise ratio (a t statistic) to what we would expect to see based on random chance alone (a p value). You have probably done this - it’s a t test1.
A contrast specifies a specific comparison from a statistical model using the model parameters. Let’s go back to the t test as an example. Take a two sample t test comparing the average of treatment vs control.
\[\frac{\bar{Y}_{Treatment}-\bar{Y}_{Control}}{\sqrt{\frac{2\sigma^2}{n}}} \sim t_{df}\]This test actually assumes a linear model beneath it - or a one-way ANOVA (it’s all the same math).
\[Y_i = \beta_0 + X_i\beta_1 + \epsilon_i \text{ where } \epsilon_i \overset{iid}{\sim} N(0,\sigma^2)\]Rewritten in a more friendly way:
\[\displaylines{ Y_i = \text{Mean Y for Control} + X_i(\text{Mean difference of Y between control and treatment}) + \text{Error}_i \\\ \text{where } X_i = 0 \text{ for control, or } 1 \text{ for treatment} }\]A contrast is a set of coefficients that usually sum to 0, and correspond to model parameters. In abstract, it’s how we go from the fitted model to a specific estimate. For the t test above, comparing the difference between treatment and control, the contrast would be \((0,1)\) and the estimate being \((0\times\beta_0 + 1\times\beta_1)\) where \(\beta_0\) is the average response of the control and \(\beta_1\) is the average difference between the control and treatment, both from the fitted model. Follow me?
Now for a simple example, the two sample t test and the contrast with a linear model are the same. The real magic happens when you have multiple independent variables, levels of each variable, sources of variation (like random factors in a mixed-effects model), and interactions. The contrast also specifies how to compute the variance of the estimate. I’ve heard this referred to as “propagating error” for people familiar with GraphPad Prism, and, in essence, it lets you piggyback off of the explanatory power of the other variables, random effects, and interactions to get a more precise estimate of variance.
1In the purest form, a t test is a signal-to-noise ratio. A special case is a two sample t test or a paired t test where the signal is the difference of two means and the ratio is the pooled variance.
Cardinal::meansTest() did and does do differential analysis, depending on exactly what difference you are trying to analyze. meansTest() computes mean intensity for each feature and sample then fits linear models, with stats::lm() or nlme::lme() when a random effect is specified. meansTest() then performs a likelihood ratio test (LRT) against a reduced model, defaulting to ~ 1. The interpretation of this test changes a lot depending on the context, but in general an LRT compares a full and reduced model to test if the full model explains significantly more variation than the reduced. In this use case, an LRT is equivalent to an F test - and if you are testing a model with only a single fixed effect with two levels, it’s equivalent to a two sample t test. But beyond that situation (testing a single fixed effect) LRTs quickly become less useful if your goal is to test differential abundance. For one thing, you don’t get estimates of the effect - just if it’s significant. Also you can’t test individual factor levels.
So instead let’s t test (signal to noise ratio remember?) contrasts of interest. Now how to do that… you could, of course, extract the fitted models from the MeansTest result object and run the tests yourself. This is fine for models without random effects that use lm but nlme::lme models don’t check for singularity (in this case, most often when subject/biological variation is too small to estimate) and offer a primitive method of degrees of freedom computation. Is that a big deal? Maybe - probably not if you’re doing something simple - but might as well compute means within Cardinal and use lme4::lmer() on the FeatureData frame pulled from every sample, seeing as how you already have to run the contrasts yourself anyway. lme4::lmer() lets you know when the models are singular so you can check for (then ignore :sunglasses:) zero subject-level variance and lmerTest offers a method for Satterthwaite approximation of the degrees of freedom. Contrast testing can be done with emmeans. It’s complex, but if nothing else, emmeans’s wide adoption yields many examples of its usage with different research questions and experimental designs.
But in my experience, most Cardinal users are experimentalists, not computer scientists or statisticians, and won’t or can’t do the extra steps above because they are too complicated. It makes sense - we all have our areas of expertise and no one can be specialized in everything. So since I have this expertise, and the need is clear (at least to me), I decided to add contrast testing to Cardinal.
Running contrasts in Cardinal is relatively straightforward. All MSI samples need to be in the same MSImagingExperiment object, and pixels from each sample identified using a factor in the PositionDataFrame, usually the run. Independent variables must be specified in the same way. Then it’s pretty simple - first, run meansTest with your preferred specification setting use_lmer = TRUE. Then feed the results into contrastTest, specifying the contrasts using specs and method args. These pretty much map directly to specs arg of emmeans::emmeans() and the method arg of emmeans::contrast. Exactly how to specify these depends on your hypotheses of interest, but as I mentioned above emmeans has extensive documentation, vignettes, and examples. Or just ask ChatGPT, with appropriate skepticism. Cardinal::topFeatures will do FDR correction, the very important final step. I’m finishing up a paper about this, available very soon, that will include code and workflows for you to use with your data.
Although I am a relatively competent scientific programmer (I write code to do science pretty well) that is not the same as being a good software engineer… We all hate on vibe coding (god I hate that word) and all its cringy etymological children (search LinkedIn for “vibe coding cleanup specialist” to see truly the most uninspired people), but in their narrow and well confined lane I found Windsurf, Cursor, and GitHub Copilot to be very useful. It helped me plan, answered questions about Cardinal and its existing repository, and frankly “thought” of stuff I would have missed. My expertise actually came with testing - I know how these models work and what the results should be. I have used Cardinal a lot and I know how I want it to behave. I can create realistic test data for each scenario and I had already implemented the non-Cardinal version of this process from above.
Now onto some interesting technical details in no particular order. Upon conference with Kylie (my colleague and the creator of Cardinal), we decided to keep nlme::lme() and simply add lme4::lmer(), specified with the use_lmer arg. Why? First we wanted the LRT to behave exactly the same as it always has. lme4 and nlme are relatively interchangeable with mostly esoteric differences, but their estimators are not exactly the same so they don’t produce the exact same answers. Better to keep the old way around in case someone out there relies on LRTs. Second, nlme supports some interesting additions, such as Matérn covariance structures that could let us specify pixel-level models that overcome the biasing effect of pixel autocorrelation inherent to MSI data. In the same vein, I decided not to implement LRT testing with lme4::lmer() models. lme4 offers both maximum likelihood estimation (MLE) and restricted maximum likelihood estimation (REML - I know but it’s convention). MLE generally underestimates variance, especially at small sample sizes whereas REML is generally considered unbiased (see this). Unfortunately, LRTs with REML-estimated parameters must have the same fixed effects, rendering them useless for our purposes. As MSI experiments often have few (if any) replicates, in my opinion, it’s more important to use REML than it is to offer LRTs.
Going forward, I think my contributions to Cardinal will focus on filling usability gaps. Contrast testing seemed to be the largest hole in the end to end workflow of differential analysis - but there are others, mostly small and avoidable, but a few (deisotoping) that still need to be remedied with external packages. Excited for the future.
]]>Northeastern PHI does things a little differently from the traditional qualifying exam - hence this public post detailing each qualifying exam component.
The research described in the technical and health components differs greatly from the work in the research core and my current research. Three years into my studies my first advisor Dr. Dinesh John left Northeastern to pursue work in health policy and physical activity in government and I joined Olga Vitek’s lab. One way to frame this is I went from applying statistical models to activity data to applying statistical models to mass spectrometry imaging data with through lines of statistics, programming, biology, and experimental design. I’m glad I have a diverse set of professional interests and scientific experiences. :microscope:
Examiner: Dr. Dakuo Wang
Date of completion: May 23, 2024
Description of exam topic: In 2023, Diego Arguello, Dinesh John, and I concluded the Companion Pilot Study on the use of activity-informed real-time interventions to increase physical activity in adults, identifying that these interventions do work but required buy-in and relationship building between the participants and health coaches (see O.3.11). High quality health coaching is labor and time intensive, thus a barrier to scaling these types of real-time interventions. At the time (2023), large language models (LLMs) were starting to mature into useful tools that had the potential to automate some amount of routine messaging and interaction. For my exam I designed an AI health coaching system, Companion2, for use by human health coaches to expand their reach and productivity as well as a comprehensive evaluation plan to test its efficacy and safety. This work was submitted as a predoctoral fellowship training grant (F31) in the December 8th, 2023 NIH grant cycle and resubmitted the following year with changes for the August 8th, 2024 cycle.
Examiner and reason for selection: Dr. Dakuo Wang, an Associate Professor with joint appointments in the Khoury College of Computer Sciences and the College of Arts, Media, and Design has a lot of experience working with AI systems for health. Before this project, I worked with one of his students on a project studying how smart-speaker voice assistants can help patients share information with their care teams. His collaborative style and our shared interest in using LLMs for health applications led me to ask him to be a sponsor on the F31 and proctor this exam.
Structure and reason for selection: A grant submission requires extensive research, planning, and iteration. Technological systems must be thoroughly detailed as well as their evaluation; all justified by and based on previous research. Resubmissions (as was the case for our August 8, 2024 submission) must integrate feedback and address weaknesses from reviewers, as well as incorporate novel technologies from a rapidly advancing field. I used this process to demonstrate my technical design capabilities all while gaining valuable grant writing experience.
Unfortunately, neither submission was funded, but the process was valuable.
Examiner: Dr. Dinesh John
Date of completion: September 23, 2024
Description of exam topic: Motivational Interviewing (MI) is an evidence-based therapeutic technique used by practitioners to help clients make behavior changes, specifically around health. The process of MI is to establish a trusting relationship with a client, explore the benefits and barriers of the behavior change of focus, cultivate the client’s internal motivation, and support the client when they take action and implement behavior change. This process requires practitioners to respect and foster the client’s self-efficacy and self-determination, withhold judgment, avoid confrontation, and refrain from giving unsolicited advice. MI requires a soft touch; moving between asking open-ended questions, redirecting conversation from unproductive topics, summarizing and reflecting, and affirming the client’s experiences. MI was the core approach used in the health coaching conducted as part of the Companion trial to promote physical activity in older adults and in the F31 grant application based on the data collected from Companion trial, as detailed above in the technical component. At the time, it was highly relevant to my future research.
Examiner and reason for selection: My advisor at the time, Dr. Dinesh John was an associate professor in the department of Public Health and Health Sciences at Northeastern University’s Bouvé College of Health Sciences. His research focused on the measurement of physical behavior and developing technological interventions to promote behavior change and health. Dinesh also has background in behavior change and health interventions. We had planned to build an AI system based on the Companion work that would use MI to promote physical activity therefore I asked him to administer my exam. Dinesh believes that practical experience was the best way to learn, thus we collaboratively selected this course.
Structure and reason for selection: Using MI to promote behavior change not only requires the study of the philosophy and approach behind MI, but the opportunity to practice MI techniques. Doing a course in MI as the health component, specifically UMass Chan Medical School’s Certificate in Intensive Motivational Interviewing, offered me the opportunity to practice MI and receive coaching and evaluation from MI practitioners. The course took four months and had ten two-hour group meetings where students were taught the theory, principles, and practice of MI. Students had ten learning assignments with quizzes, two mock-patient interviews to practice their MI skills, and two coaching sessions with MI practitioners to evaluate their performance. Upon successful completion of the course, students received a certificate of completion.
Examiner: Dr. Olga Vitek
Date of completion: very soon
Current status: As of 4/8/26, on BioRxiv and submitted to Analytical Chemestry
Title: Statistical Principles Define an Open-Source Differential Analysis Workflow for Mass Spectrometry Imaging Experiments with Complex Designs: A Case Study of Osteoarthritis
Author list and affiliations: Ethan B T Rogers1, Sai Srikanth Lakkimsetty1, Kylie Ariel Bemis1, Charles A Schurman2, Peggi M Angel3, Birgit Schilling2, Olga Vitek1
1Khoury College of Computer Sciences, Northeastern University, Boston MA
2Buck Institute for Research on Aging, Novato CA
3Department of Pharmacology and Immunology, Medical University of South Carolina, Charleston SC
Abstract: Mass spectrometry imaging (MSI) characterizes the spatial heterogeneity of molecular abundances in biological samples. Experiments with complex designs, involving multiple conditions and multiple samples, provide particularly useful insight into differential abundance of analytes. However, analyses of these experiments require attention to details such as signal processing, selection of regions of interest, and statistical methodology. This manuscript contributes a statistical analysis workflow for detecting differentially abundant analytes in MSI experiments with complex designs. Using a case study of histologic samples of human tibial plateaus from knees of osteoarthritis patients and cadaveric controls, as well as simulated datasets, we illustrate the impact of the analysis decisions. We illustrate the importance of signal processing and feature aggregation for preserving biological relevance and alleviating the stringency of multiple testing. We further demonstrate the importance of selecting regions of interest in ways that are compatible with differential analysis. Finally, we contrast several common statistical models for differential analysis, showcase the appropriate use of replication, and demonstrate model-based calculation of sample size for followup investigations. The discussion is accompanied by detailed recommendations and an open-source R-based implementation that can be followed by other investigations.
Link:
Journal: Analytical Chemistry, part of the American Chemical Society. From their website:
Analytical Chemistry publishes compelling research articles advancing chemical measurement science from significant fundamentals to innovative applications.
Some stats (from 2025):
Vignettes of the workflow developed as part of this work:
Statement from examiner, Dr. Olga Vitek, on the role of myself and each author: coming soon
Date of presentation to PHI group: coming soon
Other details: This work has been previously presented in posters at two conferences, ASMS (2025) and IMSIS3 (2025). Reprints available upon request.
Courses:
CS7200: Statistical Methods for Computer Science, Fall 2023, Dr. Olga Vitek
CS4950: Computer Science Research Seminar, Spring 2024, Dr. Olga Vitek
CS3950: Introduction to Computer Science Research, Spring 2024, Dr. Olga Vitek
On meeting the teaching requirement: As part of being an assistant for multiple courses, I have certainly accumulated more than three hours of teaching experience. My duties for CS7200 were mostly holding office hours - roughly two hours each week - where I supplemented Olga’s lectures, explaining statistical concepts in multiple ways, going over example problems for homework and tests, helping students formulate analysis plans for their projects, and answering questions students had about the course and grading. Office hours were well attended, and I spent the vast majority of time teaching statistics - most often reviewing the lecture material with the students and helping them with homework problems. Aside from holding office hours, I created and edited homework assignments; reviewed, proctored, and graded exams; and answered student questions on Piazza among other administrative duties. CS4950 and CS3950 were both 1-2 credit courses that I TA’d for simultaneously. TAing for these courses was more administrative due to the structure of the course - creating and grading homework, reviewing and offering feedback on project proposals, grading final project papers, and keeping track of participation and attendance. For several sessions, I was the sole instructor, taking attendance, moderating discussions, and lecturing.
On challenges, benefits, and take-aways: I was a TA in college for several lab courses. My experience in grad school was roughly similar and didn’t generate any particularly noteworthy challenges. Administration is tedious, providing feedback takes a lot of time, things that seem clear or obvious (class policies, assignment instructions, rubrics, etc.) aren’t more often than I would expect, and objective grading (or as close to it as can be managed by a fallible human like myself) is a lot of work. TAing a stats course was really helpful for my own understanding of the material. I’ve always been “good” at math per se, but in CS being “good” at math is the baseline and statistics is like math but with opinions. But nothing requires you to thoroughly flesh out your own understanding more than trying to teach it to someone else. Also, any ego that in the past might have prevented me from saying “I’m not actually sure” has been brutally and mercilessly sanded off.
I end this with things I have learned from TAing, in no particular order. I enjoy teaching, though much like grant writing I don’t really want it to be part of my career. Slowing down, trying a new approach, or reframing the problem are helpful ways to unstick someone’s lack of understanding. Students who are good at troubleshooting (know the system, define the problem, isolate components) are also good at teaching themselves. I made a bunch of friends TAing. Your class isn’t always someone’s priority, so have a comprehensive syllabus and best not to take it personally. For so many reasons, I’m so glad I didn’t have access to ChatGPT when I was a student.
Example assignments:
An example homework (with solutions) for CS7200 created based on previous assignments covering similar topics. An example of a weekly assignment for CS3950 also created by me based on previous years’ examples.
➜ ➜ ➜ ➜ ➜ Onwards to candidacy ➜ ➜ ➜ ➜ ➜
]]>