fixed toc

docs/tutorials/lite.ipynb

@@ -10,7 +10,7 @@
     "\n",
     "While that makes scarlet a powerful tool for a wide range of astronomical data analysis, quite often the data that we are working with is much more uniform. In many (most?) cases users have data from a single instrument that has been reprojected onto a common WCS in all bands to make multi-color photometric images. Further, if the user is modeling a large area of the sky, there is likely to be less customization of models and a simple bulge-disk model like the scarlet `ExtendedSource` model with a small number of components is sufficient. When you can assume that the data is all in the same bounding box, at the same resolution, and you have models with gradients that you can calculate analytically, using `scarlet.lite` as opposed to baseline `scarlet` is likely to run several times faster using an order of magnitude less memory. This tutorial wll describe how to use `scarlet.lite` and outline some of the differences between creating, fitting, and visualizing scarlet lite models as opposed to baseline scarlet.\n",
     "\n",
-    "# Design\n",
+    "## Design\n",
     "\n",
     "The overal design of scarlet lite is significantly different than baseline scarlet. In the main module, scarlet was designed to be hierarchical, with `scarlet.model.Model` as the base class that all of the other models are constructed from. This design is beneficial for users that have a wide variety of very complicated models and makes it efficient to use an automatic gradient code like [autograd](https://github.com/HIPS/autograd) to optimize over a wide variety of parameters.\n",
     "\n",

docs/tutorials/multiscale_deblending.ipynb

@@ -146,7 +146,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "# Vanilla scarlet lite\n",
+    "## Vanilla scarlet lite\n",
     "\n",
     "We first use the standard scarlet lite code to measure both the runtime and overall -logL (smaller is better):"
    ]
@@ -189,7 +189,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "# Using wavelets to calculate the loss function\n",
+    "## Using wavelets to calculate the loss function\n",
     "\n",
     "Using scarlet lite it is fairly straight-forward to update the loss function of the entire model so that instead of calculating the residuals of the model wrt the data in real space, it calculates the starlets (undecimated isotropic wavelets) for the model in each iteration, and compares the residuals of each wavelet scale separately. The idea was that this would be able to supress the high frequency spikes that are seen in the scarlet deconvolved models, but unfortunately it does not appear to work and gives _slightly_ worse results with slightly higher as vanialla scarlet with a higher runtime. 😞"
    ]
@@ -248,7 +248,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "# Use source models with wavelet coefficients\n",
+    "## Use source models with wavelet coefficients\n",
     "\n",
     "The second test is to use a model for each source that contains wavelet coefficients, where the blend updates the coefficients at each scale with their residuals. The algorithm is similar to Starck et al. 2011 for calculating positive wavelet coefficients, the main difference being that we model each source (set of positive coefficients) separately, using the standard scarlet assumption that each component has a consistent color. However, in this case we allow that color to be different at each wavelet scale.\n",
     "\n",
@@ -551,13 +551,6 @@
     "\n",
     "display_multiresolution_residuals(images, mask, blend)"
    ]
-  },
-  {
-   "cell_type": "code",
-   "execution_count": null,
-   "metadata": {},
-   "outputs": [],
-   "source": []
   }
  ],
  "metadata": {