diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 6f63089fcdc57cf171b643805652a961de54f634..a4f67c3d3ef0ab81888ebe1367595dbf1f3242ed 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,5 +1,5 @@
-Contributing to VTK
-===================
+Contributing
+============
 
 This page documents at a very high level how to contribute to VTK.
 Please check our [developer instructions] for a more detailed guide to
diff --git a/Documentation/Doxygen/ArrayDispatch-VTK-7-1.md b/Documentation/Doxygen/ArrayDispatch-VTK-7-1.md
index 23ff0acc7b1c1d0c96cb454e78bdcd915ad2a2ca..ce867f7a56605c2d184bf71b34160c69290a2134 100644
--- a/Documentation/Doxygen/ArrayDispatch-VTK-7-1.md
+++ b/Documentation/Doxygen/ArrayDispatch-VTK-7-1.md
@@ -1,7 +1,9 @@
 @page VTK-7-1-ArrayDispatch vtkArrayDispatch and Related Tools
 @tableofcontents
 
-# Background # {#VTKAD-Background}
+# vtkArrayDispatch and Related Tools
+
+## Background # {#VTKAD-Background}
 
 VTK datasets store most of their important information in subclasses of
 `vtkDataArray`. Vertex locations (`vtkPoints::Data`), cell topology
@@ -9,7 +11,7 @@ VTK datasets store most of their important information in subclasses of
 (`vtkFieldData::Data`) are the dataset features accessed most frequently by VTK
 algorithms, and these all rely on the `vtkDataArray` API.
 
-# Terminology # {#VTKAD-Terminology}
+## Terminology # {#VTKAD-Terminology}
 
 This page uses the following terms:
 
@@ -32,7 +34,7 @@ __Template explosion__ refers to a sharp increase in the size of a compiled
 binary that results from instantiating a template function or class on many
 different types.
 
-## vtkDataArray ## {#VTKAD-vtkDataArray}
+### vtkDataArray ## {#VTKAD-vtkDataArray}
 
 The data array type hierarchy in VTK has a unique feature when compared to
 typical C++ containers: a non-templated base class. All arrays containing
@@ -66,7 +68,7 @@ void calcMagnitude(vtkDataArray *vectors, vtkDataArray *magnitude)
 }
 ```
 
-## The Costs of Flexiblity ## {#VTKAD-TheCostsOfFlexiblity}
+### The Costs of Flexiblity ## {#VTKAD-TheCostsOfFlexiblity}
 
 However, this flexibility comes at a cost. Passing data through a generic API
 has a number of issues:
@@ -91,7 +93,7 @@ such as vectorization.
 So what can one do if they want fast, optimized, type-safe access to the data
 stored in a `vtkDataArray`? What options are available?
 
-## The Old Solution: vtkTemplateMacro ##  {#VTKAD-vtkTemplateMacro}
+### The Old Solution: vtkTemplateMacro ##  {#VTKAD-vtkTemplateMacro}
 
 The `vtkTemplateMacro` is described in this section. While it is no longer
 considered a best practice to use this construct in new code, it is still
@@ -199,7 +201,7 @@ ValueType, but now we have to ensure this, since we cast both arrays' `void`
 pointers to `VTK_TT`*. What if vectors is an array of integers, but we want to
 calculate floating point magnitudes?
 
-## vtkTemplateMacro with Multiple Arrays ## {#VTKAD-Dual-vtkTemplateMacro}
+### vtkTemplateMacro with Multiple Arrays ## {#VTKAD-Dual-vtkTemplateMacro}
 
 The best solution prior to VTK 7.1 was to use two worker functions. The first
 is templated on vector's ValueType, and the second is templated on both array
@@ -266,7 +268,7 @@ the final worker function would be generated. As more arrays are considered,
 the need for some form of restricted dispatch becomes very important to keep
 this template explosion in check.
 
-## Data Array Changes in VTK 7.1 ## {#VTKAD-Changes-in-VTK-71}
+### Data Array Changes in VTK 7.1 ## {#VTKAD-Changes-in-VTK-71}
 
 Starting with VTK 7.1, the Array-Of-Structs (AOS) memory layout is no longer
 the only `vtkDataArray` implementation provided by the library. The
@@ -301,7 +303,7 @@ buffer operations. And while we're at it, let's look at removing the tedium of
 multi-array dispatch and reducing the problem of 'template explosion'. The
 remainder of this page details such a system.
 
-# Best Practices for vtkDataArray Post-7.1 # {#VTKAD-BestPractices}
+## Best Practices for vtkDataArray Post-7.1 # {#VTKAD-BestPractices}
 
 We'll describe a new set of tools that make managing template instantiations
 for efficient array access both easy and extensible. As an overview, the
@@ -385,7 +387,7 @@ void calcMagnitude(vtkDataArray *vectors, vtkDataArray *magnitude)
 }
 ```
 
-# vtkGenericDataArray # {#VTKAD-vtkGenericDataArray}
+## vtkGenericDataArray # {#VTKAD-vtkGenericDataArray}
 
 The `vtkGenericDataArray` class template drives the new `vtkDataArray` class
 hierarchy. The ValueType is introduced here, both as a template parameter and a
@@ -402,7 +404,7 @@ There are two main subclasses of `vtkGenericDataArray`:
 `vtkAOSDataArrayTemplate` and `vtkSOADataArrayTemplate`. These implement
 array-of-structs and struct-of-arrays storage, respectively.
 
-# vtkTypeList # {#VTKAD-vtkTypeList}
+## vtkTypeList # {#VTKAD-vtkTypeList}
 
 Type lists are a metaprogramming construct used to generate a list of C++
 types. They are used in VTK to implement restricted array dispatching. As we'll
@@ -456,7 +458,7 @@ option `VTK_DISPATCH_SOA_ARRAYS` will enable SOA array dispatch as well. More
 advanced possibilities exist and are described in
 `VTK/Common/Core/vtkCreateArrayDispatchArrayList.cmake`.
 
-# vtkArrayDownCast # {#VTKAD-vtkArrayDownCast}
+## vtkArrayDownCast # {#VTKAD-vtkArrayDownCast}
 
 In VTK, all subclasses of `vtkObject` (including the data arrays) support a
 downcast method called `SafeDownCast`. It is used similarly to the C++
@@ -525,7 +527,7 @@ void DoSomeAction(vtkAbstractArray *array)
 the ArrayType, and otherwise falls back to `SafeDownCast`. This is the
 preferred array downcast method for performance, uniformity, and reliability.
 
-# vtkDataArrayAccessor # {#VTKAD-vtkDataArrayAccessor}
+## vtkDataArrayAccessor # {#VTKAD-vtkDataArrayAccessor}
 
 Array dispatching relies on having templated worker code carry out some
 operation. For instance, take this `vtkArrayDispatch` code that locates the
@@ -694,7 +696,7 @@ Using the above pattern for calling a worker and always going through
 `vtkDataArrayAccessor` to `Get`/`Set` array elements ensures that any worker
 implementation can be its own fallback path.
 
-# VTK_ASSUME # {#VTKAD-VTK_ASSUME}
+## VTK_ASSUME # {#VTKAD-VTK_ASSUME}
 
 While performance testing the new array classes, we compared the performance of
 a dispatched worker using the `vtkDataArrayAccessor` class to the same
@@ -752,7 +754,7 @@ There are many scenarios where `VTK_ASSUME` can offer a serious performance
 boost, the case of known tuple size is a common one that's really worth
 remembering.
 
-# vtkArrayDispatch # {#VTKAD-vtkArrayDispatch}
+## vtkArrayDispatch # {#VTKAD-vtkArrayDispatch}
 
 The dispatchers implemented in the vtkArrayDispatch namespace provide array
 dispatching with customizable restrictions on code generation and a simple
@@ -760,12 +762,12 @@ syntax that hides the messy details of type resolution and multi-array
 dispatch. There are several "flavors" of dispatch available that operate on up
 to three arrays simultaneously.
 
-## Components Of A Dispatch ## {#VTKAD-ComponentsOfADispatch}
+### Components Of A Dispatch ## {#VTKAD-ComponentsOfADispatch}
 
 Using the `vtkArrayDispatch` system requires three elements: the array(s), the
 worker, and the dispatcher.
 
-### The Arrays ### {#VTKAD-TheArrays}
+#### The Arrays ### {#VTKAD-TheArrays}
 
 All dispatched arrays must be subclasses of `vtkDataArray`. It is important to
 identify as many restrictions as possible. Must every ArrayType be considered
@@ -774,7 +776,7 @@ restricted? If dispatching multiple arrays at once, are they expected to have
 the same ValueType? These scenarios are common, and these conditions can be
 used to reduce the number of instantiations of the worker template.
 
-### The Worker ### {#VTKAD-TheWorker}
+#### The Worker ### {#VTKAD-TheWorker}
 
 The worker is some generic callable. In C++98, a templated functor is a good
 choice. In C++14, a generic lambda is a usable option as well. For our
@@ -824,7 +826,7 @@ struct FindMax
 };
 ```
 
-### The Dispatcher ### {#VTKAD-TheDispatcher}
+#### The Dispatcher ### {#VTKAD-TheDispatcher}
 
 The dispatcher is the workhorse of the system. It is responsible for applying
 restrictions, resolving array types, and generating the requested template
@@ -847,7 +849,7 @@ interest. If it finds a match, it calls the worker's `operator()` method with
 the properly typed arrays. If no match is found, it returns `false` without
 executing the worker.
 
-## Restrictions: Why They Matter ## {#VTKAD-RestrictionsWhyTheyMatter}
+### Restrictions: Why They Matter ## {#VTKAD-RestrictionsWhyTheyMatter}
 
 We've made several mentions of using restrictions to reduce the number of
 template instantiations during a dispatch operation. You may be wondering if it
@@ -883,7 +885,7 @@ to 104 instantiations from 17,576.
 Always apply restrictions when they are known, especially for multi-array
 dispatches. The savings are worth it.
 
-## Types of Dispatchers ## {#VTKAD-TypesOfDispatchers}
+### Types of Dispatchers ## {#VTKAD-TypesOfDispatchers}
 
 Now that we've discussed the components of a dispatch operation, what the
 dispatchers do, and the importance of restricting dispatches, let's take a look
@@ -891,7 +893,7 @@ at the types of dispatchers available.
 
 ---
 
-### vtkArrayDispatch::Dispatch ### {#VTKAD-Dispatch}
+#### vtkArrayDispatch::Dispatch ### {#VTKAD-Dispatch}
 
 This family of dispatchers take no parameters and perform an unrestricted
 dispatch over all arrays in `vtkArrayDispatch::Arrays`.
@@ -916,7 +918,7 @@ vtkArrayDispatch::Dispatch::Execute(array, worker);
 
 ---
 
-### vtkArrayDispatch::DispatchByArray ### {#VTKAD-DispatchByArray}
+#### vtkArrayDispatch::DispatchByArray ### {#VTKAD-DispatchByArray}
 
 This family of dispatchers takes a `vtkTypeList` of explicit array types to use
 during dispatching. They should only be used when an array's exact type is
@@ -977,7 +979,7 @@ MyDispatch::Execute(input, output, someWorker);
 
 ---
 
-### vtkArrayDispatch::DispatchByValueType ### {#VTKAD-DispatchByValueType}
+#### vtkArrayDispatch::DispatchByValueType ### {#VTKAD-DispatchByValueType}
 
 This family of dispatchers takes a vtkTypeList of ValueTypes for each array and
 restricts dispatch to only arrays in vtkArrayDispatch::Arrays that have one of
@@ -1026,7 +1028,7 @@ MyDispatch::Execute(array1, array2, array3, someWorker);
 
 ---
 
-### vtkArrayDispatch::DispatchByArrayWithSameValueType ### {#VTKAD-DispatchByArrayWithSameValueType}
+#### vtkArrayDispatch::DispatchByArrayWithSameValueType ### {#VTKAD-DispatchByArrayWithSameValueType}
 
 This family of dispatchers takes a `vtkTypeList` of ArrayTypes for each array
 and restricts dispatch to only consider arrays from those typelists, with the
@@ -1083,7 +1085,7 @@ MyDispatch::Execute(array1, array2, someWorker);
 
 ---
 
-### vtkArrayDispatch::DispatchBySameValueType ### {#VTKAD-DispatchBySameValueType}
+#### vtkArrayDispatch::DispatchBySameValueType ### {#VTKAD-DispatchBySameValueType}
 
 This family of dispatchers takes a single `vtkTypeList` of ValueType and
 restricts dispatch to only consider arrays from `vtkArrayDispatch::Arrays` with
@@ -1135,9 +1137,9 @@ MyDispatch::Execute(array1, array2, someWorker);
 
 ---
 
-# Advanced Usage # {#VTKAD-AdvancedUsage}
+## Advanced Usage # {#VTKAD-AdvancedUsage}
 
-## Accessing Memory Buffers ## {#VTKAD-AccessingMemoryBuffers}
+### Accessing Memory Buffers ## {#VTKAD-AccessingMemoryBuffers}
 
 Despite the thin `vtkGenericDataArray` API's nice feature that compilers can
 optimize memory accesses, sometimes there are still legitimate reasons to
@@ -1199,7 +1201,7 @@ struct DeepCopyWorker
 };
 ```
 
-# Putting It All Together # {#VTKAD-PuttingItAllTogether}
+## Putting It All Together # {#VTKAD-PuttingItAllTogether}
 
 Now that we've explored the new tools introduced with VTK 7.1 that allow
 efficient, implementation agnostic array access, let's take another look at the
diff --git a/Documentation/Doxygen/DataAssembly.md b/Documentation/Doxygen/DataAssembly.md
index 4e0a581b751312411cca64c15fefebb3803c7755..9cd2d733ad2aa97874108c81c780f721af721220 100644
--- a/Documentation/Doxygen/DataAssembly.md
+++ b/Documentation/Doxygen/DataAssembly.md
@@ -4,7 +4,7 @@ VTK 10.0 introduces a new mechanism for representing data hierarchies
 using vtkPartitionedDataSetCollection and vtkDataAssembly. This document
 describes the design details.
 
-# Data Model
+## Data Model
 
 The design is based on three classes:
 
@@ -14,7 +14,7 @@ The design is based on three classes:
 * `vtkDataAssembly` defines the hierarchical relationships between items in a
   `vtkPartitionedDataSetCollection`.
 
-## Partitioned Dataset
+### Partitioned Dataset
 
 `vtkPartitionedDataSet` is simply a collection of datasets that are to be
 treated as a logical whole. In data-parallel applications, each dataset may
@@ -27,7 +27,7 @@ a `vtkPartitionedDataSet` comprises of `vtkDataSet` subclasses, all will have
 exactly the same number of point data/cell data arrays, with same names, same
 number of components, and same data types.
 
-## Partitioned Dataset Collection
+### Partitioned Dataset Collection
 
 `vtkPartitionedDataSetCollection` is a collection of `vtkPartitionedDataSet`.
 Thus, it is simply a mechanism to group multiple `vtkPartitionedDataSet`
@@ -40,7 +40,7 @@ between each items, partitioned-datasets, in the `vtkPartitionedDataSetCollectio
 Thus, in the multiblock-dataset parlance, each item in this collection can be thought
 of as a block.
 
-## Data Assembly
+### Data Assembly
 
 `vtkDataAssembly` is a means to define an hierarchical organization of items in a
 `vtkPartitionedDataSetCollection`. This is literally a tree made up of named nodes.
@@ -66,7 +66,7 @@ supports a mechanism to iterate over all nodes in depth-first or breadth-first
 order using a *visitor*. vtkDataAssemblyVisitor defines a API that can be
 implemented to do custom action as each node in the tree is visited.
 
-# Design Implications
+## Design Implications
 
 1. Since `vtkPartitionedDataSet` is simply parts of a whole, there is no specific significance
    to the number of partitions. In distributed pipelines, for example, a `vtkPartitionedDataSet`
diff --git a/Documentation/Doxygen/IOLegacyInformationFormat.md b/Documentation/Doxygen/IOLegacyInformationFormat.md
index 8684557bab7c7a69d1136dff9186e9535a87ce0c..8d489ee37a120d907217cfbefe8b5576795d1f49 100644
--- a/Documentation/Doxygen/IOLegacyInformationFormat.md
+++ b/Documentation/Doxygen/IOLegacyInformationFormat.md
@@ -1,14 +1,16 @@
 @page IOLegacyInformationFormat VTK Legacy Reader/Writer Information Format
 @tableofcontents
 
-# Overview #
+# VTK Legacy Reader/Writer Information Format
+
+## Overview
 
 The legacy vtk data file readers / writers store certain `vtkInformation`
 entries that are set on `vtkAbstractArray`'s `GetInformation()` object. Support
 is currently limited to numeric and string information keys, both single- and
 vector-valued. Only the information objects attached to arrays are encoded.
 
-# Array Metadata Blocks #
+## Array Metadata Blocks
 
 A block of metadata may immediately follow the specification of an array.
 Whitespace is permitted between the array data and the opening `METADATA` tag.
@@ -76,13 +78,13 @@ As shown, a metadata block can have two sections, `COMPONENT_NAMES` and
 `INFORMATION`. The `INFORMATION` tag is followed by the number of information
 keys that follow.
 
-## COMPONENT_NAMES ##
+### COMPONENT_NAMES
 
 If the `METADATA` block contains the line `COMPONENT_NAMES`, the following lines
 are expected to be encoded strings containing the names of each component. There
 must be one line per component.
 
-## INFORMATION ##
+### INFORMATION
 
 If the `METADATA` block contains the line `INFORMATION`, the number of information
 keys is read from the INFORMATION line and `vtkInformation` data that follows is
@@ -105,49 +107,49 @@ newlines.
 
 Specific examples of supported key types:
 
-### vtkInformationDoubleKey ###
+#### vtkInformationDoubleKey
 
 ```
 NAME Double LOCATION TestKey
 DATA 1
 ```
 
-### vtkInformationDoubleVectorKey ###
+#### vtkInformationDoubleVectorKey
 
 ```
 NAME DoubleVector LOCATION TestKey
 DATA 3 1 90 260
 ```
 
-### vtkInformationIdTypeKey ###
+#### vtkInformationIdTypeKey
 
 ```
 NAME IdType LOCATION TestKey
 DATA 5
 ```
 
-### vtkInformationStringKey ###
+#### vtkInformationStringKey
 
 ```
 NAME String LOCATION TestKey
 DATA Test%20String!%0ALine2
 ```
 
-### vtkInformationIntegerKey ###
+#### vtkInformationIntegerKey
 
 ```
 NAME Integer LOCATION TestKey
 DATA 408
 ```
 
-### vtkInformationIntegerVectorKey ###
+#### vtkInformationIntegerVectorKey
 
 ```
 NAME IntegerVector LOCATION TestKey
 DATA 3 1 5 45
 ```
 
-### vtkInformationStringVectorKey ###
+#### vtkInformationStringVectorKey
 
 ```
 NAME StringVector LOCATION TestKey
@@ -157,7 +159,7 @@ Second%20(with%20whitespace!)
 Third%20(with%0Anewline!)
 ```
 
-### vtkInformationUnsignedLongKey ###
+#### vtkInformationUnsignedLongKey
 
 ```
 NAME UnsignedLong LOCATION TestKey
diff --git a/Documentation/Doxygen/IOXMLInformationFormat.md b/Documentation/Doxygen/IOXMLInformationFormat.md
index b2148158b27c1b8eb5fbaffb3c1e0e0017ee215a..cc92af0d1bc7f20f05f9e8db6acde8132a715de4 100644
--- a/Documentation/Doxygen/IOXMLInformationFormat.md
+++ b/Documentation/Doxygen/IOXMLInformationFormat.md
@@ -1,14 +1,16 @@
 @page IOXMLInformationFormat VTK XML Reader/Writer Information Format
 @tableofcontents
 
-# Overview #
+# VTK XML Reader/Writer Information Format
+
+## Overview
 
 The vtk xml data file readers / writers store certain `vtkInformation`
 entries that are set on `vtkAbstractArray`'s `GetInformation()` object. Support
 is currently limited to numeric and string information keys, both single- and
 vector-valued. Only the information objects attached to arrays are written/read.
 
-# Array Information #
+## Array Information
 
 Array information is embedded in the `<DataArray>` XML element as a series of
 `<InformationKey>` elements. The required attributes `name` and `location`
@@ -30,7 +32,7 @@ the `vtkDataArray::UNITS_LABEL()` key has `name="UNITS_LABEL"` and
 
 Specific examples of supported key types:
 
-### vtkInformationDoubleKey ###
+### vtkInformationDoubleKey
 
 ```
 <InformationKey name="Double" location="XMLTestKey">
@@ -38,7 +40,7 @@ Specific examples of supported key types:
 </InformationKey>
 ```
 
-### vtkInformationDoubleVectorKey ###
+### vtkInformationDoubleVectorKey
 
 ```
 <InformationKey name="DoubleVector" location="XMLTestKey" length="3">
@@ -54,7 +56,7 @@ Specific examples of supported key types:
 </InformationKey>
 ```
 
-### vtkInformationIdTypeKey ###
+### vtkInformationIdTypeKey
 
 ```
 <InformationKey name="IdType" location="XMLTestKey">
@@ -62,7 +64,7 @@ Specific examples of supported key types:
 </InformationKey>
 ```
 
-### vtkInformationStringKey ###
+### vtkInformationStringKey
 
 ```
 <InformationKey name="String" location="XMLTestKey">
@@ -71,7 +73,7 @@ Line2
 </InformationKey>
 ```
 
-### vtkInformationIntegerKey ###
+### vtkInformationIntegerKey
 
 ```
 <InformationKey name="Integer" location="XMLTestKey">
@@ -79,7 +81,7 @@ Line2
 </InformationKey>
 ```
 
-### vtkInformationIntegerVectorKey ###
+### vtkInformationIntegerVectorKey
 
 ```
 <InformationKey name="IntegerVector" location="XMLTestKey" length="3">
@@ -95,7 +97,7 @@ Line2
 </InformationKey>
 ```
 
-### vtkInformationStringVectorKey ###
+### vtkInformationStringVectorKey
 
 ```
 <InformationKey name="StringVector" location="XMLTestKey" length="3">
@@ -112,7 +114,7 @@ newline!)
 </InformationKey>
 ```
 
-### vtkInformationUnsignedLongKey ###
+### vtkInformationUnsignedLongKey
 
 ```
 <InformationKey name="UnsignedLong" location="XMLTestKey">
diff --git a/Documentation/Doxygen/ModuleSystem.md b/Documentation/Doxygen/ModuleSystem.md
index afd046d91506870c8f178fab16c6b939129644b6..3413f38ae7b9ca06c87fe6bfec4d55e61d1575af 100644
--- a/Documentation/Doxygen/ModuleSystem.md
+++ b/Documentation/Doxygen/ModuleSystem.md
@@ -4,7 +4,7 @@ VTK 9.0 introduces a new build system compared to previous versions. This
 version uses CMake's built-in functionality for behaviors that were performed
 manually in the previous iteration of the build system.
 
-# Terminology
+## Terminology
 
   - **module**: A unit of API provided by a project. This is the core of the
     system and there are lots of features available through this mechanism that
@@ -21,7 +21,7 @@ manually in the previous iteration of the build system.
   - **enable status**: A 4-way state to allow for "weak" and "strong" selection
     or deselection of a module or group for building.
 
-# Principles
+## Principles
 
 The module system was designed with a number of principles in mind. These
 should be followed as much as possible when developing extensions as well.
@@ -67,7 +67,7 @@ should be followed as much as possible when developing extensions as well.
 [cmake-CMAKE_PROJECT_NAME]: https://cmake.org/cmake/help/latest/variable/CMAKE_PROJECT_NAME.html
 [cmake-project]: https://cmake.org/cmake/help/latest/command/project.html
 
-# Build process
+## Build process
 
 Building modules involves two phases. The first phase is called "scanning" and
 involves collecting all the information necessary for the second phase,
@@ -90,7 +90,7 @@ when they are built.
 [vtk.module]: @ref module-parse-module
 [vtk_module_build]: @ref vtk_module_build
 
-# Modules
+## Modules
 
 Modules are described by [vtk.module][] files. These files are "scanned" using
 the [vtk_module_scan][] function. They provide all the information necessary for
@@ -132,7 +132,7 @@ module is treated as if it did not exist at all.
 [vtk_module_find_modules]: @ref vtk_module_find_modules
 [cmake-find_package]: https://cmake.org/cmake/help/latest/command/find_package.html
 
-## Module metadata
+### Module metadata
 
 A number of pieces of metadata are considered important enough to indicate them
 at the module level. These are used for managing slightly different workflows
@@ -152,7 +152,7 @@ for modules which have these properties.
     implicitly `EXCLUDE_WRAP`, not `IMPLEMENTABLE` and do not `IMPLEMENTS` any
     module.
 
-## Enabling modules for build
+### Enabling modules for build
 
 Modules are enabled in a number of ways. These ways allow for project control
 and user control of which modules should be built or not. There are 4 states for
@@ -197,7 +197,7 @@ the modules.
 
 [enable-status]: @ref module-enable-status
 
-## Dependencies
+### Dependencies
 
 Modules have three types of dependencies:
 
@@ -235,7 +235,7 @@ command. The required json argument is only available in a build tree though.
 
 `Utilities/Maintenance/FindNeededModules.py -s /path/to/sources -j path/to/vtk_build/modules.json`
 
-## Testing
+### Testing
 
 There is some support for testing in the module system, but it is not as
 comprehensive as the build side. This is because testing infrastructure and
@@ -281,7 +281,7 @@ be used for optional module dependencies.
 
 [cmake-add_subdirectory]: https://cmake.org/cmake/help/latest/command/add_subdirectory.html
 
-# Building modules
+## Building modules
 
 After scanning is complete, [vtk_module_scan][] returns a list of modules and
 kits to build in the variables given by the `PROVIDES_MODULES` and
@@ -308,7 +308,7 @@ When using [vtk_module_build][], the `PROVIDES_MODULES` and `PROVIDES_KITS` from
 a single scan should be passed together. Multiple scans may be built together as
 well if they all use the same build parameters as each other.
 
-## Build-time parameters
+### Build-time parameters
 
 The [vtk_module_build][] function is where the decision to build with or without
 kits is decided through the `BUILD_WITH_KITS` option. Only if this is set will
@@ -334,7 +334,7 @@ targets not built under [vtk_module_build][] also end up at a sensible location.
 [cmake-CMAKE_LIBRARY_OUTPUT_DIRECTORY]: https://cmake.org/cmake/help/latest/variable/CMAKE_LIBRARY_OUTPUT_DIRECTORY.html
 [cmake-CMAKE_RUNTIME_OUTPUT_DIRECTORY]: https://cmake.org/cmake/help/latest/variable/CMAKE_RUNTIME_OUTPUT_DIRECTORY.html
 
-## Library parameters
+### Library parameters
 
 When building libraries, it is sometimes useful to have top-level control of
 library metadata. For example, VTK suffixes its library filenames with a version
@@ -352,7 +352,7 @@ number. The variables that control this include:
 [cmake-VERSION]: https://cmake.org/cmake/help/latest/prop_tgt/VERSION.html
 [cmake-SOVERSION]: https://cmake.org/cmake/help/latest/prop_tgt/SOVERSION.html
 
-## Installation support
+### Installation support
 
 [vtk_module_build][] also offers arguments to aid in installing module
 artifacts. These include destinations for pieces that are installed, CMake
@@ -399,7 +399,7 @@ true).
 
 [cmake-CMAKE_INSTALL_PREFIX]: https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html
 
-## Test data information
+### Test data information
 
 The directory that is looked for in each module is specified by using the
 `TEST_DIRECTORY_NAME` argument. If it is set to the value of `NONE`, no testing
@@ -422,7 +422,7 @@ Each is provided in the testing subdirectory as `_vtk_build_${name}`, so the
 
 [ExternalData]: https://cmake.org/cmake/help/latest/module/ExternalData.html
 
-# Building a module
+## Building a module
 
 Building a module is basically the same as a normal CMake library or executable,
 but is wrapped to use arguments to facilitate wrapping, exporting, and
@@ -439,7 +439,7 @@ associated with the module. The module system requires that the `CMakeLists.txt`
 for a module create a target with the name of the module. In the case of
 `INTERFACE` modules, it suffices to create the module manually in many cases.
 
-## Libraries
+### Libraries
 
 Most modules end up being libraries that can be linked against by other
 libraries. Due to cross-platform support generally being a good thing, the
@@ -477,7 +477,7 @@ should be supported, but might not work at the moment.
 [vtk_module_add_executable]: @ref vtk_module_add_executable
 [GenerateExportHeader]: https://cmake.org/cmake/help/latest/module/GenerateExportHeader.html
 
-### Source listing
+#### Source listing
 
 Instead of using CMake's "all sources in a single list" pattern for
 `add_library`, [vtk_module_add_module][] classifies its source files explicitly:
@@ -518,7 +518,7 @@ conventions to ease usage. These include:
 
 [vtk_module_install_headers]: @ref vtk_module_install_headers
 
-## Executables
+### Executables
 
 Executables may be created using [vtk_module_add_executable][]. The first
 argument is the name of the executable to build. Since the scanning phase does
@@ -536,7 +536,7 @@ tree. It will not be available to consumers of the project. If the name of the
 executable is different from the target name, `BASENAME` may be used to change
 the executable's name.
 
-## Module APIs
+### Module APIs
 
 All of CMake's `target_` function calls have [analogues][module-as-target] for
 modules. This is primarily due to the kits feature which causes the target name
@@ -589,14 +589,14 @@ differences, if any) is:
 [vtk_module_link]: @ref vtk_module_link
 [vtk_module_link_options]: @ref vtk_module_link_options
 
-# Packaging support
+## Packaging support
 
 Getting installed packages to work for CMake is, unfortunately, not trivial. The
 module system provides some support for helping with this, but it does place
 some extra constraints on the project so that some assumptions that vastly
 simplify the process can be made.
 
-## Assumptions
+### Assumptions
 
 The main assumption is that all modules passed to a single [vtk_module_build][]
 have the same CMake namespace (the part up to and including the `::`, if any,
@@ -618,7 +618,7 @@ to allow the component to not exist while not failing the main
 
 [cmake-CMAKE_FIND_PACKAGE_NAME]: https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_PACKAGE_NAME.html
 
-## Creating a full package
+### Creating a full package
 
 The module system provides no support for the top-level file that is used by
 [`find_package`][cmake-find_package]. This is because this logic is highly
@@ -636,7 +636,7 @@ Here, the list of files generated are based on the `PACKAGE` argument passed to
 The module properties file must be included after the targets file so that they
 exist when it tries to add properties to the imported targets.
 
-## External dependencies
+### External dependencies
 
 Since the module system is heavily skewed towards using imported targets, these
 targets show up by name in the [`find_package`][cmake-find_package] of the
@@ -667,7 +667,7 @@ so that the package can collate the reason why things are not available.
 [vtk_module_export_find_packages]: @ref vtk_module_export_find_packages
 [vtk_module_find_package]: @ref vtk_module_find_package
 
-## Setting the `_FOUND` variable
+### Setting the `_FOUND` variable
 
 The module system does not currently help in determining the top-level
 `${CMAKE_FIND_PACKAGE_NAME}_FOUND` variable based on the results of the
@@ -691,12 +691,12 @@ details about [creating a package configuration][cmake-create-package-config].
 
 [cmake-create-package-config]: https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-a-package-configuration-file
 
-# Advanced topics
+## Advanced topics
 
 There are a number of advanced features provided by the module system that are
 not normally required in a simple project.
 
-## Kits
+### Kits
 
 Kits are described in [vtk.kit][] files which act much like [vtk.module][]
 files. However, they only have `NAME`, `LIBRARY_NAME`, and `DESCRIPTION` fields.
@@ -712,7 +712,7 @@ that they do not know about.
 [vtk.kit]: @ref module-parse-kit
 [vtk_module_find_kits]: @ref vtk_module_find_kits
 
-### Requirements
+#### Requirements
 
 In order to actually use kits, CMake 3.12 is necessary in order to do the
 [`OBJECT`][cmake-OBJECT] library manipulations done behind the scenes to make it
@@ -728,7 +728,7 @@ and other usage requirements should not leak from other modules that are members
 of the same kit.
 
 <a name="autoinit"></a>
-## Autoinit
+### Autoinit
 
 The module system supports a mechanism for triggering static code construction
 for modules which require it. This cannot be done through normal CMake usage
@@ -751,7 +751,7 @@ For details on the implementation of the autoinit system, please see
 [autoinit]: @ref module-autoinit
 
 <a name="wrapping"></a>
-## Wrapping
+### Wrapping
 
 VTK comes with support for wrapping its classes into other languages.
 Currently, VTK supports wrapping its classes for use in the Python and Java
@@ -762,7 +762,7 @@ All languages read the headers of classes with a `__VTK_WRAP__` preprocessor
 definition defined. This may be used to hide methods or other details from the
 wrapping code if wanted.
 
-### Python
+#### Python
 
 For Python, the [vtk_module_wrap_python][] function must be used. This function
 takes a list of modules in its `MODULES` argument and creates Python modules
@@ -790,7 +790,7 @@ wrapping code.
 [vtk_module_wrap_python]: @ref vtk_module_wrap_python
 [vtk_module_python_default_destination]: @ref vtk_module_python_default_destination
 
-### Java
+#### Java
 
 For Java, the [vtk_module_wrap_java][] function must be used. This function
 creates Java sources for classes in the modules passed in its `MODULES`
@@ -809,14 +809,14 @@ wrapping code.
 
 [vtk_module_wrap_java]: @ref vtk_module_wrap_java
 
-### Hierarchy files
+#### Hierarchy files
 
 Hierarchy files are used by the language wrapper tools to know the class
 inheritance for classes within a module. Each module has a hierarchy file
 associated with it. The path to a module's hierarchy file is stored in its
 `hierarchy` module property.
 
-## Third party
+### Third party
 
 The module system has support for representing third party modules in its
 build. These may be built as part of the project or represented using other
@@ -841,7 +841,7 @@ participate in autoinit.
 [vtk_module_third_party_internal]: @ref vtk_module_third_party_internal
 [vtk_module_third_party_external]: @ref vtk_module_third_party_external
 
-### External third party modules
+#### External third party modules
 
 External modules are found using CMake's [`find_package`][cmake-find_package]
 mechanism. In addition to the arguments supported by
@@ -862,7 +862,7 @@ The `STANDARD_INCLUDE_DIRS` argument creates an include interface for the
 module target which includes the "standard" module include directories to.
 Basically, the source and binary directories of the module.
 
-### Internal third party modules
+#### Internal third party modules
 
 Internal modules are those that may be built as part of the build. These should
 ideally specify a set of `LICENSE_FILES` indicating the license status of the
@@ -888,7 +888,7 @@ be used by setting the `HEADERS_SUBDIR` option. It is implied for
 After the subdirectory is added a target with the module's name must exist.
 However, a target is automatically created if it is `HEADERS_ONLY`.
 
-#### Properly shipping internal third party code
+##### Properly shipping internal third party code
 
 There are many things that really should be done to ship internal third party
 code (also known as vendoring) properly. The issue is mainly that the internal
@@ -921,7 +921,7 @@ external package. In this case, it is recommended that code using the third
 party module use unmangled names and let the module interface and mangling
 headers handle the mangling at that level.
 
-## Debugging
+### Debugging
 
 The module system can output debugging information about its inner workings by
 using the `_vtk_module_log` variable. This variable is a list of "domains" to
@@ -938,7 +938,7 @@ following domains are used in the internals of the module system:
 It is encouraged that projects expose user-friendly flags to control logging
 rather than exposing `_vtk_module_log` directly.
 
-## Control variables
+### Control variables
 
 These variables do not follow the API convention and are used if set:
 
diff --git a/Documentation/Doxygen/MomentInvariantsArchitecture.md b/Documentation/Doxygen/MomentInvariantsArchitecture.md
index 638cab0002d4701a91fe70155241ed75e960b51d..eaa09d0781a0ad67387e87724339a985f70f1ca0 100644
--- a/Documentation/Doxygen/MomentInvariantsArchitecture.md
+++ b/Documentation/Doxygen/MomentInvariantsArchitecture.md
@@ -1,4 +1,6 @@
-# Rotation-invariant Pattern Detection
+# MomentInvariants Architecture
+
+## Rotation-invariant Pattern Detection
 For pattern detection, the orientation of the pattern is usually not known a priory. The process should not be decelerated more than necessary while the pattern detection algorithm looks for all possible rotated copies of the template. Therefore, rotation invariance is a critical requirement.
 Moment invariants can achieve rotation invariance without the need for point to point correlations, which are difficult to generate in smooth fields. For an introduction, we recommend
 
@@ -38,7 +40,7 @@ Langbein et al. have generalized the definition of the moment tensor to tensor v
 where $x^{\otimes o}$ denotes the $o$-th tensor power of the vector $x$.
 -->
 
-# Extensions
+## Extensions
 The **MomentInvariants** module contains actually a bunch of extra algorithms and helper classes.
 
 The class **vtkMomentsHelper** provides functions for the moments computation that will be needed by vtkComputeMoments and vtkMomentInvariants.
diff --git a/Documentation/Doxygen/PythonWrappers.md b/Documentation/Doxygen/PythonWrappers.md
index 538e6137a87cb98787bdef6cf33037153362c744..25b876d33610e3b52e19d83975d7e1b124894a41 100644
--- a/Documentation/Doxygen/PythonWrappers.md
+++ b/Documentation/Doxygen/PythonWrappers.md
@@ -1,6 +1,6 @@
 # Python Wrappers
 
-# Introduction {#introduction}
+## Introduction {#introduction}
 
 This document is a reference for using VTK from Python. It is not a tutorial
 and provides very little information about VTK itself, but instead describes
@@ -9,7 +9,7 @@ differs from using VTK from C++.  It assumes that the reader is already
 somewhat familiar with both Python and VTK.
 
 
-# Background {#background}
+## Background {#background}
 
 The Python wrappers are automatically generated from the VTK source code,
 and for the most part, there is a one-to-one mapping between the VTK classes
@@ -20,7 +20,7 @@ the wrappers, you are actually executing compiled C++ code, and there is
 very little performance difference between VTK/C++ and VTK/Python.
 
 
-# Installation {#installation}
+## Installation {#installation}
 
 VTK for Python can be installed via either conda or pip, where the conda
 packages is maintained on conda-forge, while the pip packages are maintained
@@ -40,7 +40,7 @@ Instructions for building VTK from source code are given in the file
 [vtk-build]: https://gitlab.kitware.com/vtk/vtk/-/blob/release/Documentation/dev/build.md
 
 
-# Importing {#importing}
+## Importing {#importing}
 
 VTK is comprised of over one hundred individual modules. Programs can import
 just the modules that are needed, in order to reduce load time.
@@ -74,7 +74,7 @@ The output is as follows:
     from vtkmodules.vtkFiltersSources import vtkConeSource
     from vtkmodules.vtkRenderingCore import vtkRenderWindow
 
-## Factories and Implementation Modules {#implementation-modules}
+### Factories and Implementation Modules {#implementation-modules}
 
 In the first 'import' example above, you might be wondering about this line:
 
@@ -121,7 +121,7 @@ into your program, even if you are not certain that you need them.
 * For `vtkRenderingVolume`, `import vtkRenderingVolumeOpenGL2`
 * For `vtkCharts`, `import vtkContextOpenGL2`
 
-## Classic VTK Import {#classic-import}
+### Classic VTK Import {#classic-import}
 
 There are many VTK programs that still import the '`vtk`' module, which
 has been available since VTK 4.0, rather than using the '`vtkmodules`'
@@ -141,9 +141,9 @@ was fixed in VTK 9.2.6.  For 9.2.5 and earlier, the following can be used:
 
 From the programmer's perspective, this is equivalent to '`import vtk`'.
 
-# VTK Classes and Objects {#classes-and-objects}
+## VTK Classes and Objects {#classes-and-objects}
 
-## Classes Derived from vtkObjectBase {#vtkobject-classes}
+### Classes Derived from vtkObjectBase {#vtkobject-classes}
 
 In C++, classes derived from `vtkObjectBase` are instantiated by calling
 `New()`.  In Python, these classes are instantiated by simply calling the
@@ -179,7 +179,7 @@ C++ `PrintSelf()` method.  The printed information can be useful for debugging:
       Reference Count: 1
       Registered Events: (none)
 
-## Other Classes (Special Types) {#special-types}
+### Other Classes (Special Types) {#special-types}
 
 VTK also uses several classes that aren't derived from `vtkObjectBase`.  The
 most important of these is `vtkVariant`, which can hold any type of object:
@@ -211,7 +211,7 @@ on what `operator<<` produces.
     >> print(repr(v))
     vtkmodules.vtkCommonCore.vtkVariant((invalid))
 
-## Class Templates {#class-templates}
+### Class Templates {#class-templates}
 
 There are several C++ templates in VTK, which can be tricky to use from the
 wrappers since the Python language has no real concept of templates.  The
@@ -253,7 +253,7 @@ The type names are the same as numpy's dtypes: `bool`, `int8`, `uint8`,
 see [Template Keys](#template-keys) in [Advanced Topics](#advanced-topics).
 
 
-# Method Calls {#method-calls}
+## Method Calls {#method-calls}
 
 When VTK methods are called from Python, conversion of all parameters from
 Python to C++ occurs automatically.  That is, if the C++ method signature
@@ -302,7 +302,7 @@ you to pass null objects and null strings:
     >>> print(a.GetMapper())
     None
 
-## Wrappable and Unwrappable Methods {#wrappable}
+### Wrappable and Unwrappable Methods {#wrappable}
 
 A method cannot be used from Python if its C++ parameters or return type
 cannot be converted to or from Python by the wrappers, or if the method is
@@ -356,7 +356,7 @@ access is used.
 The `vtkObject::AddObserver()` method has a special wrapping, as discussed
 in the [Observer Callbacks](#observer-callbacks) section below.
 
-## Conversion Constructors {#conversion-constructors}
+### Conversion Constructors {#conversion-constructors}
 
 If a wrapped type has constructor that takes one parameter, and if that
 constructor is not declared '`explicit`', then the wrappers will automatically
@@ -374,7 +374,7 @@ will then pass it as a parameter to `InsertNextItem()`.  This is a feature
 that most C++ programmers will take for granted, but Python users might
 find it surprising.
 
-## Overloaded Methods {#overloaded-methods}
+### Overloaded Methods {#overloaded-methods}
 
 If you call a VTK method that is overloaded, the Python wrappers will choose
 the overload that best matches the supplied arguments.  This matching takes
@@ -388,7 +388,7 @@ any methods that is overloaded on C++ `float` and `double`.  The Python
 `float` type is a perfect match C++ `double`, therefore the `float` overload
 is not wrapped.
 
-## Static Methods {#static-methods}
+### Static Methods {#static-methods}
 
 A static method can be called without an instance.  For example,
 
@@ -399,7 +399,7 @@ like `vtkMatrix4x4`, most of the non-static methods have static overloads.
 Within Python, the only way to tell if a VTK method is static (other than
 trying it) is to look at its docstring.
 
-## Unbound Methods {#unbound-methods}
+### Unbound Methods {#unbound-methods}
 
 When a non-static method is called on the class, rather than on an instance,
 it is called an unbound method call.  An unbound method call must provide
@@ -414,7 +414,7 @@ C++ unbound method calls.  These are useful when deriving a Python class
 from a wrapped VTK class, since they allow you to call any base class
 methods that have been overridden in the subclass.
 
-## Operator Methods {#operator-methods}
+### Operator Methods {#operator-methods}
 
 For special classes (the ones not derived from `vtkObjectBase`), some useful
 C++ operators are wrapped in python.  The '`[]`' operator is wrapped for
@@ -429,7 +429,7 @@ of `vtkVariant` objects with Python.
 The '`<<`' operator for printing is wrapped and is used by the python
 `print()` and `str()` commands.
 
-## Strings and Bytes {#strings-and-bytes}
+### Strings and Bytes {#strings-and-bytes}
 
 VTK uses both `char*` and `std::string` for strings.  As far as the wrappers
 are concerned, these are equivalent except that the former can be `nullptr`
@@ -445,7 +445,7 @@ if it is valid utf-8, or as a `bytes` object if not.  The caller should check
 the type of the returned object (`str`, `bytes`, or perhaps `None`) if there
 is any reason to suspect that non-utf-8 text might be present.
 
-## STL Containers {#stl-containers}
+### STL Containers {#stl-containers}
 
 VTK provides conversion between `std::vector` and Python sequences
 such as `tuple` and `list`.  If the C++ method returns a vector,
@@ -472,7 +472,7 @@ The value type of the `std::vector<T>` must be `std::string` or a
 fundamental numeric type such as `double` or `int` (including
 `signed char` and `unsigned char` but excluding `char`).
 
-## Smart pointers {#smart-pointers}
+### Smart pointers {#smart-pointers}
 
 The wrappers will automatically convert between C++ `vtkSmartPointer<T>`
 and objects of type `T` (or `None`, if the smart pointer is empty):
@@ -496,7 +496,7 @@ the wrappers will automatically construct the vector from any sequence that
 is passed from Python.  The objects in the sequence must be of type `T` (or
 a subclass of `T`, or `None`).  If not, a `TypeError` will be raised.
 
-## Pass by Reference {#pass-by-reference}
+### Pass by Reference {#pass-by-reference}
 
 Many VTK methods use pass-by-reference to return values back to the caller.
 Calling these methods from Python requires special consideration, since
@@ -538,7 +538,7 @@ Some important notes when using pass-by-reference:
    because the reference already supports the interface protocols of the
    object that it contains.
 
-## Preconditions {#preconditions}
+### Preconditions {#preconditions}
 
 One very real concern when using VTK from Python is that the parameters that
 you pass to a method might cause the program to crash.  In particular, it is
@@ -560,7 +560,7 @@ Currently the only way to find out if a method has preconditions is to look
 at the declaration of the method in the C++ header file to see if it has a
 `VTK_EXPECTS` hint.
 
-# Observer Callbacks {#observer-callbacks}
+## Observer Callbacks {#observer-callbacks}
 
 Similar to what can be done in C++, a Python function can be called
 each time a VTK event is invoked on a given object.  In general, the
@@ -577,7 +577,7 @@ or `func(self, obj:vtkObject, event:str)` if it is a method of a class.
     object: vtkObject - event: ModifiedEvent
 
 
-## Call Data {#observer-call-data}
+### Call Data {#observer-call-data}
 
 In case there is a 'CallData' value associated with an event, in C++, you
 have to cast it from `void*` to the expected type using `reinterpret_cast`.
@@ -614,9 +614,9 @@ is first declared with the help of the `@calldata_type` decorator:
     >>>     print('object: %s - event: %s - msg: %s' % (object.GetClassName(),
                                                         event, calldata))
 
-# Other Wrapped Entities {#other}
+## Other Wrapped Entities {#other}
 
-## Constants {#constants}
+### Constants {#constants}
 
 Most of the constants defined in the VTK header files are available in Python,
 and they can be accessed from the module in which they are defined.  Many of
@@ -637,7 +637,7 @@ Constants in the header files are wrapped if they are enums, or if they are
 const variables of a wrappable scalar type, or if they are preprocessor
 symbols that evaluate to integer, floating-point, or string literal types.
 
-## Enum Types {#enum-types}
+### Enum Types {#enum-types}
 
 Each named enum type is wrapped as a new Python type, and members of the enum
 are instances of that type.  This allows type checking for enum types:
@@ -668,7 +668,7 @@ Note that the VTK enum types behave like C++ enums, and not like the Python
 enums types provided by the Python '`enum`' module.  In particular, all VTK
 enum values can be used anywhere that an `int` can be used.
 
-## Namespaces {#namespaces}
+### Namespaces {#namespaces}
 
 Namespaces are currently wrapped in a very limited manner.  The only
 namespace members that are wrapped are enum constants and enum types.
@@ -677,14 +677,14 @@ namespaces.  Currently, the wrappers implement namespaces as Python
 `module` objects.
 
 
-# Docstrings {#docstrings}
+## Docstrings {#docstrings}
 
 The wrappers automatically generate docstrings from the doxygen comments in
 the header files.  The Python `help()` command can be used to print the
 documentation to the screen, or the `__doc__` attributes of the classes
 and methods can be accessed directly.
 
-## Method Docstrings {#method-docstrings}
+### Method Docstrings {#method-docstrings}
 
 The method docstrings are formatted with the method signatures first,
 followed by doxygen comments.  The Python method signatures have type
@@ -709,7 +709,7 @@ completeness.
 Some Python IDEs will automatically show the docstring as soon as you type
 the name of the method.
 
-## Class Docstrings {#class-docstrings}
+### Class Docstrings {#class-docstrings}
 
 The class docstrings include a brief description of the class, followed
 by the name of the superclass, and then the full doxygen documentation,
@@ -746,7 +746,7 @@ more public constructors, and these will be included before the comments:
     through different threads.
 ```
 
-## Template Docstrings {#template-docstrings}
+### Template Docstrings {#template-docstrings}
 
 Class templates are documented similar to classes, except that they include
 a 'Provided Types' section that lists the available template instantiations
@@ -811,9 +811,9 @@ of whether the the class template derives from `vtkObjectBase` or not:
 ```
 
 
-# Internals and Advanced Topics {#advanced-topics}
+## Internals and Advanced Topics {#advanced-topics}
 
-## Special Attributes {#special-attributes}
+### Special Attributes {#special-attributes}
 
 Classes and objects derived from `vtkObjectBase` have special attributes, which
 are only used in very special circumstances.
@@ -855,7 +855,7 @@ wrapped with a different wrapper tool, for example with SWIG.  If you can
 get the VTK pointer from SWIG, you can use it to construct Python object
 that can be used with the native VTK wrappers.
 
-## Wrapper Hints {#wrapper-hints}
+### Wrapper Hints {#wrapper-hints}
 
 A wrapper hint is an attribute that can be added to a class, method, or
 parameter declaration in a C++ header file to give extra information to
@@ -911,7 +911,7 @@ used with `T*` parameters, for basic integer or float type `T`, to indicate
 that the Python buffer protocol will be used to access the values, rather
 than the Python sequence protocol that is used by default.
 
-## Deprecation Warnings {#deprecation-warnings}
+### Deprecation Warnings {#deprecation-warnings}
 
 In addition to the wrapping hints, the Python wrappers are also aware of the
 deprecation attributes that have been applied to classes and methods.  When
@@ -928,7 +928,7 @@ To see each deprecation warning just once per session,
 
     warnings.filterwarnings('once', category=DeprecationWarning)
 
-## Template Keys {#template-keys}
+### Template Keys {#template-keys}
 
 The following is a table of common template key names, which are the same as
 the numpy dtype names.  Note that you can actually use numpy dtypes as keys,
@@ -959,7 +959,7 @@ much older `array` module.
 Since the size of '`long`' and '`unsigned long`' is platform-dependent, these
 types should generally be avoided.
 
-## Exception Handling {#exception-handling}
+### Exception Handling {#exception-handling}
 
 There are times when an observer might generate a Python exception.  Since
 the observers are called from C++, there is no good way to catch these
@@ -968,7 +968,7 @@ traceback to stderr and then clear the error indicator.  The Python program
 will continue running unless the exception was a `KeyboardInterrupt` (Ctrl-C),
 in which case the program will exit with an error code of 1.
 
-## Deleting a vtkObject {#deleting-objects}
+### Deleting a vtkObject {#deleting-objects}
 
 There is no direct equivalent of VTK's `Delete()` method, since Python does
 garbage collection automatically.  The Python object will be deleted
@@ -1000,7 +1000,7 @@ be extracted before the deletion occurs:
 In cases where you need to track down tricky memory issues, you might find
 it useful to call the `GetReferenceCount()` method of the object directly.
 
-## Ghosts {#ghosts}
+### Ghosts {#ghosts}
 
 A wrapped VTK object (derived from `vtkObjectBase`) is a Python object that
 holds a pointer to a C++ object (specifically, a `vtkObjectBase*`).  The
@@ -1036,7 +1036,7 @@ graveyard holds a weak pointer to its C++ object and will vanish when the C++
 object is deleted (not immediately, but the next time the graveyard garbage
 collector runs).
 
-## Subclassing a VTK Class {#subclassing}
+### Subclassing a VTK Class {#subclassing}
 
 It is possible to subclass a VTK class from within Python, but this is of
 limited use because the C++ virtual methods are not hooked to the Python
@@ -1051,7 +1051,7 @@ is via callbacks. The `vtkProgrammableSource` and `vtkProgrammableFilter` are
 examples of VTK algorithm classes that use callbacks for execution, while
 `vtkInteractionStyleUser` can use observer callbacks for event handling.
 
-## Wrapping External VTK Modules {#external-wrapping}
+### Wrapping External VTK Modules {#external-wrapping}
 
 If you have your own C++ classes that are based on VTK, and if they are
 placed with a VTK module with a vtk.module file, then they can be wrapped
@@ -1060,9 +1060,9 @@ also find the cmake documentation on VTK modules to be useful.
 
 [external-wrapping]: https://gitlab.kitware.com/vtk/vtk/-/blob/release/Examples/Modules/Wrapping
 
-# Experimental Features {#experimental-features}
+## Experimental Features {#experimental-features}
 
-## Python Class Overrides {#override}
+### Python Class Overrides {#override}
 
 VTK now supports overriding wrapped classes with Python subclasses.  This
 enables developers to provide more Python friendly interfaces for certain
@@ -1097,7 +1097,7 @@ Please see [Subclassing a VTK Class](#subclassing) for restrictions on
 subclassing VTK classes through Python.
 
 
-## Stub Files for Type Hinting {#stub-files}
+### Stub Files for Type Hinting {#stub-files}
 
 VTK includes a script called [`generate_pyi.py`][generate_pyi] that
 will generate pyi stub files for each wrapped VTK module.  The purpose of
diff --git a/Documentation/Doxygen/SMPTools.md b/Documentation/Doxygen/SMPTools.md
index 0ea26f5ddb11308aac6d17a1df76ef038cd04519..bab0d02d8e39e292a3c1917d8ec3495fe8374e5e 100644
--- a/Documentation/Doxygen/SMPTools.md
+++ b/Documentation/Doxygen/SMPTools.md
@@ -1,7 +1,7 @@
 # Parallel Processing with VTK's SMP Framework
 August 2022
 
-# Contributors
+## Contributors
 Berk Geveci wrote the initial version of this document in 2013. The design and implementation of vtkSMPTools was strongly influenced by the [KAAPI thread scheduling system](https://www.researchgate.net/publication/221564735_KAAPI_A_thread_scheduling_runtime_system_for_data_flow_computations_on_cluster_of_multi-processors) and an associated Inria research report: [*VtkSMP: Task-based Parallel Operators for Accelerating VTK Filters*](https://hal.inria.fr/hal-00789814). Later contributors to this document include:
 - Timothee Couble
 - Charles Gueunet
@@ -14,7 +14,7 @@ Also note that several blog posts have been written about vtkSMPTools:
 - [Ongoing VTK / ParaView Performance Improvements](https://www.kitware.com/ongoing-vtk-paraview-performance-improvements/)
 - [VTK/ParaView Filters: Performance Improvements](https://www.kitware.com/vtk-paraview-filters-performance-improvements/)
 
-# Introduction
+## Introduction
 The overarching objective of vtkSMPTools, the SMP (symmetric multiprocessing) framework, is to provide an infrastructure to simplify the development of shared memory parallel algorithms in VTK. In addition, vtkSMPTools defines a simple, abstract API that drives several threading backends such as std::thread, TBB (i.e., Intel's Threading Building Blocks template library); and OpenMP; as well as supporting a sequential backend for testing and debugging. To achieve these objectives, we have developed three simple constructs to support basic SMP functionality:
 
 • Parallel building blocks / functions
@@ -23,40 +23,40 @@ The overarching objective of vtkSMPTools, the SMP (symmetric multiprocessing) fr
 
 vtkSMPTools is extremely easy to use, ensuring that the major challenge of creating parallel algorithms is not one of implementation, but rather the design of good, threaded algorithms.  In the next sections we describe the basic concepts used in vtkSMPTools, and then demonstrate these concepts through example code. Of course, there are hundreds of vtkSMPTools implementations found in VTK which provide an excellent source of more complex examples. In the final section of this document we provide tips on how to design and implement  vtkSMPTools-based algorithms.
 
-# Concepts
+## Concepts
 
 The following are several high-level concepts that will help you understand and use vtkSMPTools.
 
-## The Age of Abundant Computing Cores
+### The Age of Abundant Computing Cores
 Many early computational algorithms were designed and implemented in an era of limited computing resources: typically a single CPU was available with rudimentary memory models. Such limitations typically led to a frugal approach to writing algorithms, in particular approaches that minimized CPU utilization. However modern computing architectures commonly have many cores with multiple execution threads per core, and memory models have expanded to include a hierarchy of data caches to retrieve frequently used data more quickly. Also, many developers are inclined to think in terms of *sequential* algorithmic operations, partly due to the way in which we were trained but also because managing multiple simultaneous processes can take a lot of work and programmers are often pressed for time. But with growing data sizes, increasing computational demands, and the abundance of computing threads; it's clear that parallel approaches are essential to creating responsive and impactful software tools. It's important that VTK developers conceive and implement performant parallel algorithms to ensure that the system remain vital into the future.
 
 There are a variety of approaches to parallel computing, but two approaches - distributed computing and shared memory computing - are particularly relevant to VTK. In distributed computing, computational tasks are carried out in separate memory space and exchange information through message passing communication. In shared memory computing, information is exchanged through variables in shared memory space. Typically a flavor of MPI is used by VTK for distributed computing, plus VTK provides a variety of software constructs to support distributed computing. vtkSMPTools is used to implement shared memory computing with symmetric multiprocessing (SMP) approaches; i.e., where multiple processors are connected to a single, shared memory space. Distributed computing is more complex and scales best for extremely large data, while shared memory computing is simpler and works cell on single computers (desktop, laptop, mobile). Note that it is possible to combine distributed and shared computing in a VTK application.
 
 Besides MPI (for distributed computing) and vtkSMPTools (shared memory parallelism, typically on CPUs), be aware that VTK leverages another parallel processing toolkit for computing accelerators (e.g., GPUs). [vtk-m](https://m.vtk.org/) is a toolkit of scientific visualization algorithms for emerging processor architectures, supporting fine-grained concurrency for data analysis and visualization algorithms. Depending on the application, vtk-m may be a preferred solution for extreme scale computing. It is possible to mix all three forms of parallel computing frameworks into a single VTK application.
 
-## Fine- and Coarse-Grained Parallelism
+### Fine- and Coarse-Grained Parallelism
 When parallelizing an algorithm, it is important to first consider the "dimension" (i.e., the way in which data is accessed via threads) over which to parallelize it. For example, VTK's Imaging modules parallelize many algorithms by assigning subsets of the input image (VOIs) to a thread safe function which processes them in parallel. Another example is parallelizing over blocks of a composite dataset (such as an AMR dataset). We refer to these examples as coarse-grained parallelism. On the other hand, we can choose points or cells as a dimension over which to parallelize access to a VTK dataset. Many algorithms simply loop over cells or points and are relatively trivial to parallelize this way. Here we refer to this approach as fine-grained parallelism. Note that some algorithms fall into a gray area. For example, if we parallelize streamline generation over seeds, is it fine- or coarse-grained parallelism?
 
-## Backends
+### Backends
 The SMP framework provides a thin abstraction over a number of threading backends. Currently, we support four backends: Sequential (serial execution); C++ std::thread referred to as STDThread; TBB (based on Intel’s TBB); and OpenMP. Note that the Sequential backend is useful for debugging but is typically not used unless no other backend can be made to work on the target platform. As discussed in the following, it's possible to build VTK with multiple backends, and switch between them at run-time.
 
 Backends are configured via CMake during the build process. Setting the CMake variables `VTK_SMP_ENABLE_OPENMP`, `VTK_SMP_ENABLE_SEQUENTIAL`, `VTK_SMP_ENABLE_STDTHREAD`, and `VTK_SMP_ENABLE_TBB` enables the inclusion of the appropriate SMP backend(s), and `VTK_SMP_IMPLEMENTATION_TYPE` can be used to select one of Sequential, OpenMP, TBB, and STDThread (this selects the default backend when VTK runs). Once VTK is built, setting the environment variable `VTK_SMP_BACKEND_IN_USE` can be used to select from multiple backends. (Note: `vtkSMPTools::SetBackend()` can be used from within a C++ application to select the backend as well -- for example `vtkSMPTools::SetBackend("TBB")` will select TBB.)
 
-## Thread Safety in VTK
+### Thread Safety in VTK
 Probably the most important thing in parallelizing shared-memory algorithms is to make sure that all operations that occur in a parallel region are performed in a thread-safe way (i.e., avoid race conditions). Note that there is much in the VTK core functionality that is not thread-safe. The VTK community has an ongoing effort of cleaning this up and marking APIs that are thread-safe to use. At this point, probably the best approach is to double check by looking at the implementation. Also, we highly recommend using analysis tools such as ThreadSanitizer or Valgrind (with the Helgrind tool) to look for race conditions in problematic code.
 
 When coding parallel algorithms, be especially wary of insidious execution side effects. Such side effects typically result in simultaneous execution of code. For example, invoking `Update()` on a filter shared by multiple threads is a bad idea since simultaneous updates to that filter is likely doomed to fail. Also, some methods like `vtkPolyData::GetCellNeighbors()` internally invoke the one-time operation `BuildLinks()` in order to generate topological information. Similarly, the `BuildLocator()` method found in point and cell locators may be called as a side effect of a geoemtric query such as `vtkDataSet::FindCell()`. In such cases, prior to threaded execution, affected classes should be "primed" by explicitly invoking methods that produce side effects (e.g., call `BuildLinks()` directly on the `vtkPolyData`; or manually call `BuildLocator()` prior to using methods that require a locator).
 
-## Results Invariance
+### Results Invariance
 A significant challenge to writing good threaded algorithms is to insure that they produce the same output each time they execute. For example, a threaded sort operation may order *identical* set elements differently each time the sort is run depending on the order in which data is processed by different computing threads. (This is related to the C++ standard providing the `std::stable_sort` algorithm.) Even simple threaded operation such as summing a list of numbers can produce different results, since the order and partitioning of data during threading may result in round off effects. Since sequential algorithms implicitly order their operations, and threading typically does not do so (unless extensive use of locks, barriers, etc. are used), a sequential algorithm may produce different results than a threaded algorithm, and even across multiple runs threaded algorithms may produce results that vary across each run. Such behaviors are disturbing to users, and make testing difficult. In VTK, we aim to write algorithms that are results invariant.
 
-## Show Me the Code
+### Show Me the Code
 The vtkSMPTools class defined in `VTK\Common\Core\vtkSMPTools.h` provides detailed documentation and further implementation details. To find examples of vtkSMPTools in use, simply search for VTK C++ classes that include this header file.
 
-# Implementation Overview
+## Implementation Overview
 As mentioned previously, vtkSMPTools provides a few, simple programmatic building blocks; support for thread-local storage; and support for atomics. In this section we provide high-level descriptions of these building blocks. Then in the following section we provide implementation details.
 
-## Functional Building Blocks
+### Functional Building Blocks
 The core, functional building blocks of vtkSMPTools are as follows. See `vtkSMPTools.h` for details.
 * `For(begin, end, functor)` - a for loop over the range [begin,end) executing the functor each time.
 * `Fill(begin, end, value)` - assign the given value to the elements in range [begin,end) (a drop in replacement for `std::fill()`).
@@ -69,22 +69,22 @@ Of special interest is the `functor` invoked in the `For()` loop. The functor is
 
 With these few building blocks, powerful threaded algorithms can easily be written. In many cases, the `For()` loop is all that is needed.
 
-## Thread Local Storage
+### Thread Local Storage
 Often times parallel algorithms produce intermediate results that are combined to produce a final result. For example, to sum a long list of numbers, each thread may sum just a subset of the numbers, and when completed the intermediate sums from each thread can be combined to produce a final summation. So the ability to maintain intermediate data associated with each thread is valuable. This is the purpose of thread local storage.
 
 Thread local storage is generally referred to memory that is accessed by one thread only. In the SMP framework, vtkSMPThreadLocal and vtkSMPThreadLocalObject enable the creation of objects local to executing threads. The main difference between the two is that vtkSMPThreadLocalObject makes it easy to manage vtkObject and subclasses by allocating and deleting them appropriately. Thread local storage almost always requires definition of the `Initialize()` and `Reduce()` methods to initialize local storage, and then combine it once the `For()` loop completes.
 
 One important performance trick with thread local storage, is that temporary variables may be defined and then used in the execution of `operator()`. For example, instantiating temporary objects such as vtkGenericCell, vtkIdList, and other C++ containers or classes can be relatively slow. Sometimes it's much faster to create and initialize them once (when the thread is created), and then "reset" them in each invocation of `operator()`.
 
-## Atomics
+### Atomics
 Another very useful tool when developing shared memory parallel algorithms is atomic integers. Atomic integers provide the ability to manipulate integer values in a way that can’t be interrupted by other threads. A very common use case for atomic integers is implementing global counters. For example, in VTK, the modified time (MTime) global counter and vtkObject’s reference count are implemented as atomic integers.
 
 Prior to C++11, vtkSMPTools had an internal implementation for atomic integers. However, this implementation is now obsolete in favor of `std::atomic<>`. C++ also provides `std::mutex' and 'std::lock_guard<>`; and VTK provides a lightweight spinlock `vtkAtomicMutex` which may be faster than using mutexes.
 
-# Implementation Examples
+## Implementation Examples
 In the subsections below, we describe the SMP framework in more detail and provide examples of how it can be used.
 
-## Functors and Parallel For
+### Functors and Parallel For
 The `vtkSMPTools::For()` parallel for is the core computational construct of vtkSMPTools. It's use is as shown in the following example which evaluates points against a set of planes, and adjusts the planes to "bound" the points (see `vtkHull.cxx` and `VTK/Common/DataModel/Testing/Cxx/TestSMPFeatures.cxx`).
 ```
   vtkNew<vtkPoints> pts;
@@ -155,7 +155,7 @@ Note that same code can be conveniently and compactly defined inline via a C++ l
 ```
 With alternative signatures for `For()` it is possible to provide a grain parameter. Grain is a hint to the underlying backend about the coarseness of the typical range when parallelizing a for loop. If you don’t know what grain will work best for a particular problem, omit the grain specification and let the backend find a suitable grain. TBB in particular does a good job with this. Sometimes, you can eek out a little bit more performance by setting the grain just right. Too small, the task queuing overhead will be too much. Too little, load balancing will suffer.
 
-## Thread Local Storage
+### Thread Local Storage
 Thread local storage is generally referred to memory that is accessed by one thread only. In the SMP framework, vtkSMPThreadLocal and vtkSMPThreadLocalObject enable the creation objects local to executing threads. The main difference between the two is that vtkSMPThreadLocalObject makes it easy to manage vtkObject and subclasses by allocating and deleting them appropriately.
 
 Below is an example of thread local objects in use. This example computes the bounds of a set of points represented by a vtkFloatArray. Note in particular the introduction of the `Initialize()` and `Reduce()` methods:
@@ -248,7 +248,7 @@ Thread local objects are immensely useful. Often, visualization algorithms want
 
 However, mutexes have a major impact on the scalability of parallel operations. Another solution is to produce a different vtkPolyData for each execution of the functor. However, this can lead to hundreds if not thousands of outputs that need to be merged, which is a difficult operation to scale. The best option is to use one vtkPolyData per thread using thread local objects. Since it is guaranteed that thread local objects are accessed by one thread at a time (but possibly in many consecutive functor invocations), it is thread safe for functors to keep adding polygons to these objects. The result is that the parallel section will produce only a few vtkPolyData, usually the same as the number of threads in the pool. It is much easier to efficiently merge these vtkPolyData.
 
-## Atomic Integers
+### Atomic Integers
 As mentioned previously, atomics should be represented by the C++ std::atomic<>. However, to provide a brief explanation of the importance of atomics we provide the following simple example.
 
 ```
@@ -277,44 +277,44 @@ std::cout << Total << " " << TotalAtomic.load() << endl;
 
 When this program is executed, most of the time `Total` will be different (smaller) than `Target` whereas `TotalAtomic` will be exactly the same as `Target`. For example, a test run on a Mac prints: `999982 1000000`. This is because when the integer is not atomic, both threads can read the same value of `Total`, increment and write out the same value, which leads to losing one increment operation. Whereas, when ++ happens atomically, it is guaranteed that it will read, increment and write out `Total` all in one uninterruptible operation. When atomic operations are supported at hardware level, they are very fast.
 
-# Tips
+## Tips
 In this section, we provide some tips that we hope will be useful to those that want to develop shared memory parallel algorithms.
 
-## Think about Thread Safety
+### Think about Thread Safety
 First things first, it is essential to keep thread safety in mind. If the parallel section does not produce correct results consistently, there is not a lot of point in the performance improvement it produces. To create thread-safe algorithms, consider using common parallel design patterns. Also verify that the API you are using is thread safe under your particular application. While VTK continues to add additional thread-safe capabilities, there are still many booby traps to avoid.
 
-## Analysis Tools Are Your Friend
+### Analysis Tools Are Your Friend
 The LLVM/Clang-based ThreadSanitizer is widely used to detect data races. Valgrind’s Helgrind is also a wonderful tool. Use these tools often. We developed the original backends mainly using Helgrind. Note that backends like TBB can produce many false positives; you may want to try different backends to reduce these. There are commercial tools with similar functionality, e.g., Intel’s Parallel Studio has static and dynamic checking.
 
-## Debugging Tricks
+### Debugging Tricks
 Beyond using the analysis tools mentioned previously (e.g., ThreadSanitizer), there are some simple tricks that can be used to resolve programming issues relatively quicky. Firstly, switch between different backends. For example, if a program runs correctly when the backend is set to Sequential, but incorrectly when the backend is other than Sequential, it's likely that there is a race condition. Such broken code, when run repeatedly, while not always failing at the same point due to the variability of thread execution, will often fail at or near the same function, providing clues as to the location of the race. Also, empirically the STDThread backend seems to be most sensitive to race conditions. So make sure to test with more than one backend especially STDThread.
 
-## Avoid Locks
+### Avoid Locks
 Mutexes are expensive. Avoid them as much as possible. Mutexes are usually implemented as a table of locks by the kernel. They take a lot of CPU cycles to acquire. Specially, if multiple threads want to acquire them in the same parallel section. Use atomic integers if necessary. Try your best to design your algorithm without modifying the same data concurrently.
 
-## Use Atomics Sparingly
+### Use Atomics Sparingly
 Atomics are very useful and much more efficient that mutexes. However, overusing them may lead to performance issues. Try to design your algorithm in a way that you avoid locks and atomics. This also applies to using VTK classes that manipulate atomic integers such as MTime and reference count. Try to minimize operations that cause MTime or shared reference counts to change in parallel sections.
 
-## Grain Can Be Important
+### Grain Can Be Important
 In some situation, setting the right value for grain may be important. TBB does a decent job with this but there are situations where it can’t do the optimal thing. There are a number of documents on setting the grain size with TBB on the Web. If you are interested in tuning your code further, we recommend taking a look at some of them.
 
-## Minimize Data Movement
+### Minimize Data Movement
 This is true for serial parts of your code too but it is specially important when there are bunch of threads all accessing main memory. This can really push the limits of the memory bus. Code that is not very intensive computationally compared to how much memory it consumes is unlikely to scale well. Good cache use helps of course but may not be always sufficient. Try to group work together in tighter loops.
 
-## Choose Computation over Memory
+### Choose Computation over Memory
 As mentioned earlier in this document, typically computation is much cheaper than data movement. As a result, it's a good idea to create compact data structures with minimal representational fat. Such data structures may require computation to extract important information: for example, a data structure that contains a vector 3-tuple need not represent the vector magnitude since this can be quickly computed. Depending on the number of times vector magnitude is needed, the cost of computing it is usually less than the cost of placing vector magnitude into memory. Of course, effects like this are a function of scale / data size and must be considered when designing applications.
 
-## Multi-Pass Implementations
+### Multi-Pass Implementations
 Parallel algorithms often require significant bookkeeping to properly partition and transform input data to output data. Trivial algorithms, such as mapping an input vector array of 3-tuples to an output scalar array of vector magnitudes, are easy to partition and map: for each vector tuple, a single scalar is produced; and if there are N tuples, there are N scalars. However, more complex algorithms such as building cell links (creating lists of cells connected to a point) or smoothing stencils (identifying points connected to each other via a cell edge) require an initial pass to determine the size of output arrays (and then to allocate the output), followed by another pass to actually populate the output arrays. While at first counterintuitive, it turns out that allocating a small number of large memory blocks is much, much faster than many dynamic allocations of small amounts of memory. This is one reason that a common implementation pattern for parallel algorithms is to use multiple data processing passes consisting of simple computing operations. Such an approach is quite different than many serial algorithms that often perform multiple, complex algorithmic steps for each input data item to be processed.
 
 A variation of this approach is to use thread local storage to perform computation on a local range of input, store the result in thread local, and then reduce/composite the local storage into the global output. While this is problematic for many reasons (especially since data movement is needed to composite the output data), it still can be used to effectively partition and transform input data to the output, especially if the thread local storage is relatively small in size.
 
 Whatever approach is used, parallel algorithms are often implemented using multiple passes. When designing parallel algorithms, it is important to think in terms of passes, and implement algorithms accordingly.
 
-## Use Parallel Design Patterns
+### Use Parallel Design Patterns
 There are many parallel operations that are used repeatedly. Of course `for` loops and `fill()` are two obvious operations, but the `sort()` operation is more widely used than might be expected. Another is the prefix sum (or inclusive scan, or simply scan) typically used to build indices into data arrays. Become familiar with these and other parallel operations and the task of designing and implementing algorithms will be much easier.
 
-# Parallel Is Not Always Faster
+## Parallel Is Not Always Faster
 Threading introduces overhead into computation. As a result, threaded computation is not always faster than an equivalent serial operation. For example, `for` loops across a small number of data items can easily slow down computation due to **thread creation overhead**. A simple addition on each entry of an array may become a bottleneck if done using a too fine grain, due to **false sharing** (threads continuously invalidating other thread's cache). Even complex operations such as prefix sums across large amounts of data may be slower than serial implementations because of **synchronization issues**. For this reason, use threading sparingly to address data or computation of large scale. In VTK it is not uncommon to see code that switches between serial and parallel implementations based on input data size.
 
 Different backends may have significantly performance characteristics as well. TBB for example uses a thread pool combined with task stealing to address load balancing challenges. Empirically at the time of writing, in some situations TBB can significantly outperform the STDThread backend especially in situations where task loads are highly variable. Of course this may change as std::thread implementations mature and evolve.
diff --git a/Documentation/dev/git/dashboard.md b/Documentation/dev/git/dashboard.md
index d32e9d50a72663bbdb20e7cb503dd3deb778c6cb..796c45c10e63db5472cfd0afd6cf3f8b4a083053 100644
--- a/Documentation/dev/git/dashboard.md
+++ b/Documentation/dev/git/dashboard.md
@@ -1,5 +1,5 @@
-VTK Dashboard Scripts
-=====================
+Dashboard Scripts
+=================
 
 This page documents how to use the VTK `dashboard` branch in [Git][].
 See the [README](README.md) for more information.
diff --git a/Documentation/dev/git/data.md b/Documentation/dev/git/data.md
index 54c599cb1a0de71668dd7f5033bcc8dfeec2e2c0..599d02382e09906eee79a05f42a32cabc0b00e7d 100644
--- a/Documentation/dev/git/data.md
+++ b/Documentation/dev/git/data.md
@@ -1,5 +1,5 @@
-VTK Data
-========
+Test Data
+=========
 
 This page documents how to add test data while developing VTK with [Git][].
 See the [README](README.md) for more information.
@@ -10,7 +10,7 @@ Setup
 -----
 
 The workflow below depends on local hooks to function properly.
-Follow the main [developer setup instructions](develop.md#setup)
+Follow the main [developer setup instructions](develop.md#initial-setup)
 before proceeding.  In particular, run [SetupForDevelopment.sh][]:
 
     $ ./Utilities/SetupForDevelopment.sh
diff --git a/Documentation/dev/git/deprecation.md b/Documentation/dev/git/deprecation.md
index 1cc1c8fbd8588ff7c7687feeaca488aa5952b390..7b95657676099982139400fd7c302d01882f4b68 100644
--- a/Documentation/dev/git/deprecation.md
+++ b/Documentation/dev/git/deprecation.md
@@ -1,5 +1,5 @@
-VTK Deprecation Process
-=======================
+Deprecation Process
+===================
 
 This page documents how to deprecate an API and mark it as no longer necessary
 for downstream consumers of VTK.
diff --git a/Documentation/dev/git/develop.md b/Documentation/dev/git/develop.md
index 8b50e63b4f57b245c92080506527dcf9ec1324cf..6bb9fa779cc254f3d49aa249e86e455af5bc2d06 100644
--- a/Documentation/dev/git/develop.md
+++ b/Documentation/dev/git/develop.md
@@ -1,5 +1,5 @@
-Develop VTK
-===========
+Develop
+=======
 
 This page documents how to develop VTK using [GitLab][] and [Git][].
 See the [README](README.md) for more information.
diff --git a/Domains/Microscopy/readme.md b/Domains/Microscopy/readme.md
index 6004ad4ca25bbd38388c934d3d47dcc873f73507..6647e9b7a9f249677d9b9a6abae674cbc1f1798a 100644
--- a/Domains/Microscopy/readme.md
+++ b/Domains/Microscopy/readme.md
@@ -4,5 +4,5 @@
 - Mainly from microscopy domain
 - Requires openslide libraries for building
 
-# Known issues
+## Known issues
 - Ubuntu 14.04 contains incorrectly patched version of openjpeg (dependency of openslide), and thus openslide is unable to decode certain .svs files. This issue is not present in later versions of ubuntu or fedora 23.
diff --git a/IO/Cesium3DTiles/README.md b/IO/Cesium3DTiles/README.md
index 42d7dab0767f53fc028e3df9f661d58d51791573..79c931bc34ae0d0ae655c4b62fb61928c7f69b9d 100644
--- a/IO/Cesium3DTiles/README.md
+++ b/IO/Cesium3DTiles/README.md
@@ -4,14 +4,14 @@ Currently, to create a valid 3D Tiles dataset we may need additional
 conversions: from GLTF to GLB and from GLB to B3DM. We can use
 JavaScript tools to do these conversions.
 
-# Install conversion and validation scripts
+## Install conversion and validation scripts
 - Using node and npm installed on Ubuntu 20.04:
 - `cd ~/external/3d-tiles-tools/;npm install 3d-tiles-tools`. Help at: <https://github.com/AnalyticalGraphicsInc/3d-tiles-tools/tree/master/tools>
 - `cd ~/external/gltf-pipeline;npm install gltf-pipeline`. Help at: <https://github.com/CesiumGS/gltf-pipeline>
 - Clone <https://github.com/CesiumGS/3d-tiles-samples>. and then `npm install.`
 - Clone <https://github.com/KhronosGroup/glTF-Validator> and then follow Building section.
 
-# Convert data to GLB or B3DM - Optional
+## Convert data to GLB or B3DM - Optional
 See Testing/Cxx/Test3DTilesWriter for conversions of Jacksonville data
 stored in OBJs and or Berlin data stored in CityGML.
 Note that the test saves the 3D Tiles data using GLTF files.
@@ -37,7 +37,7 @@ find . -name '*.glb' -exec bash -c 'nodejs ~/external/3d-tiles-tools/tools/bin/3
 find . -name '*.glb' -exec rm {} \;
 
 ```
-# View in Cesium
+## View in Cesium
 1. Use 3d-tiles-samples
   - Link the tileset created for previous set:
   `cd ~/external/3d-tiles-samples/tilesets; ln -s ~/projects/VTK/build/Testing/Temporary/jacksonville-3dtiles`
@@ -46,7 +46,7 @@ find . -name '*.glb' -exec rm {} \;
   `cd ..;npm start`
 2. `google-chrome jacksonville-3dtiles.html;google-chrome berlin-3dtiles.html`
 
-# Test the tilesets using 3d-tiles-validator
+## Test the tilesets using 3d-tiles-validator
 ```
 cd ~/external/3d-tiles-validator/validator/
 node ./bin/3d-tiles-validator.js -i ~/projects/VTK/build/Testing/Temporary/jacksonville-3dtiles-points/tileset.json
diff --git a/Rendering/OpenXRRemoting/README.md b/Rendering/OpenXRRemoting/README.md
index db504dc01fadd7756b1002be15d2cdd4d6ec8948..0abaa910743a6d6232b6d1a1730334f5fbc38109 100644
--- a/Rendering/OpenXRRemoting/README.md
+++ b/Rendering/OpenXRRemoting/README.md
@@ -5,7 +5,7 @@ The remote application receives camera information and rendering resources from
 This way we avoid the need to build VTK for Universal Windows Platform (UWP), and we can also keep using VTK's OpenGL-based rendering pipeline.<br/>
 Still, DirectX must be used to fill the texture to be streamed back to the Hololens. This is possible by creating a texture shared by both a DirectX and an OpenGL context, thanks to the NV_DX_interop extension available on almost every recent GPU.
 
-# Player application
+## Player application
 
 - Download the Microsoft MixedReality HolographicRemoting [samples](https://github.com/microsoft/MixedReality-HolographicRemoting-Samples) and follow the instruction to build the player application.<br/>
   ⚠️ The version number in the branch name **must** match the version of the `Microsoft.Holographic.Remoting.OpenXr` package used below by the remote application.
@@ -15,7 +15,7 @@ Still, DirectX must be used to fill the texture to be streamed back to the Holol
 
 - When the player is deployed, you should see the following message: `Waiting for connection on XX.XX.XX.XX` where *XX.XX.XX.XX* describes the IP address the remote application should connect to.
 
-# Remote application
+## Remote application
 
 - Enable the CMake option `VTK_MODULE_ENABLE_VTK_RenderingOpenXRRemoting` when building VTK.
 
@@ -32,7 +32,7 @@ Still, DirectX must be used to fill the texture to be streamed back to the Holol
   The address of the player application to connect to must be set using `vtkOpenXRRemotingRenderWindow::SetRemotingIPAddress("XX.XX.XX.XX")` before starting the interactor.<br/>
   See the TestOpenXRRemotingInitialization test for a complete example.
 
-# Troubleshooting:
+## Troubleshooting:
 
 > The OpenXR runtime fails to create and initialize the XrInstance.
 
diff --git a/ThirdParty/UPDATING.md b/ThirdParty/UPDATING.md
index 59938d9e7d51afcc1584355e652e69bb781501c0..695b032081ff4051db86480ab962023101606c42 100644
--- a/ThirdParty/UPDATING.md
+++ b/ThirdParty/UPDATING.md
@@ -12,13 +12,13 @@ this setup.
 Any updates to projects not listed there should first convert over to this
 framework.
 
-# Updating a Project Upstream
+## Updating a Project Upstream
 
 Ideally, any code changes to third party code should first be submitted to the upstream
 project using whatever workflow they prefer or require.  Once that is done, the changes
 can next be brought into VTK.
 
-# Updating the Import
+## Updating the Import
 
 Examine the project's `update.sh` script and note the value of the `repo=` field.
 
@@ -42,7 +42,7 @@ $ git push
 When deciding what to rebase, you should generally use
 the first commit in the current history that isn't upstream.
 
-# Updating a Project into VTK
+## Updating a Project into VTK
 
 Bringing changes into VTK involves first deciding what to bring in. That is specified in the
 `update.sh` script under the `tag=` field. Usually this is a `for/vtk` branch, but may
@@ -68,7 +68,7 @@ simplify the availability of the commits to the main checkout.)
 
 Now you can review the change and make a merge request from the branch as normal.
 
-# Porting a Project
+## Porting a Project
 
 When converting a project, if there are any local patches, a project should be
 created [on Kitware's GitLab](https://gitlab.kitware.com/third-party) to track it
@@ -129,7 +129,7 @@ On Windows, run:
 Also add an entry to [imported.md](imported.md) for the project, and
 `CMakeLists.txt` and `module.cmake` as appropriate.
 
-# Process
+## Process
 
 The basic process involves a second branch where the third party project's
 changes are tracked. This branch has a commit for each time it has been
diff --git a/Wrapping/Tools/README.md b/Wrapping/Tools/README.md
index 02be2b5e5df50bfdfc4edee1a0b7035ecb71f808..373ae4962df8c0672f5c9cfd8efff72fa59c8c42 100644
--- a/Wrapping/Tools/README.md
+++ b/Wrapping/Tools/README.md
@@ -1,4 +1,4 @@
-# The Wrapping Tools
+# Wrapping Tools
 
 The wrapping tools consist of executables that pull information from C++
 header files, and produce wrapper code that allows the C++ interfaces to