This PR adds a new spot-based decoding method, the CheckAll decoder, based on the method described here (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6046268/). It is capable of detecting several times more true targets from seqFISH image data than current spot-based methods in starFISH (PerRoundMaxChannel) as barcodes are not restricted to exactly matching spots or only nearest neighbor spots and because it tries to put together barcodes based on spots from every round instead of a single arbitrary anchor round. It is also capable of utilizing error correction rounds in the codebook which current starFISH methods do not consider.

Summary of algorithm:

Inputs: spots - starFISH SpotFindingResults object codebook - starFISH Codebook object filter_rounds - Number of rounds that a barcode must be identified in to pass filters error_rounds - Number of error-correction rounds built into the codebook (ie number of rounds that can be dropped from a barcode and still be able to uniquely match to a single target in the codebook)

1. For each spot in each round, find all neighbors in other rounds that are within the search radius
2. For each spot in each round, build all possible full length barcodes based on the channel labels of the spot's 
neighbors and itself
3. Drop barcodes that don't have a matching target in the codebook
4. Choose the "best" barcode of each spot's possible target matching barcodes by calculating the sum of variances 
for each of the spatial coordinates of the spots that make up each barcode and choosing the minimum distance barcode 
(if there is a tie, they are all dropped as ambiguous). Each spot is assigned a "best" barcode in this way.
    sum( var(x1,x2,...,xn), var(y1,y2,...,yn), var(z1,z2,...,zn) ), where n = # spots in barcode
5. Only keep barcodes/targets that were found as "best" in a certain number of the rounds (determined by filter_rounds
parameter)
6. If a specific spot is used in more than one of the remaining barcodes, the barcode with the higher spatial variance
between it's spots is dropped (ensures each spot is only used once)
(End here if number of error_rounds = 0)
7. Remove all spots used in decoded targets that passed the previous filtering steps from the original set of spots
8. Rerun steps 2-5 for barcodes that use less than the full set of rounds for codebook matching (how many rounds can be
dropped determined by error_rounds parameter)

Tests of the CheckAll decoder vs starFISH's PerRoundMaxChannel method (w/ nearest neighbor trace building strategy) show improved performance with the CheckAll decoder. All the following tests used seqfISH image data from https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6046268/.

Note PRMC NN = PerRoundMaxChannel Nearest Neighbor

The x-axis for each of the above images marks the value for the search radius parameter used in either decoding method (the distance that spots can be from a reference spot and be allowed to form a potential barcode). It is marked in increments of increasing symmetric neighborhood size (in 3D). The left figure shows the total number of decoded transcripts that are assigned to a cell for each method (note: for the CheckAll decoder this includes partial barcodes (codes that did not use all rounds in decoding) which the PerRoundMaxChannel method does not consider). Depending on the search radius, there is as much as a 442% increase in the total number of decoded barcodes for the CheckAll decoder vs PerRoundMaxChannel.

To assess the accuracy of either decoding method, I used orthologous smFISH data that was available from the same samples for several dozen of the same genes as were probed in the seqFISH experiment. Using this data, I calculated the Pearson correlation coefficient for the correlation between the smFISH data and the results from decoding the seqFISH data with either method (note: because the targets in this dataset were introns (see paper) the values that were correlated were the calculated burst frequencies for each gene (how often/fast transcription is cycled on/off) instead of counts). The results of this are shown in the center figure above with the right-hand figure showing the same data but zoomed out to a 0-1 range. The starFISH PerRoundMaxChannel method does achieve a higher accuracy using this test but it is not significant and comes at the cost of detecting far fewer barcodes. (Note: missing values on lower end of x-axis are due to not having enough results to calculate the burst frequency of the transcripts).

Unlike current starFISH methods, the CheckAll decoder is capable of taking advantage of error correction rounds built into the codebook. As an example, say a experiment is designed with a codebook that has 5 rounds, but the codes are designed in such a way that only any 4 of those rounds are needed to uniquely match a barcode to a target, the additional round would be considered an error correction round because you may be able to uniquely identify a barcode as a specific target with only 4 rounds, but if you can also use that fifth round you can be extra confident that the spot combination making up a barcode is correct. This method is based on a previous pull request made by a colleague of mine (https://github.com/ctcisar/starfish/pull/1).

The above figures show similar results to the first figure except the results of the CheckAll decoder have been split between barcodes that were made using spots in all rounds (error correction) and those that only had a partial match (no correction). Even without considering error correction, the CheckAll decoder detects as much as 181% more barcodes than the PerRoundMaxChannel method. The smFISH correlation are as expected with error corrected barcodes achieving a higher correlation score with the smFISH data than those that were not corrected. Whether a barcode in the final DecodedIntensityTable uses an error correction round or not can be extracted from the new "rounds_used" field which shows the number of rounds used to make a barcode for each barcode in the table. This allows easy separation of data into high and lower confidence calls. Additionally, the distance field of the DecodedIntensityTable is no longer based on the intensity of the spots in each barcode but is the value that is calculated for the sum of variances of the list of spatial coordinates for each spot in a barcode. This can also be used as a filter in many cases as barcodes made of more tightly clustered spots may be more likely to be true targets.

The major downside to the CheckAll decoder is it's speed. This is no surprise, as it is searching the entire possible barcode space for every spot from all rounds instead of just nearest neighbors to spots in a single round, but the possible barcode space can become quite large as search radius increases which can significantly increase run times. In order to address this, I've added the ability to multi-thread the program and run multiple chunks simultaneously in parallel using the python module ray, though even with this added parallelization, runtimes for CheckAll are much higher than for PerRoundMaxChannel. The above figure shows the runtime in minutes for the CheckAll decoder (using 16 threads) vs PerRoundMaxChannel with nearest neighbors (note: the seqFISH dataset used here is among the larger that are available at 5 rounds, 12 channels, and over 10,000 barcodes in the codebook so for most other seqFISH datasets I expect runtimes will be considerably less than what is shown here, unfortunately I did not have access to another suitable seqFISH dataset to test on). Ongoing work is being done to optimize the method and bring runtimes down. I was unable to figure out how to correctly add ray to the requirements file so that will still need to be done.

Objective

As a spaceTX data analyst with an experiment that does not have a matching number of rounds and channels, I want starfish to support this data model, so that I can create a starfish benchmarking pipeline

Acceptance Criteria

• Simone can process his data with starfish
• Brian Long can process his data with starfish

Notes

Encapsulates work that needs to be done to support data coming in from Ola, Simone, Brian Long, and presumably RNAscope users

For example, after using Segmentation.Watershed to segment a cell, is there some function that takes the resulting np.ndarray as an input and returns another np.ndarray with the outlines of all segmented cells. This doesn't have to be the exact method; anything similar will do.

I have tried looking around already for something similar, but I haven't been able to find it. If that function doesn't exist yet, I would like to help to write one since I need that function anyway.

Thank you!

Edit: To give some background to this, the reason I want to do this is because I want to detect and count dots that are only contained within cells, so I would use the outlines of cells from Segmentation.Watershed to crop the dots image to only include those outlined areas, and then count dots in those parts of the image. It is entirely possible that there is a function that does that already that I have just not been able to find yet. If that exists yet, please let me know.

Some quick and dirty test code I wrote:

import numpy as np
import xarray as xr

from starfish import IntensityTable

from starfish.core.types import Coordinates, Features
from starfish.core.types._constants import OverlapStrategy
from starfish.core.codebook.test.factories import codebook_array_factory
from starfish.core.intensity_table.test.factories import create_intensity_table_with_coords
from starfish.core.intensity_table.overlap import Area

import matplotlib.pyplot as plt
import matplotlib.patches


def plot_intensity_tables(intensity_table_plot_specs, concatenated_table):
    
    fig, ax = plt.subplots(dpi=500)
    
    for table, color, marker, coord, x_dim, y_dim in intensity_table_plot_specs:
        ax.scatter(table['xc'], table['yc'], facecolors='none', marker=marker, linewidth=0.25, s=15, edgecolors=color)
        rect = matplotlib.patches.Rectangle(coord, x_dim, y_dim, edgecolor='none', facecolor=color, alpha=0.10)
        ax.add_patch(rect)

    ax.scatter(concatenated_table['xc'], concatenated_table['yc'], facecolors='none', marker='^', linewidth=0.25, s=15, edgecolors='black')
        
    fig.tight_layout()


def create_more_realistic_intensity_table_with_coords(area: Area, n_spots: int=10, random_seed=888) -> IntensityTable:
    codebook = codebook_array_factory()
    it = IntensityTable.synthetic_intensities(
        codebook,
        num_z=1,
        height=50,
        width=50,
        n_spots=n_spots
    )
    
    np.random.seed(random_seed)
    it[Coordinates.X.value] = xr.DataArray(np.random.uniform(area.min_x, area.max_x, n_spots),
                                           dims=Features.AXIS)
    it[Coordinates.Y.value] = xr.DataArray(np.random.uniform(area.min_y, area.max_y, n_spots),
                                           dims=Features.AXIS)
    # 'Restore' random seed so downstream usages aren't affected
    np.random.seed()

    return it


def test_take_max_of_multiple_overlaps():
    
    it1 = create_more_realistic_intensity_table_with_coords(Area(min_x=0, max_x=3,
                                                  min_y=2, max_y=5), n_spots=29)
    it2 = create_more_realistic_intensity_table_with_coords(Area(min_x=2, max_x=5,
                                                  min_y=2, max_y=5), n_spots=31)
    it3 = create_more_realistic_intensity_table_with_coords(Area(min_x=0, max_x=3,
                                                  min_y=0, max_y=3), n_spots=37)
    it4 = create_more_realistic_intensity_table_with_coords(Area(min_x=2, max_x=5,
                                                  min_y=0, max_y=3), n_spots=41)
    
    concatenated = IntensityTable.concatenate_intensity_tables(
        [it1, it2, it3, it4], overlap_strategy=OverlapStrategy.TAKE_MAX)


    tables = [it1, it2, it3, it4]
    colors = ['r', 'g', 'b', 'gold']
    markers = ['*', 'D', 's', '*']
    coords = [(0, 2), (2, 2), (0, 0), (2, 0)]
    x_dims = [3, 3, 3, 3]
    y_dims = [3, 3, 3, 3]
    
    plot_intensity_tables(zip(tables, colors, markers, coords, x_dims, y_dims), concatenated)

    
    print(concatenated.sizes[Features.AXIS])

The weird result: Black Triangles = spots in concatenated Other colored shapes = spots associated with a given color quadrant

The center quad overlap area shouldn't have that blue square or yellow star surviving in the concatenated table. Also in the overlap area between yellow and blue, there are two anomalous blue spots that somehow survive the TAKE_MAX process... Finally there is a surviving red star in the overlap between red and green.

Note also that this test code also doesn't even test for when Z-overlaps might occur.

CC: @berl

Hi all,

So I've encountered an issue when running write_experiment_json() in 'no copy' mode (see: https://github.com/spacetx/starfish/pull/1053)

The resulting output .json files that starfish produces all assume that image tiles reside in the experiment root directory (see: https://github.com/spacetx/slicedimage/blob/3456f86a10cc9c89996a394cb75a03457a9bf6bc/slicedimage/io.py#L303).

However, our data (and likely many other group's data) do not live in a flat directory structure. Ours happens to look like:

expt_root_dir
| - Round_1_dir
|    | - FOV_1_dir
|    |   | - channel_1_z_1.tiff
|    |   ...
|    | - FOV_2_dir
|    |   | - channel_1_z_1.tiff
|    |   ...
|    ...
| - Round_2_dir
|   | - FOV_1_dir
|   |    | - channel_1_z_1.tiff
|   |    ...
|   ...
...

Although this issue arises because Starfish can no longer dictate a flat data structure (by forcing copying), copying has to be optional as the overhead of creating a new copy of huge 'local' datasets is unreasonable.

From an end-user perspective, having image data organized into subdirectories is also much easier to deal with than having to deal with one folder with thousands of tiffs.

edit 7.27.18: updated to include prototypes for show_spots (see 5525d9b, 48ba1e7, dd941e2)

Overview

The show_stack tool is really useful for evaluating the images during processing. However, it is very slow and thus difficult to use. I have prototyped a faster way to update images (see the notebook) and proposed a method for speeding up the show_spots as well (see below). Thoughts?

Approach

Faster scrolling The current version in master creates a new imshow() plot each time the slider is adjusted. Recreating the entire plot is very slow, so instead we use the imshow().set_data() to update just the image data. We should be able to make show_stack(). If we need to go faster, we may need to look into a different plotting library (e.g., pyqtgraph).

Faster spots To speed up the spot display, we draw all of the spots on the image (as if they were z projected) before calling interact object. We set all spots to set_visible = False (i.e., make them invisible). Then, when the viewer "scrolls" between slices, toggle the visible property for spots that are members of that frame. We precompute the masks for each slice to speed up the upate function.

Image query cursor tooltop Additionally, note that I use the 'notebook' (as opposed to 'inline') matplotlib magic, which both allows the draw to work and as a bonus gives an image tooltip. The tooltip is super useful because it reads out the coordinates and intensity of the pixel under the cursor (exactly what we were talking about today)!

Questions

• Will the proposed show_spots method generalize to other slicing (i.e., not along z)?
• Is the show_spots responsive enough? We could consider blitting (i.e., only interacting with spots that change state between slices), but it may not be worth the effort.
• What class will be passed to show_spots as the 'results_df'?
• Does it matter what backend (e.g., QtAgg or TkAgg) the user has?

This is an update to my previous PR for a new seqFISH decoding method. We discovered some problems with the method in regards to the false positive rate and have spent the past several months improving it to it's current state and think it is now fit to be published.

So recapping the previous PR, we found that starFISH's seqFISH decoding (PerRoundMaxChannel with NEAREST_NEIGHBOR or EXACT_MATCH TraceBuildingStrategy) was finding far fewer targets in our seqFISH datasets than we were expecting from previous results and the reason for this is the limited search space within which starFISH looks for barcodes. For both TraceBuildingStrategy's, spots in different rounds are only connected into barcodes if they are spatially close to a spot in an arbitrary anchor round which does not utilize the inherent error correction that can be done by comparing the barcodes found using each round as an anchor. Additionally, the EXACT_MATCH TraceBuildingStrategy requires spots in different rounds to be in the exact same pixel location in order to connected into barcodes while NEAREST_NEIGHBOR requires that they be nearest neighbors, which are both extremely sensitive to spot drift between rounds, requiring precise registration that isn't always possible. The PerRoundMaxChannel decoder also lacks the ability to find error-corrected barcodes (in codebook where all codes have at least a hamming distance of 2 each code can still be uniquely identified by a barcode that is missing one round).

To address this, I attempted to write a seqFISH decoding method that emulates the one used by the lab where seqFISH originated at Caltech. In this method, the spots in all rounds are separately used as anchors to search to spots within a search radius of the anchor spots. So for each spot, all the possible barcodes that could constructed using the spots in other rounds within the search radius are considered, which is a much larger search space than when only considering exact matches or nearest neighbors. Each anchor spot is then assigned a "best" barcode out of its total possible set (it "checks all" of the possible barcodes) based on the spatial variance and intensities of the spots that make it up and whether it has a match to codebook, though the order of those steps will vary.

This larger search space requires a few extra tricks to keep false positive calls down. One of these is a filter that removes barcodes that were not found as best for a certain number of the spots/rounds that make it up (usually one less than the total round number) which the Caltech group calls the seed filter. So if we had a 5 round barcode and that barcode was chosen as the best choice for only 3 of the spots that make it up, it would not pass the filter. I've also introduced a parameter I call strictness that sets a maximum number of possible barcodes a given spot is allowed to have before it is dropped as ambiguous. Barcodes in spot dense regions tend to be difficult to call accurately so it is useful to be able to restrict that if necessary. Another trick I found helpful was to run decoding in multiple nested stages that start off with stricter parameters which are loosened as decoding progresses. This includes the search radius (starts off with radius 0 and increments up to the user-specified value), the number of rounds that can be omitted from the barcode to make a match (only looks for full codes first then looks for partials) and the max allowed score (based on spatial variance and intensity of spots). Between each decoding, the spots that were found to be in decoded barcodes that pass all filters are removed from the original spot set before decoding the remaining spots. This allows you to call high confidence barcodes first and remove their spots, making calling adjacent barcodes easier. Running the whole decoding process repeatedly became quite time consuming so I have added in multiprocessing capability to allow users to speed things up using Python's standard multiprocessing library.

In addition to the filters and incremental decoding I also take advantage of two slightly different decoding algorithms with different precision/recall properties. In one method, which I call "filter-first", once all the possible barcodes for each spot are assembled, the "best" barcode for each spot is chosen based on a scoring function that uses the spatial variance of the spots and their intensities. The chosen barcodes are then matched to the codebook and those that have no match are dropped. The other method, called "decode-first", instead matches all the possible barcodes for each spot to the codebook first and then if there are multiple matches the best is chosen based on the distance score. The "filter-first" method tends to be higher accuracy but return fewer decoded targets (high precision/low recall) while the "decode-first" method finds more mRNA targets but at a cost to accuracy (low precision/high recall). In keeping with my incremental decoding strategy I described earlier, the first set of decoding is done using the high accuracy "filter-first" method followed by decodings done using the low accuracy version.

Below is a description of the required inputs and a step by step explanation of the algorithm.

Inputs:

• spots - starFISH SpotFindingResults object
• codebook - starFISH Codebook object
• search_radius - pixel distance that spots can be from each other and be connected into a barcode
• error_rounds - number of rounds that can be dropped from each code and still allow unique barcode matching (only values are 0 or 1 are currently allowed)
• mode - accuracy mode, determines settings of several different parameters ("high", "med", or "low")
• physical_coords - boolean for whether to using the physical coordinate values found in the spots object for calculating distance between spots or use pixel coordinates

Steps

1. For each spot in each round, calculate a scaled intensity value by dividing the spot's intensity by the l2 norm of all the spots found in the same channel and same 100 radius pixel neighborhood.
2. For each spot in each round, find all neighboring spots in different rounds within the search radius.
3. From each spot and their neighbors, build all possible combinations of spots that form barcodes using their channel labels.
4. Choose a "best" barcode for each spot using the scoring function and drop barcodes that don't have codebook matches (this is for the filter-first method and is switched for decode-first).
5. Drop barcodes that were not found as best for most of the spots that make it up (usually one less than the round total).
6. Choose between overlapping barcodes (barcodes that share spots) using their scores.
7. Remove spots found in passing barcodes from original spot set. (2-7 is repeated, first using the filter-first method for each incremental radius and then using the decode-first method for each radius)
8. One final decoding is done if error_rounds parameter > 0, where partial barcodes are allowed. Uses filter-first method and strict parameters as the barcodes it finds are more error prone than full barcodes.
9. Turn overall barcode set into DecodedIntensityTable object and return

One final detail worth explaining here is the mode parameter. This parameter can take three values: "high", "med", or "low" and essentially simplifies a number of parameter choices into these three presets including the seed filter value at the end of each decoding step, the max allowed score allowed for a barcode, and the strictness value for the filter-first and decode-first methods. "high" corresponds to high accuracy (lower recall), "low" corresponds to low accuracy (higher recall), and "med" is a balance between the two.

To evaluate the results of our decodings and compare them with starFISH methods, we used two different kinds of qc measures. The first is correlation with orthogonal RNA counts (either smFISH or RNAseq) and the other is the proportion of false positive calls measured by placing "blank" codes in the codebook that adhere to the hamming distance rules of the codebook but don't actually correspond to any true mRNA. This false positive metric was lacking from my previous PR and when we ran it on the previous method our false positive values were quite high. Depending on the method used to calculate the false positive rate and the specific dataset, high false positive rates can be a problem with seqFISH data but the mode parameter allows you to easily adjust the decoding parameters to get the best results.

Below are some figures showing results from 3 different seqFISH datasets comparing the starFISH PerRoundMaxChannel + NEAREST_NEIGHBORS method with each mode choice for the CheckAll decoder. Each red/blue bar pair along the x-axis represent a single cell, FOV, or image chunk (don't have segmented cells yet for this dataset so it is broken into equal sized chunks), while the height of the blue bar represents the total number of on-target (real) barcodes found in that cell/fov/chunk and the red bar height is the off-target count (blank) with the black bar showing the median on-target count. Also printed on each graph is the overall false positive (FP) rate and the pearson correlation with smFISH or RNAseq where available. For each dataset the same set of spots was used for each run.

Intron seqFISH

• Mouse ESC lines
• 10,421 real genes + ~9,000 blank genes
• 29 (close) z slices
• This was the most difficult of the three datasets to get good results from. The large number of genes and close by z slices make finding true barcodes tricky.

RNA SPOTs seqFISH

• No cells, just extracted RNA on a slide
• 10,421 real genes + ~9,000 blank genes
• single z slice
• Pretty easy dataset as there was no cellular autofluorescence

Mouse Atlas seqFISH

• slices of mouse hippocampus
• 351 real genes, 351 blanks
• 6 (distant) z slices
• Lower false positives than intron seqFISH probably from the lower gene count and distant z slices reducing confusion. Not sure why starFISH does so poorly here though but the FP rate is almost 3x the low accuracy rate for the new decoder.

From these, you can see that this updated decoder is capable of finding more targets than starFISH, with lower false positive rates, and higher smFISH/RNAseq correlations. The one area where the starFISH methods have us beat is speed. Being more thorough is costly so while starFISH can decode a set of spots in 2-3 minutes on my system, this new decoder can take up to 1.5 hours even when using 16 different simultaneous processes. That time is from the intron seqFISH dataset which is quite large (5 x 12 x 29 x 2048 x 2048) so the run times are more reasonable for smaller datasets.

Running the "make all" tests for my current repo throws a mypy error but in code that I haven't touched (like the ImageStack class code) so hopefully we can work together to get those kinks worked out so we can add this to starFISH so others might use it.

What does this PR do?

This PR is a prototype of using the Napari GUI for viewing detected spots overlayed on an ImageStack. The Napari GUI is still an early prototype, so it does have some bugs/brittle parts, but the performance for viewing spots on 3D volumes is way better than current notebook-based solutions.

There are some more usability updates coming to the Napari GUI (e.g, constrast sliders) that will definitely improve UX. However, the API should remain the same in the near term, so show_spots_napari() will still work.

Demo

To try the viewer, first pip install --upgrade napari-gui and then open test_napari.ipynb in the notebooks directory. This demos the Allen Institute smFISH notebook using the Napari viewer. The notebook loads a saved version of the 3D spot detection (allen_decoded) from the notebook directory for convenience (spot detection takes a while). We will nuke this after initial testing.

Open questions

• Where should this function go? I also noticed that there is a stub for a show_spots() method in IntensityTable. Maybe it should go there?
• Is there an easy to way to tell what type of image the spot attributes come from (e.g., 3D stack, MIP)? It would be nice to be able to automatically choose the type of projection of the 5D ImageStack to use for the display.
• Noob question: how do I get a full r, c, z, x, y coordinate for a given feature in IntensityTable?

Is your feature request related to a problem? Please describe.

We are using Nikon microscopes and in each round (out of more than 10) of our experiment we have ~80 GB of data in .nd2 format. We are using nd2 files as we originally didn't want to lose any metadata.

Describe the solution you'd like I was hopping to have a support for nd2 files to make json files (and single frame .tiff files) directly from .nd2 files.

Describe alternatives you've considered In order to write the json file what we do for now is to convert all files from nd2 to single frame tiff format that have channel-label and z-level in their filenames so it could be used by `get_tiel()' and later make a formatted folder containing all the frames and json files. Very suboptimal specifically dealing with this large volume.

Additional context I wish there were no need for starfish to save frames in its own format and separately from the original stack. This feature will save more than few TBs for each of our animals ...

-- and sorry if I posted few issues/feature requests in a row!

Remaining work includes:

1. Running this tool against all raw data
2. Uploading formatted data to cloud
3. Using experiment API against this dataset to test parsing larger datasets

If *.py.skip exists, then that notebook is skipped.

See https://travis-ci.org/spacetx/starfish/builds/389071632 for a run when .travis.yml is set to look for a different branch name.

Bumps setuptools from 58.1.0 to 65.5.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps setuptools from 58.1.0 to 65.5.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps certifi from 2022.6.15 to 2022.12.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps certifi from 2022.6.15 to 2022.12.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps pillow from 9.1.1 to 9.3.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps pillow from 8.3.2 to 9.3.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.