refactor ccf_plots

[tmchartrand]

• make some methods private
  • anything not currently imported, others?
  • remove plot_raster_region
• simplify palette handlng
  • switch to edge/face palettes?
• remove polygon options
  • remove for now, maybe later Tom will create a separate module and match signatures, so they could be imported and dropped back in in the future
• plot_ccf_overlay
  • could move much of logic to a 'preprocess dataframe' method (Tom will tackle this)
  • probably also need to generate a palette here before moving to section-level plots
• tentative goals
  • make plot_ccf_overlay and plot_expression use as much shared code as possible
  • same for plot_metrics_ccf_section and plot_ccf_section_raster

[meghanaturner]

I'm working off of the ccf_plots_refactor_mt branch

[meghanaturner]

reminder to self: as I adjust function names, need to Find+Replace all instances in notebooks. Same for argument changes, but that will take more legwork to update across all notebooks

[meghanaturner]

Progress as of today, commit 12cf04e97e8bc3fa7d14788c1c5528f359715a7d on branch ccf_plots_refactor_mt

• make some methods private
  • anything not currently imported, others?
  • remove plot_raster_region
• simplify palette handling
  • switch to edge/face palettes?
• remove polygon options
  • remove for now, maybe later Tom will create a separate module and match signatures, so they could be imported and dropped back in in the future

[meghanaturner]

Next steps for modularizing to increase shared code amongst plot_xxxx functions:

• add per-section functions to plot cells/points, colored by: (a) continuous/numeric variables from a col of a df, and (b) categorical variables from a col of a df
• plot_expression() function as a specialized wrapper for easy access to a common use case of (a), which mostly just handles moving the gene expression data from adata.X into adata.obs in order to be able to just use (a) like it's any other numeric variable

[meghanaturner]

as I'm cleaning up the "view_XXX" notebooks, I've noted that the custom_xy_lims parameter in most ccf_plots functions will likely not be useful for generating new custom plots once we split thalamus_merfish_analysis modules off into their own package because it requires a user to know the exact xy positions of the feature you'd like to highlight BUT we've shut off the axes via _format_image_axes() so you can't see that info

I was getting around this by manually commenting out the lines that turned off the axes, but that won't be an option when it's an installed

I see a few options, I'd lean towards (1) but as a "nice-to-have" before release:

1. Add another user parameter, show_axes={default=False, True}, to all top-level plotting functions that is passed through to _format_image_axes() to allow users to turn the axes back on. Once they have their bounding box, they can turn it back off to make their figures look pretty again
2. Have a set of pre-calculated bounding boxes for each nucleus (set of nuclei? this could get big quickly ...) and have a parameter that allows a user to specify zooming in on a particular nucleus for their plot
3. Ignore this issue, rendering custom_xy_lims usable only if you know what you want to plot or via guesswork on the lims, which will likely limit use cases to internal power users

[meghanaturner]

Before release, we should switch the default values of the following parameters to reflect the ABC Atlas standard column names:

• section_col='z_reconstructed'
• x_col='x_reconstructed'
• y_col='y_reconstructed'
• ccf_label='parcellation_substructure'

Right now, each view_xxx demo notebook has to include 1-2 extra cells at the top of the notebook to set those variables and then we have to explicitly specify them in each and every plotting function call.

Would be helpful to be able to clean that all up.