fixed some typoes and added explanation

_posts/2024-07-21-fragmenting-the-tile-data.markdown

@@ -1,21 +1,21 @@
 ---
 title: Fragmenting the tile data
 image: /img/subband_sizes_tiles1000.png
-description:
+description: Looking at some statistics about the structure of the tile data we learn something about the underlying wavelet compression.
 ---
 
-When looking at the data segment [CIS/COD
+When looking at the data segment of [CIS/COD
 images](/2024/04/03/learning-about-the-image-format.html) (i.e., the
 tiles) the byte sequence `0x63 0x6f 0x64` (ASCII: `cod`) appears
 several times and thus is conspicuous. According to [a wiki page
 describing a derived video
 codec](https://wiki.multimedia.cx/index.php/Lightning_Strike_Video_Codec)
-it marks the end of a "plane", a basic building blog of
+it marks the end of a "plane", a basic building block of
 wavelet-compressed images. In this post we explore the distribution of
 these blocks.
 
 Let us start to analyse how many such parts we find in images for the
-different tile sizes:
+different tile types:
 
 ## 20 colour tiles of size 250x250
 
@@ -47,10 +47,10 @@ different tile sizes:
 |              13 |     24667 |
 |              14 |        33 |
 
-We can clearly see that most images of one tile size/type have the
-same number of parts: typically 36 for colour images and 13 for
-greyscale images (with the exception of the 250x250 overview images
-which have mainly 39 parts).
+We can clearly see that tiles from the same type have mostly the same
+number of parts: typically 36 for colour tiles and 13 for greyscale
+tiles (with the exception of the 250x250 overview tiles which have
+mainly 39 parts).
 
 Without going into further detail (yet) I can state that each part
 likely represents a "sub-band" of the wavelet decomposition which has
@@ -67,3 +67,15 @@ The following plot shows the size distribution of the components over
 all greyscale 1000x1000 tiles for each sub-band:
 
 ![sub-band sizes for all 1000x1000 greyscale tiles](/img/subband_sizes_tiles1000.png)
+
+The vertical axis is logarithmically scaled and the numbers at each
+lower end of the violin plot indicate the mean for each sub-band.
+
+We can see that the size required for each sub-band increases from (on
+average) 693 bytes for sub-band 0 to (on average) 22530 bytes for
+sub-band 12 (excluding sub-band 13 which only 33 images have). This
+nicely fits the typical order in which sub-bands in wavelet compressed
+images are stored: The first sub-band provides a very much scaled-down
+version of the original image. Successively adding information from
+the following sub-bands improves the image quality step-by-step, thus
+supporting progressing loading and display of images.