\n",
- "![](\"images/reductions/3D-cube-plane.png\")
\n",
- "
\n",
- "\n",
- "By default, Blosc2 chooses the chunk size so that it fits in the CPU cache (e.g. 8 MB); it then selects the chunk shape according to the NumPy convention of storing data row-wise, so that data that is contiguous within chunks is also contiguous in the full array. Hence, for the 3D case above (shown schematically in the figure), the default chunk shape, shown in pink, is (1, 1000, 1000). Since the array elements are of type ``float64`` they each occupy 8 bytes, and so the chunk is of size `8 * 1 * 1000 * 1000 = 8MB`. While chunking the data like this often speeds up computations and operations, in the case of reductions, it means that reduction times along different axes will not be the same, as the sizes are not uniform.\n",
- "\n",
- "The difference in cost while traversing data values can be visualized via some schematic diagrams.\n",
- "\n",
- "**Reducing along the X axis**\n",
- "\n",
- "\n",
- "![](\"images/reductions/memory-access-2D-x.png\")
\n",
- "
\n",
- "\n",
- "When accessing a chunk, the CPU can access the values from memory sequentially, but they need to be stored in an accumulator. Each chunk needs to be fetched from memory and each element added to the accumulator. If the size of the accumulator is large (in this case `1000 * 1000 * 8 = 8 MB`), it does not fit in low level CPU caches, making this fetching, decompression and addition a slow procedure.\n",
- "\n",
- "**Reducing along the Y axis**\n",
- "\n",
- "\n",
- "![](\"images/reductions/memory-access-2D-y.png\")
\n",
- "
\n",
- "\n",
- " When accessing a chunk the CPU again accesses these values from memory sequentially but, contrarily to the case above, there is no need for an accumulator as the sum of the chunk along the Y axis already gives a row of the final result. So, although the number of sum operations is the same as above, the required time is smaller because there is no need to update *all* the values of an accumulator per chunk, which reduces the time spent communicating between cache and processor.\n",
- "\n",
- "### Tweaking the chunk shape\n",
- "\n",
- "\n",
- "\n",
- "![](\"images/reductions/3D-cube.png\")
\n",
- "
\n",
- "\n",
- "However, when Blosc2 is instructed to create chunk shapes that are more uniform along all axes (`chunks=(200, 200, 100)`), the situation changes. In this case, an accumulator is needed for each subcube, but it is smaller (either `200 * 100 * 8 = 160 KB` or, for the Z-axis reduction, ``320KB`` ) and fits in L2, which is faster than L3 (scenario above). Since the chunk shape is nearly isomorphic, no axis is preferred and hence the performance is similar for all of them.\n",
- "\n",
- "It is interesting to note that, when using compression, Blosc2 performance is similar to NumPy along *all* axes, except for the X axis, where performance is a bit better. This fact is even more interesting since the same underlying NumPy reduction machinery is used for each chunk by Blosc2 as well. This is a nice side effect of compression; see below."
- ]
- },
- {
- "cell_type": "markdown",
- "id": "a1deee3b4faacc14",
- "metadata": {},
- "source": [
- "### Effects of using different codecs in Python-Blosc2\n",
- "\n",
- "Compression and decompression consume CPU and memory resources, however different codecs and configurations impact the use of these resources in different ways, and so it can be a good idea to alter the configuration to choose the most efficient option for the operating environment.\n",
- "\n",
- "When compression is not applied, data is stored and accessed as-is, which saves the time spent on compression and decompression; however, especially if the data is large, the resulting higher memory usage can result in longer access times. Compression reduces the size of the data in memory and storage, which can improve performance when reading and writing data; but one then requires additional CPU time for compression and decompression. Therefore, it is important to find the right balance between reduced size and processing time to give overall optimal performance.\n",
- "\n",
- "In the plots above, we can see how using the LZ4 codec strikes such a balance, as it achieves the best performance in general, exceeding the performance for uncompressed data. This is because LZ4 is tuned towards speed, and so the time to compress and decompress the data is very low (recall the discussion in [tutorial 1](./01.ndarray-basics.html)). On the other hand, ZSTD is a codec that is optimized for compression ratio, but is consequently a bit slower. However, it is still faster than the uncompressed case, as the reduced memory transmission time compensates for the additional CPU time required for compression and decompression.\n",
- "\n",
- "There are many compression parameters that can be tuned in Blosc2. You can use the `CParams` object with the different parameters in [CParams reference](https://www.blosc.org/python-blosc2/reference/autofiles/storage/blosc2.CParams.html#blosc2.CParams) to set the compression level, codec, filters and other parameters. We also offer automated parameter selection via the [Btune neural network tool](https://ironarray.io/btune) that, depending on your requirements for compression/decompression speed, compression ratio, or lossiness of compression, tries to select the best parameters for your application and CPU resources."
- ]
- },
- {
- "cell_type": "markdown",
- "id": "106d7af6d1a6cedc",
- "metadata": {},
- "source": [
- "## Conclusion\n",
- "\n",
- "Understanding the balance between minimising storage space and the additional time required to process the data is important. Testing different compression settings can help you obtain the best trade-off between reduced size and processing time. However, as a first approximation (without requiring the user to weigh up the particulars of their CPU cache structure), the default Blosc2 parameters are not too bad, since the chunk shape is automatically selected based on the CPU cache size. As we have seen, it is also easy to fine tune the chunk shape if necessary for the desired application.\n",
- "\n",
- "Besides the ``sum`` reduction examined here, Blosc2 supports the main reduction operations (``mean``, ``std``, ``min``, ``max``, ``all``, ``any``, etc.), and you are invited to [explore them](../../reference/reduction_functions.html).\n",
- "\n",
- "Although we didn't review it explicitly here, it is possible to use reductions even for very large arrays that are stored on disk, as is the case for the lazy expressions and functions we have seen in previous tutorials. This is immensely powerful for data analysis on large datasets, offering efficient computations for data compressed on-disk with minimal memory usage. We will explore this in a forthcoming tutorial."
- ]
- }
- ],
- "metadata": {
- "kernelspec": {
- "display_name": "Python 3 (ipykernel)",
- "language": "python",
- "name": "python3"
- },
- "language_info": {
- "codemirror_mode": {
- "name": "ipython",
- "version": 3
- },
- "file_extension": ".py",
- "mimetype": "text/x-python",
- "name": "python",
- "nbconvert_exporter": "python",
- "pygments_lexer": "ipython3",
- "version": "3.13.5"
- }
- },
- "nbformat": 4,
- "nbformat_minor": 5
-}
diff --git a/doc/getting_started/tutorials/05.persistent-reductions.ipynb b/doc/getting_started/tutorials/05.persistent-reductions.ipynb
deleted file mode 100644
index ddaedec19..000000000
--- a/doc/getting_started/tutorials/05.persistent-reductions.ipynb
+++ /dev/null
@@ -1,335 +0,0 @@
-{
- "cells": [
- {
- "cell_type": "markdown",
- "id": "79426a2f11e6c3cb",
- "metadata": {},
- "source": [
- "# Advanced Lazy Expressions and Persistent Reductions\n",
- "\n",
- "We're now going to more fully detail Blosc2’s capabilities for lazy computation in Python. In previous tutorials we have hinted at the power of lazy expressions, and in this tutorial we'll demonstrate exactly how lazy expressions optimize performance by deferring computations. Postponing the computation of the expression until it is actually needed means we can avoid large in-memory temporaries, optimizing memory usage and processing.\n",
- "\n",
- "However, as mentioned previously, reductions are always computed eagerly when using regular Python expressions with Blosc2 operands. Thus, imprudent use of them could render the lazy expression technique ineffective. Fortunately Blosc2 implements a method to avoid eager computations even when calculating reductions by using a string version of the expression in combination with the `blosc2.lazyexpr` constructor. We will show how to create and save a lazy expression in this way, and then compute it to obtain the desired results.\n",
- "\n",
- "We'll also provide some examples which show how powerful broadcasting can be in Blosc2, and how we can use it to get metadata about the result of a lazy expression without performing the full computation. Access to structural information of the computation result, such as shape and dtype, is hence rapid - even for arbitrarily large arrays. Finally, we'll demonstrate how such metadata will dynamically adapt to changes in the dimensions and values of the original operands, stored on disk.\n",
- "\n"
- ]
- },
- {
- "cell_type": "markdown",
- "id": "f8c69fe846b1e13d",
- "metadata": {},
- "source": [
- "## Operands as arrays of different shape\n",
- "\n",
- "We will now create the operands, using a different shape for each of them - remember that this is no problem for Blosc2, which fully supports broadcasting, including for lazy expressions."
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 1,
- "id": "initial_id",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-04T11:57:04.636699Z",
- "start_time": "2025-08-04T11:57:04.339091Z"
- }
- },
- "outputs": [],
- "source": [
- "import time\n",
- "\n",
- "import blosc2\n",
- "\n",
- "# Define dimensions of arrays\n",
- "dim_a = (200, 300, 400) # 3D array\n",
- "dim_b = (200, 400) # 2D array\n",
- "dim_c = 400 # 1D array\n",
- "\n",
- "# Create arrays with specific dimensions and values\n",
- "a = blosc2.full(dim_a, 1, urlpath=\"a.b2nd\", mode=\"w\")\n",
- "b = blosc2.full(dim_b, 2, urlpath=\"b.b2nd\", mode=\"w\")\n",
- "c = blosc2.full(dim_c, 3, urlpath=\"c.b2nd\", mode=\"w\")"
- ]
- },
- {
- "cell_type": "markdown",
- "id": "7a6a6d076255afaf",
- "metadata": {},
- "source": [
- "## Creating and using a string lazy expression\n",
- "\n",
- "First, let's build a string expression that sums the contents of array `a` and performs a multiplication with `b` and `c`. In this context, creating a string version of the expression is critical; otherwise, the sum reduction will be computed eagerly.\n",
- "\n",
- "We may then convert the string to a ``LazyExpr`` object using the `blosc2.lazyexpr` constructor, along with a dictionary which maps the names of the operands within the expression to their corresponding arrays. Since the operands are saved on disk, recall that we can also save the expression to disk.\n"
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 2,
- "id": "b8f05b87b99d38ec",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-04T11:57:04.723139Z",
- "start_time": "2025-08-04T11:57:04.644938Z"
- }
- },
- "outputs": [],
- "source": [
- "# Expression that sums all elements of 'a' and multiplies 'b' by 'c'\n",
- "expression = \"a.sum() + b * c\"\n",
- "# Define the operands for the expression\n",
- "operands = {\"a\": a, \"b\": b, \"c\": c}\n",
- "# Create a lazy expression\n",
- "lazy_expression = blosc2.lazyexpr(expression, operands)\n",
- "# Save the lazy expression to the specified path\n",
- "url_path = \"my_expr.b2nd\"\n",
- "lazy_expression.save(urlpath=url_path, mode=\"w\")"
- ]
- },
- {
- "cell_type": "markdown",
- "id": "87d517ab1f3ec0fa",
- "metadata": {},
- "source": [
- "#### Result Metadata\n",
- "Note that even though the expression has not been computed, we can access some metadata for the computation result, such as its shape and dtype. On creation, a ``LazyExpr`` object uses operand metadata and casting and broadcasting rules to work out some information about the result."
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 3,
- "id": "632aacd442588477",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-04T11:57:04.818224Z",
- "start_time": "2025-08-04T11:57:04.810162Z"
- }
- },
- "outputs": [
- {
- "name": "stdout",
- "output_type": "stream",
- "text": [
- "Result will have shape (200, 400) and dtype int64\n"
- ]
- }
- ],
- "source": [
- "print(f\"Result will have shape {lazy_expression.shape} and dtype {lazy_expression.dtype}\")"
- ]
- },
- {
- "cell_type": "markdown",
- "id": "26a1fb93b2faf5a",
- "metadata": {},
- "source": [
- "\n",
- "\n",
- "**REFRESHER**: Broadcasting allows arrays of different shapes (dimensions) to align for mathematical operations, such as addition or multiplication, without the need to enlarge operands by replicating data. The main idea is that smaller dimensions are \"stretched\" to larger dimensions in such a way that the operation may be performed consistently.\n",
- "\n",
- "\n",
- "![](\"images/lazyexpr-broadcast.png\")
\n",
- "\n",
- "See the [NumPy docs on broadcasting](https://numpy.org/doc/stable/user/basics.broadcasting.html) for more information.\n",
- "\n",
- "#### Computing the lazy expression\n",
- "Now that we have saved the expression, we can open and compute it to obtain the result. Let's see how this is done."
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 4,
- "id": "86b48c7707cea2a7",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-04T11:57:04.990126Z",
- "start_time": "2025-08-04T11:57:04.849352Z"
- }
- },
- "outputs": [
- {
- "name": "stdout",
- "output_type": "stream",
- "text": [
- "(o0.sum() + o1 * o2)\n",
- "(200, 400)\n",
- "Time to get shape:0.00012\n",
- "Time to compute:0.09958\n",
- "Result of the operation (slice):\n",
- "[[24000006 24000006 24000006 24000006]\n",
- " [24000006 24000006 24000006 24000006]]\n"
- ]
- }
- ],
- "source": [
- "lazy_expression = blosc2.open(urlpath=url_path)\n",
- "# Print the lazy expression and its shape\n",
- "print(lazy_expression)\n",
- "t1 = time.time()\n",
- "print(lazy_expression.shape)\n",
- "t2 = time.time()\n",
- "print(f\"Time to get shape:{t2 - t1:.5f}\")\n",
- "t1 = time.time()\n",
- "result1 = lazy_expression.compute()\n",
- "t2 = time.time()\n",
- "print(f\"Time to compute:{t2 - t1:.5f}\")\n",
- "print(\"Result of the operation (slice):\")\n",
- "print(result1[:2, :4]) # Print a small slice of the result for demonstration"
- ]
- },
- {
- "cell_type": "markdown",
- "id": "362cfd5eb88b9bb6",
- "metadata": {},
- "source": [
- "As we can observe when printing the lazy expression and its shape, the time required to get the `shape` is significantly shorter than the time to compute the result. This is because `lazy_expression.shape` does not need to compute all the elements of the expression; instead, it only accesses the **metadata** of the operands, from which it infers the necessary information about the dimensions and type of the result.\n",
- "\n",
- "Thanks to this metadata, if we know the dimensions of the arrays involved in the operation (such as in the case of `a.sum() + b * c`), Blosc2 can **quickly infer the resulting shape** without performing intensive calculations. This allows for fast access to structural information (like the `shape` and `dtype`) without operating on the actual data.\n",
- "\n",
- "In contrast, when we call `lazy_expression.compute()`, all the necessary operations to calculate the final result are executed. Here is where the real computation takes place, and as we can see from the time, this process takes longer."
- ]
- },
- {
- "cell_type": "markdown",
- "id": "a19ba0d14053d1a0",
- "metadata": {},
- "source": [
- "## Dynamic adaptation and lazy expressions\n",
- "\n",
- "In this section, we will see how persisted lazy expressions automatically adapt to changes in the dimensions and values of the original operands, such as the arrays `a` and `b`."
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 5,
- "id": "61bcd7d60ec69004",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-04T11:57:05.284431Z",
- "start_time": "2025-08-04T11:57:05.005080Z"
- }
- },
- "outputs": [
- {
- "name": "stdout",
- "output_type": "stream",
- "text": [
- "(300, 400)\n",
- "Time to get shape:0.00020\n",
- "Time to compute:0.13406\n",
- "Result of the operation (slice):\n",
- "[[60000006 60000006 60000006 60000006]\n",
- " [60000006 60000006 60000006 60000006]]\n"
- ]
- }
- ],
- "source": [
- "# Resizing arrays and updating values to see changes in the expression result\n",
- "a.resize((300, 300, 400))\n",
- "a[200:300] = 3\n",
- "b.resize((300, 400))\n",
- "b[200:300] = 5\n",
- "# Open the saved file\n",
- "lazy_expression = blosc2.open(urlpath=url_path)\n",
- "t1 = time.time()\n",
- "print(lazy_expression.shape)\n",
- "t2 = time.time()\n",
- "print(f\"Time to get shape:{t2 - t1:.5f}\")\n",
- "t1 = time.time()\n",
- "result2 = lazy_expression.compute()\n",
- "t2 = time.time()\n",
- "print(f\"Time to compute:{t2 - t1:.5f}\")\n",
- "print(\"Result of the operation (slice):\")\n",
- "print(result2[:2, :4])"
- ]
- },
- {
- "cell_type": "markdown",
- "id": "d82492bf518c5a39",
- "metadata": {},
- "source": [
- "After increasing the dimensions of the original arrays by modifying the values of `a` and `b`, we *reopen* the lazy expression (although we do not modify it explicitly). Upon reopening, the lazy expression updates its operand references to refer to the new operand values. From there, we can see that the metadata and final result indeed reflect the changes in the array operands. As before, obtaining the updated structural information (the `shape`) of the expression is a quick process, since using updated **metadata** bypasses the need to do the full computation with the new operands (which takes more time).\n",
- "\n",
- "Note that the dynamic adaptation of lazy expressions to changes in the operands is not limited to the string lazy expression interface; it also works just as well with the Python expression interface we have seen in the other tutorials:"
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 6,
- "id": "d5169ae83e2c0802",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-04T11:57:05.354938Z",
- "start_time": "2025-08-04T11:57:05.296934Z"
- }
- },
- "outputs": [
- {
- "name": "stdout",
- "output_type": "stream",
- "text": [
- "Old a: [ 1 2 3 4 5 6 7 8 9 10]\n",
- "New a: [11 12 13 14 15 16 17 18 19 20]\n"
- ]
- }
- ],
- "source": [
- "a = blosc2.arange(0, 10, urlpath=\"a.b2nd\", mode=\"w\")\n",
- "lexpr = a + 1\n",
- "print(f\"Old a: {lexpr[:]}\")\n",
- "a = blosc2.arange(10, 20, urlpath=\"a.b2nd\", mode=\"w\")\n",
- "print(f\"New a: {lexpr[:]}\") # This will still compute the original expression"
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 7,
- "id": "9087d47c90af03ba",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-04T11:57:05.389151Z",
- "start_time": "2025-08-04T11:57:05.384494Z"
- }
- },
- "outputs": [],
- "source": [
- "# Clean up the created files\n",
- "blosc2.remove_urlpath(\"a.b2nd\")\n",
- "blosc2.remove_urlpath(\"b.b2nd\")\n",
- "blosc2.remove_urlpath(\"c.b2nd\")\n",
- "blosc2.remove_urlpath(\"my_expr.b2nd\")"
- ]
- },
- {
- "cell_type": "markdown",
- "id": "776fbc7e82d5477f",
- "metadata": {},
- "source": [
- "## Conclusion\n",
- "\n",
- "The dynamic adaptation of lazy expressions to changes in the dimensions of array operands illustrates the power of deferred computations in Blosc2. By deferring the computation of expressions until necessary, Blosc2 can quickly access structural information about the result, such as the `shape` and `dtype`, even when operands **change** on disk, without performing intensive calculations. We can also avoid memory-starving temporaries, freeing up resources for the truly necessary computation steps. Broadcasting support also facilitates working with arrays of different sizes offering a powerful and intuitive interface for defining expressions.\n"
- ]
- }
- ],
- "metadata": {
- "kernelspec": {
- "display_name": "Python 3 (ipykernel)",
- "language": "python",
- "name": "python3"
- },
- "language_info": {
- "codemirror_mode": {
- "name": "ipython",
- "version": 3
- },
- "file_extension": ".py",
- "mimetype": "text/x-python",
- "name": "python",
- "nbconvert_exporter": "python",
- "pygments_lexer": "ipython3",
- "version": "3.13.5"
- }
- },
- "nbformat": 4,
- "nbformat_minor": 5
-}
diff --git a/doc/getting_started/tutorials/06.remote_proxy.ipynb b/doc/getting_started/tutorials/06.remote_proxy.ipynb
deleted file mode 100644
index a77c9bc9f..000000000
--- a/doc/getting_started/tutorials/06.remote_proxy.ipynb
+++ /dev/null
@@ -1,396 +0,0 @@
-{
- "cells": [
- {
- "cell_type": "markdown",
- "id": "a33c4f0335308f35",
- "metadata": {},
- "source": [
- "# Using Proxies for Efficient Handling of Remote Multidimensional Data\n",
- "\n",
- "When working with large datasets, a common problem is that they must be stored remotely, or on-disk, since they are too large to fit in memory. Doing so frees up memory for calculations with the data, but transfer times between the processor and the stored data can then cause bottlenecks. Blosc2 offers a way to manage this via proxies, and thus obtain the typical speedups associated with caching and in-memory storage of data, whilst still storing the dataset remotely/on-disk. This means we can mitigate the trade-off between storage space and execution time.\n",
- "\n",
- "In this tutorial, we will look at how to access and cache data for calculation using the `fetch` and `__getitem__` methods implemented in the ``Proxy`` class, the main Blosc2 proxy implementation. Through this comparison, we will gain a better understanding of how to optimize data access, as measured by the execution time of these retrieval operations. We will also measure the size of the local proxy file, to verify the efficiency of data management and storage. Get ready to dive into the fascinating world of data caching!"
- ]
- },
- {
- "cell_type": "code",
- "id": "92755a11cc34e834",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T07:15:07.437077Z",
- "start_time": "2025-08-05T07:15:07.068229Z"
- }
- },
- "source": [
- "import asyncio\n",
- "import os\n",
- "import time\n",
- "\n",
- "import blosc2\n",
- "from blosc2 import ProxyNDSource"
- ],
- "outputs": [],
- "execution_count": 1
- },
- {
- "cell_type": "markdown",
- "id": "5ee57ce91fc28bbd",
- "metadata": {},
- "source": [
- "## ``C2Array`` class\n",
- "Before we look at proxies, it is first necessary to understand how to use Blosc2 to work with remote data, via the ``C2Array`` class. The class implements a (limited) version of the NDArray interface of which we have already seen a lot in previous tutorials. However, it is really a local pointer to a remote array (stored e.g. on a remote server). This means that we can refer to the data, access certain attribute information about it, download portions of the data and even define it in computational expressions, without having to download the entire array into local memory or disk. This is particularly useful when working with large datasets that cannot fit into memory or would take far too long to transfer over the network.\n",
- "\n",
- "However, one limitation of this approach is that every time one wants to download a slice of the dataset, the data is fetched over the network - even if the same slice has been downloaded before. This can lead to inefficiencies, especially when working with large datasets or when the same data is accessed multiple times. Proxies offer a solution to this, whilst still preserving the low storage requirements of the ``C2Array`` class.\n",
- "\n",
- "## Proxy Classes for Data Access\n",
- "The [``Proxy`` class](../../reference/proxy.rst) in Blosc2 is a design pattern that acts as an intermediary between a (typically local) client and (typically remote or on-disk) real data containers, enabling more efficient access to the latter. Its primary objective is to provide a *caching mechanism* for effectively accessing data stored in remote/on-disk containers that utilize the ``ProxySource`` or ``ProxyNDSource`` interfaces, which serve as templates for defining custom proxy classes - in themselves they cannot be used directly, as they are abstract classes.\n",
- "\n",
- "We are going to define our own ``MyProxySource`` proxy class that will inherit from and implement the ``ProxyNDSource`` interface; it will be responsible for downloading and storing only the requested chunks, progressively filling the cache as the user accesses the data."
- ]
- },
- {
- "cell_type": "code",
- "id": "bab50ca19740a1aa",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T07:15:07.455294Z",
- "start_time": "2025-08-05T07:15:07.450249Z"
- }
- },
- "source": [
- "def get_file_size(filepath):\n",
- " \"\"\"Returns the file size in megabytes.\"\"\"\n",
- " return os.path.getsize(filepath) / (1024 * 1024)\n",
- "\n",
- "\n",
- "class MyProxySource(ProxyNDSource):\n",
- " def __init__(self, data):\n",
- " self.data = data\n",
- " print(f\"Data shape: {self.shape}, chunks: {self.chunks}, dtype: {self.dtype}\")\n",
- "\n",
- " @property\n",
- " def shape(self):\n",
- " return self.data.shape\n",
- "\n",
- " @property\n",
- " def chunks(self):\n",
- " return self.data.chunks\n",
- "\n",
- " @property\n",
- " def blocks(self):\n",
- " return self.data.blocks\n",
- "\n",
- " @property\n",
- " def dtype(self):\n",
- " return self.data.dtype\n",
- "\n",
- " # This method must be present\n",
- " def get_chunk(self, nchunk):\n",
- " return self.data.get_chunk(nchunk)\n",
- "\n",
- " # This method is optional\n",
- " async def aget_chunk(self, nchunk):\n",
- " await asyncio.sleep(0.1) # simulate an asynchronous operation\n",
- " return self.data.get_chunk(nchunk)"
- ],
- "outputs": [],
- "execution_count": 2
- },
- {
- "cell_type": "markdown",
- "id": "32fffd14035b20c4",
- "metadata": {},
- "source": "Next, we will establish a connection to a [multidimensional array stored remotely](https://cat2.cloud/demo/roots/@public/examples/lung-jpeg2000_10x.b2nd?roots=%40public) on a [Cat2Cloud](https://ironarray.io/cat2cloud) demo server (https://cat2.cloud/demo). The ``remote_array`` variable will represent this dataset on the server, via a ``C2Array``, enabling us to access the information without the need to load all the data into local memory at once."
- },
- {
- "cell_type": "code",
- "id": "aa92e842ec2a2fd7",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T07:15:07.770098Z",
- "start_time": "2025-08-05T07:15:07.461995Z"
- }
- },
- "source": [
- "urlbase = \"https://cat2.cloud/demo\"\n",
- "path = \"@public/examples/lung-jpeg2000_10x.b2nd\"\n",
- "remote_array = blosc2.C2Array(path, urlbase=urlbase)"
- ],
- "outputs": [],
- "execution_count": 3
- },
- {
- "metadata": {},
- "cell_type": "markdown",
- "source": [
- "Although it is not as useful, note that a ``MyProxySource`` instance could also be constructed with an ``NDArray`` object stored on-disk, so that one can cache parts of the array in-memory for quicker access. In either case, the data of the ``C2Array``/``NDArray`` is linked by the ``MyProxySource`` instance to a local ``Proxy`` instance (instantiated using the source) acting as an in-memory cache for the data.\n",
- "\n",
- "![\"Descripción](\"images/proxyconnection.png\")
\n"
- ],
- "id": "4ad1a8da2f9b3e49"
- },
- {
- "cell_type": "code",
- "id": "9360ba9e4f946fe0",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T07:15:07.905918Z",
- "start_time": "2025-08-05T07:15:07.898829Z"
- }
- },
- "source": [
- "# Define a local file path to save the proxy container\n",
- "local_path = \"local_proxy_container.b2nd\"\n",
- "source = MyProxySource(remote_array)\n",
- "proxy = blosc2.Proxy(source, urlpath=local_path, mode=\"w\")\n",
- "print(f\"Proxy of type {type(proxy)} has shape {proxy.shape}, chunks {proxy.chunks} and dtype {proxy.dtype}\")\n",
- "initial_size = get_file_size(local_path)\n",
- "print(f\"Initial local file size: {os.path.getsize(local_path)} bytes\")"
- ],
- "outputs": [
- {
- "name": "stdout",
- "output_type": "stream",
- "text": [
- "Data shape: (10, 1248, 2689), chunks: (1, 1248, 2689), dtype: uint16\n",
- "Proxy of type ![\"Descripción](\"images/remote_proxy.png\")
\n",
- "\n",
- "Although `fetch` and `__getitem__` have distinct functions, they work together to facilitate efficient access to data. `fetch` manages the loading of data into the local cache by checking if the necessary chunks are available. If they are not, it downloads them from the remote source i to the proxy cache for future access.\n",
- "\n",
- "On the other hand, `__getitem__` handles the indexing and retrieval of data through a **NumPy** array, allowing access to specific subsets. Before accessing the data, `__getitem__` calls `fetch` to ensure that the necessary chunks are in the cache. If the data is not present in the cache, `fetch` takes care of downloading it from its original location (for example, from disk or an external source). This ensures that when `__getitem__` performs the indexing operation, it has immediate access to the data without interruptions.\n",
- "\n",
- "An important detail is that, while both `fetch` and `__getitem__` ensure the necessary data is available, they may download more information than required because they download entire chunks (and not just the required slice). However, this can be advantageous for two reasons. Firstly, often one wants to access multiple slices of large remote arrays within a script, and thus slices may overlap with already-downloaded chunks from a previous ``fetch``; by fetching the whole chunk in the first slice, one already has the data locally for future slice commands, thus implementing an efficient data **prefetcher**. Secondly, by sending the whole (compressed) chunk, the data is always compressed during the complete workflow (file transfer and storage), which reduces storage space, file transfer time, and processing overheads."
- ]
- },
- {
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T08:16:18.840302Z",
- "start_time": "2025-08-05T08:16:18.809389Z"
- }
- },
- "cell_type": "code",
- "source": [
- "# clean up\n",
- "blosc2.remove_urlpath(\"local_proxy_container.b2nd\")"
- ],
- "id": "6c1a7c0c0d970219",
- "outputs": [],
- "execution_count": 8
- },
- {
- "cell_type": "markdown",
- "id": "432c728702703cd8",
- "metadata": {},
- "source": [
- "## About the remote dataset\n",
- "\n",
- "The remote dataset is available [online](https://cat2.cloud/demo/roots/@public/examples/lung-jpeg2000_10x.b2nd?roots=%40public). You may want to explore the data values by clicking on the *Data* tab; this dataset is actually a tomography of a lung, which you can visualize by clicking on the *Tomography* tab. Finally, by clicking on the **Download** button, the file can be downloaded locally in case you want to experiment more with the data.\n",
- "\n",
- "As we have seen, every time that we downloaded a chunk, the size of the local file increased by a fixed amount (around 0.64 MB). This is because the chunks (whose uncompressed data occupies around 6.4 MB) are compressed with the `Codec.GROK` codec, which has been configured to reduce the size of the data by a *constant* factor of 10. This means that the compressed data occupies only one-tenth of the space that it would occupy without compression. This reduction in data size optimizes both storage and transfer, as data is always handled in a compressed state when downloading or storing images, accelerating the transfer process (by a factor of 10).\n",
- "\n"
- ]
- },
- {
- "cell_type": "markdown",
- "id": "c508507d74434ecd",
- "metadata": {},
- "source": [
- "## Conclusion\n",
- "\n",
- "This tutorial has highlighted how the ``Proxy`` class in Blosc2, combined with the `fetch` and `__getitem__` methods, optimizes access to multidimensional data, even when stored remotely (accessible via a ``C2Array``). The intelligent use of a workflow which links remote/on-disk data (``C2Array``/``NDArray``) to a local ``Proxy`` cache (via a ``ProxyNDSource`` instance) enables one to handle large volumes of information without maxing out storage capacity, whilst still benefitting from the performance gains of caching and in-memory calculation."
- ]
- }
- ],
- "metadata": {
- "kernelspec": {
- "display_name": "Python 3 (ipykernel)",
- "language": "python",
- "name": "python3"
- },
- "language_info": {
- "codemirror_mode": {
- "name": "ipython",
- "version": 3
- },
- "file_extension": ".py",
- "mimetype": "text/x-python",
- "name": "python",
- "nbconvert_exporter": "python",
- "pygments_lexer": "ipython3",
- "version": "3.12.3"
- }
- },
- "nbformat": 4,
- "nbformat_minor": 5
-}
diff --git a/doc/getting_started/tutorials/07.schunk-basics.ipynb b/doc/getting_started/tutorials/07.schunk-basics.ipynb
deleted file mode 100644
index 70466c76f..000000000
--- a/doc/getting_started/tutorials/07.schunk-basics.ipynb
+++ /dev/null
@@ -1,628 +0,0 @@
-{
- "cells": [
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "# Compressing data with the SChunk class\n",
- "\n",
- "Although the ``NDArray`` class is the most widely used container for data in Blosc2, it (and many other containers like `C2Array`, `ProxySource`, etc.) is built on top of the `SChunk` class. The machinery of ``SChunk`` (from \"super-chunk\") is what makes it possible to easily and quickly create, append, insert, update and delete data and metadata for these containers which inherit from the super-chunk container. Hence, it is worthwhile to learn how to use ``SChunk`` directly. See this quick overview of the `SChunk` class in the [Python-Blosc2 documentation](../overview.html)."
- ]
- },
- {
- "cell_type": "code",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T08:16:27.372464Z",
- "start_time": "2025-08-05T08:16:27.016363Z"
- }
- },
- "source": [
- "import numpy as np\n",
- "\n",
- "import blosc2"
- ],
- "outputs": [],
- "execution_count": 1
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## Create a new ``SChunk`` instance\n",
- "One can initialize an ``SChunk`` instance with default parameters. If no data is provided, the space assigned to the chunked data will also be empty (since once can always extend and resize a super-chunk, this is not a problem). However, let's specify the parameters so they are different to defaults: we'll set `chunksize` (the size of each chunk in bytes), the `cparams` (compression parameters), the `dparams` (decompression parameters) and pass a `Storage` instance, which is used to persist the data on-disk."
- ]
- },
- {
- "cell_type": "code",
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T08:16:27.390406Z",
- "start_time": "2025-08-05T08:16:27.381588Z"
- }
- },
- "source": [
- "cparams = blosc2.CParams(\n",
- " codec=blosc2.Codec.BLOSCLZ,\n",
- " typesize=4,\n",
- " nthreads=8,\n",
- ")\n",
- "\n",
- "dparams = blosc2.DParams(\n",
- " nthreads=16,\n",
- ")\n",
- "\n",
- "storage = blosc2.Storage(\n",
- " contiguous=True,\n",
- " urlpath=\"myfile.b2frame\",\n",
- " mode=\"w\", # create a new file\n",
- ")\n",
- "\n",
- "schunk = blosc2.SChunk(chunksize=10_000_000, cparams=cparams, dparams=dparams, storage=storage)\n",
- "schunk"
- ],
- "outputs": [
- {
- "data": {
- "text/plain": [
- "![](\"images/blosc2-pipeline.png\")
\n",
- "\n",
- "\n",
- "So when compressing, the first step will be to apply the prefilter (if any), then the filter pipeline with a maximum of six filters and, last but not least, the codec. For decompressing, the order will be the other way around: first the codec, then the filter pipeline and finally the postfilter (if any).\n",
- "\n",
- "In this tutorial we will see how to create and use custom codecs and filters (see the next tutorial for post-/prefilters)."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "## User-defined codecs\n",
- "\n",
- "Predefined codecs in Blosc2 use low-level C functions and so are amenable to parallelisation. Because a user-defined codec has Python code, we will not be able to use parallelism, so `nthreads` has to be 1 when compressing and decompressing. We set `nthreads=1` in the `CParams` and `DParams` objects that we will use to create the `SChunk` instance. When using user-defined codes, we may also specify ``codec_meta`` in the ``CParams`` instance as an integer between 0 and 255 (see ``compcode_meta`` [here](https://github.com/Blosc/c-blosc2/blob/main/README_CFRAME_FORMAT.rst)). This meta will be passed to the codec's *encoder* and *decoder* functions, where it can be interpreted as one desires. We may also pass ``filters_meta`` in the `CParams` object, which will be passed to the user-defined filters *forward* and *backward* functions. Later on, we will update the `CParams` object with our user-defined codec and filters, and update the meta at the same time."
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 1,
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T16:08:34.957869Z",
- "start_time": "2025-08-05T16:08:34.689868Z"
- },
- "pycharm": {
- "name": "#%%\n"
- }
- },
- "outputs": [],
- "source": [
- "import sys\n",
- "\n",
- "import numpy as np\n",
- "\n",
- "import blosc2\n",
- "\n",
- "dtype = np.dtype(np.int32)\n",
- "cparams = blosc2.CParams(nthreads=1, typesize=dtype.itemsize)\n",
- "dparams = blosc2.DParams(nthreads=1)\n",
- "\n",
- "chunk_len = 1000\n",
- "schunk = blosc2.SChunk(chunksize=chunk_len * dtype.itemsize, cparams=cparams, dparams=dparams)"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {
- "pycharm": {
- "name": "#%% md\n"
- }
- },
- "source": [
- "### Creating a codec\n",
- "\n",
- "To create a codec we need two functions: one for compressing (aka *encoder*) and another for decompressing (aka *decoder*). In order to explain the procedure, we will create a codec for repeated values. First we programme the *encoder* function:"
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 2,
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T16:08:34.970310Z",
- "start_time": "2025-08-05T16:08:34.965888Z"
- },
- "pycharm": {
- "name": "#%%\n"
- }
- },
- "outputs": [],
- "source": [
- "def encoder(input, output, meta, schunk):\n",
- " nd_input = input.view(dtype)\n",
- " # Check if all the values are the same\n",
- " if np.max(nd_input) == np.min(nd_input):\n",
- " # output = [value, nrep]\n",
- " output[0 : schunk.typesize] = input[0 : schunk.typesize]\n",
- " byteorder = \"little\" if meta == 0 else \"big\"\n",
- " n = nd_input.size.to_bytes(4, byteorder)\n",
- " output[schunk.typesize : schunk.typesize + 4] = [n[i] for i in range(4)]\n",
- " return schunk.typesize + 4\n",
- " else:\n",
- " # memcpy\n",
- " return 0"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "In order to be compatible with the Blosc2 internal compression machinery, which operates blockwise, the encoder function requires 4 arguments: the input data block; the output buffer into which the data is compressed; the codec meta (which here we decide will be used to indicate the [\"endianness\"](https://en.wikipedia.org/wiki/Endianness) of the bytes); and the `SChunk` instance which hosts the compressed block. The *encoder* must then return the size of the compressed buffer in bytes. If it cannot compress the data, it must return 0 - Blosc2 will then know to simply copy the block without compressing. The image below depicts what our *encoder* does:\n",
- "\n",
- "\n",
- "![](\"images/ucodecs-filters/encoder.png\")
\n",
- "
\n",
- "\n",
- "Now let's go for the *decoder*, which also expects to receive the same 4 arguments, and operates blockwise."
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 3,
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T16:08:35.038321Z",
- "start_time": "2025-08-05T16:08:35.033897Z"
- },
- "pycharm": {
- "name": "#%%\n"
- }
- },
- "outputs": [],
- "source": [
- "def decoder(input, output, meta, schunk):\n",
- " byteorder = \"little\" if meta == 0 else \"big\"\n",
- " if byteorder == \"little\":\n",
- " nd_input = input.view(\"\n",
- "\n",
- "![](\"images/ucodecs-filters/decoder.png\")
\n",
- "
\n",
- "\n",
- "Note that if a block was memcopied (uncompressed) by Blosc2 the *decoder* will be skipped when requesting data from the SChunk."
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {
- "pycharm": {
- "name": "#%% md\n"
- }
- },
- "source": [
- "### Registering and Using a codec\n",
- "\n",
- "Once the codec's procedures are defined, we can register it to the local Blosc2 codec registry! For that, we must choose an identifier between 160 and 255."
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 4,
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T16:08:35.050108Z",
- "start_time": "2025-08-05T16:08:35.047278Z"
- },
- "pycharm": {
- "name": "#%%\n"
- }
- },
- "outputs": [],
- "source": [
- "codec_name = \"our_codec\"\n",
- "codec_id = 160\n",
- "blosc2.register_codec(codec_name, codec_id, encoder, decoder)"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {
- "pycharm": {
- "name": "#%% md\n"
- }
- },
- "source": "The codec can now be specified in the compression params of an SChunk instance using its id. We also pass the ``codec_meta`` that we want our codec to use in the encoder and decoder. Since we designed the codec to receive the original data with no changes, we specify that no filters are to be used:"
- },
- {
- "cell_type": "code",
- "execution_count": 5,
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T16:08:35.066023Z",
- "start_time": "2025-08-05T16:08:35.059165Z"
- },
- "pycharm": {
- "name": "#%%\n"
- }
- },
- "outputs": [
- {
- "data": {
- "text/plain": [
- "CParams(codec=160, codec_meta=0, clevel=1, use_dict=False, typesize=4, nthreads=1, blocksize=0, splitmode=\n",
- "\n",
- "![](\"images/ucodecs-filters/forward.png\")
\n",
- "
\n",
- "\n",
- "The *backward* function applies the inverse transform to the *forward* function, so it will reconstruct the original data."
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 8,
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T16:08:35.138093Z",
- "start_time": "2025-08-05T16:08:35.134900Z"
- },
- "pycharm": {
- "name": "#%%\n"
- }
- },
- "outputs": [],
- "source": [
- "def backward(input, output, meta, schunk):\n",
- " nd_input = input.view(dtype)\n",
- " nd_output = output.view(dtype)\n",
- "\n",
- " nd_output[0] = nd_input[0]\n",
- " for i in range(1, nd_output.size):\n",
- " nd_output[i] = nd_output[i - 1] + nd_input[i]"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {
- "pycharm": {
- "name": "#%% md\n"
- }
- },
- "source": [
- "Hence when called on the output of the *forward* function, it will reconstruct the original data as follows:\n",
- "\n",
- "\n",
- "![](\"images/ucodecs-filters/backward.png\")
\n",
- "
\n",
- "\n",
- "### Registering and Using a filter\n",
- "\n",
- "Once we have the two required functions, we can register our filter. In the same way we did for the codecs, we have to choose an identifier between 160 and 255:"
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 9,
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T16:08:35.148096Z",
- "start_time": "2025-08-05T16:08:35.144684Z"
- },
- "pycharm": {
- "name": "#%%\n"
- }
- },
- "outputs": [],
- "source": [
- "filter_id = 160\n",
- "blosc2.register_filter(filter_id, forward, backward)"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {
- "pycharm": {
- "name": "#%% md\n"
- }
- },
- "source": "The filter can now be introduced into the SChunk's filter pipeline via updating the `cparams` attribute of the `SChunk` instance with a list of the filters to be applied, indicated by their unique id (in this case just the filter we created), and their corresponding `filters_meta` (in this case it is unimportant, as the filter does not use it). We also need to update the codec used so that we can take advantage of the filter first though."
- },
- {
- "cell_type": "markdown",
- "metadata": {
- "pycharm": {
- "name": "#%% md\n"
- }
- },
- "source": [
- "### Writing a new codec for the filtered data\n",
- "Next, we are going to create another codec to compress data passed by the filter. This will get the start value and the step when compressing, and will rebuild the data from those values when decompressing:"
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 10,
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T16:08:35.162556Z",
- "start_time": "2025-08-05T16:08:35.157998Z"
- },
- "pycharm": {
- "name": "#%%\n"
- }
- },
- "outputs": [],
- "source": [
- "def encoder2(input, output, meta, schunk):\n",
- " nd_input = input.view(dtype)\n",
- " if np.min(nd_input[1:]) == np.max(nd_input[1:]):\n",
- " output[0 : schunk.typesize] = input[0 : schunk.typesize] # start\n",
- " step = int(nd_input[1])\n",
- " n = step.to_bytes(4, sys.byteorder)\n",
- " output[schunk.typesize : schunk.typesize + 4] = [n[i] for i in range(4)]\n",
- " return schunk.typesize + 4\n",
- " else:\n",
- " # Not compressible, tell Blosc2 to do a memcpy\n",
- " return 0\n",
- "\n",
- "\n",
- "def decoder2(input, output, meta, schunk):\n",
- " nd_input = input.view(dtype)\n",
- " nd_output = output.view(dtype)\n",
- " nd_output[0] = nd_input[0]\n",
- " nd_output[1:] = nd_input[1]\n",
- "\n",
- " return nd_output.size * schunk.typesize"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "Their corresponding schemes are as follows:\n",
- "\n",
- "\n",
- "\n",
- "![](\"images/ucodecs-filters/encoder2.png\")
\n",
- "
\n",
- "\n",
- "\n",
- "\n",
- "![](\"images/ucodecs-filters/decoder2.png\")
\n",
- "
\n",
- "\n",
- "As the previous id is already in use, we will register it with another identifier:"
- ]
- },
- {
- "cell_type": "code",
- "execution_count": 11,
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T16:08:35.176293Z",
- "start_time": "2025-08-05T16:08:35.172678Z"
- },
- "pycharm": {
- "name": "#%%\n"
- }
- },
- "outputs": [],
- "source": [
- "blosc2.register_codec(codec_name=\"our_codec2\", id=184, encoder=encoder2, decoder=decoder2)"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": "Now we update the schunk's `cparams` to use the new codec as well as the filter we just registered. We will also set the `codec_meta` to 0, although it isn't used by our new codec."
- },
- {
- "cell_type": "code",
- "execution_count": 12,
- "metadata": {
- "ExecuteTime": {
- "end_time": "2025-08-05T16:08:35.192354Z",
- "start_time": "2025-08-05T16:08:35.186030Z"
- },
- "pycharm": {
- "name": "#%%\n"
- }
- },
- "outputs": [
- {
- "data": {
- "text/plain": [
- "CParams(codec=184, codec_meta=0, clevel=1, use_dict=False, typesize=4, nthreads=1, blocksize=0, splitmode=\n",
- "- Version 4.0.0 released on 2026-01-29! - - pip install blosc2 -U -
- -.. raw:: html - -Python-Blosc2: Compress Better, Compute Bigger
- -.. raw:: html - - - -.. grid:: 1 2 3 3 - :gutter: 3 - - .. grid-item-card:: - :class-card: intro-card text-center no-border - - .. raw:: html - -
-
-
-
- `Combine advanced codecs and filters Top-Notch Compression
-
-
-
-
- `NDArray objects Full-Fledged NDArrays
-
-
-
-
- Combines compression with high-speed computation of complex `mathematical expressions Compute Engine Inside
-
-
-
-
- Efficiently store data hierarchically with the `TreeStore class Hierarchical Structures
-
-
-
-
- Access data from anywhere: read/write in `memory or disk Flexible Storage
-
-
-
-
- `Blosc2's format Uncomplicated Format
-Documentation
- -.. grid:: 1 2 2 2 - :gutter: 3 - - .. grid-item-card:: - :class-card: intro-card text-center - - .. raw:: html - -
-
-
-
- New to Python-Blosc2? Check out the getting started guides. They contain an introduction to Python-Blosc2 main concepts and different tutorials.
-
- .. raw:: html
-
-
-
- .. grid-item-card::
- :class-card: intro-card text-center
-
- .. raw:: html
-
- Getting Started
-
-
-
-
- The reference guide provides a comprehensive description of the Python-Blosc2 API, detailing how functions work and their available parameters.
-
- .. raw:: html
-
-
-
- .. grid-item-card::
- :class-card: intro-card text-center
-
- .. raw:: html
-
- API Reference
-
-
-
-
- Found a typo in the documentation or want to improve existing functionality? The contributing guidelines will walk you through the process of enhancing Python-Blosc2.
-
- .. raw:: html
-
-
-
- .. grid-item-card::
- :class-card: intro-card text-center
-
- .. raw:: html
-
- Development
-
-
-
-
- Want to see what's new in the latest release? Explore the comprehensive release notes to discover new features, improvements, bug fixes, and important changes across all versions.
-
- .. raw:: html
-
-
-
-
-
-.. toctree::
- :maxdepth: 1
- :hidden:
-
- Getting Started