From 132ba2b0a889d78da86103db3fd5f40b354092a6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Robert=20J=C3=A4schke?= Date: Sun, 21 Jul 2024 13:59:44 +0200 Subject: [PATCH] fixed some typoes and added explanation --- ...4-07-21-fragmenting-the-tile-data.markdown | 28 +++++++++++++------ 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/_posts/2024-07-21-fragmenting-the-tile-data.markdown b/_posts/2024-07-21-fragmenting-the-tile-data.markdown index df6b8e9..4787a50 100644 --- a/_posts/2024-07-21-fragmenting-the-tile-data.markdown +++ b/_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.