|TechTalks / Tiling versus banding|
AWare Systems on-line
Tiling versus banding techniques for handling big images
> Why do you think that tiles are better than
Various reasons, most of them boil down to the fact that for most practical access in frequent situations, you'll need to access fewer tile blocks compared to band blocks of the same memory size. Here are two examples...
If you build on from a tiling or banding raster object, sooner or later, you'll come accross the need to access a rect in the raster. For the sake of statistical relevance, suppose the rect is square, and the image is very large. A very large image does not change tile dimensions, they'll be, e.g., 1.000x1.000 pixels, or whatever, whether you're dealing with a total raster size of 10.000x10.000 or 100.000x100.000. These total raster dimensions do influence your band dimensions, though. In the first case, 10.000x10.000, a band equal in memory size to the mentioned tile size will be 10.000x100 pixels, in the second case it will be 100.000x10 pixels. Now suppose you need the rectangle (0, 0, 2.000, 2.000). In the tiling scenario, this accesses only 4 tiles, first case as well as second. In the banding scenario, this accesses 20 bands in the first case, and even 200 bands in the second case. That's much worse, with potentially a lot of swapping going on. It's obvious that the tiling scenario is perfectly 'scalable', while in the banding scenario things do get substantially worse as images get bigger.
Here's an even more extreme example. If you build on from a tiling or banding raster object, sooner or later, you'll come accross the need to rotate a source tile array / band array into a destination tile array / band array, say 90 degrees. Suppose you have decided, at some point, that you need something like 'scanline streams'. (I have, and I can't see another way to build a feasable image processing library around tile array or band array rasters.) The way you rotate might be to take 'scancolumns' from the source, and to dump these as 'scanlines' into the destination. In the banding scenario, each column access involves access to ALL bands. That means you'll swap in and out the entire image memory for each column in the image, and huge images are bound to have a big number of columns... In the tiling scenario, things stay much better, even in this 90 degrees rotation example, because you only need access to a very limited number of tiles, whether you're dealing with columns or lines.
Another reason for prefering tiles is that the tiling scheme is resistant to very wide images with high bitdepth, while the banding scheme, in theory, may need more memory to store a single scanline than is set to be the limit. Suppose you store 64bit per channel floating point CMYK with alpha. That's 40 bytes per pixel. Suppose the set maximum of a band is 200 kilobytes. (I agree that would not be practical, this is a theoretical objection to banding, not a practical one.) That would mean that either the maximum supported width of images is 5,000 pixels, or you would have to make an exception as to the maximum size of a single-line band. I agree this is a very theoretical objection, but it's just one of those things that makes me feel 'uncomfortable' with bands... For all you know, you may decide one day to support up to 255 mask channels or such. Neuh... OK, disregard last paragraph. ;-)
Please drop us a line if you wish to be kept informed about changes and additions to this page.