An image library component is a type of linked image component that shows what appears to be a single image that is created by automatically forming a mosaic from one or more images saved in image files within a folder on disk. The individual images that comprise the image library are called image tiles. The image library component takes its name from the name of the folder that contains the image tiles that comprise the image library. Image tile files may be in BMP, ECW, GIF, JP2 (JPEG 2000), JPG, PNG, TGA or TIFF formats.
If the image tile files are in ECW, JPEG 2000 or GeoTIFF formats that contain projection information within the file then the coordinate system information within each image file will automatically be used to georegister the image and form the image library mosaic.
If the image tile files are accompanied by like-named files containing projection information in XML, PRJ, GSR or world files then the coordinate system information from those accompanying files will automatically be used to georegister the images and form the image library mosaic.
If the image tile files are not accompanied by like-named files containing projection information, then the image library mosaic can still be created if the image tile files are named to indicate their position in the mosaic.
We can link an image library into a project by choosing File - Link - Image and then choosing Image Library Files in the Files of type box and then navigating into the folder in which the image library images are located and choosing one of the images. This launches the Link Image Library dialog.
Link Image Library Dialog Controls
|
Arrange images using filenames |
If checked (the default), derive the location of image tiles from the name of each image file and place images accordingly. Choosing this option ignores coordinate system data in any accompanying coordinate system files or in the image files themselves. |
|
Mask |
A template using [X], [Y] and optionally [L] nomenclature to show how the names of image files should be used to place each image tile into position. |
|
Automatically save intermediate levels |
If checked (the default), will automatically generate tiles for intermediate image levels and will store them into the folder together with the other image files. |
|
Reverse Y |
Reverse the order in which Y values are interpreted. |
|
Margins |
The number of pixels to clip from left, right, top and bottom margins. Used when image tiles overlap and some part is to be deleted. |
|
Georegister images using accompanying files |
If checked, derive the location of image tiles from accompanying coordinate system files or from the files themselves for supported formats. |
|
Mask |
The template used for a filename when the above option is checked. Normally just an asterisk and the extension for that type of image file, such as .jpg, .tif or other supported image format. |
|
Ignore datum differences |
Enabled when the coordinate system for each image is to be defined by an accompanying file. If more than one datum is in use the system will arbitrarily choose one such datum from those used and will then treat all datums as if only that arbitrarily selected datum was the controlling datum. |
|
Scan subfolders |
If checked (the default), scan folders recursively below this folder to find more image files. If not checked, will only use image files from this folder. |
Creating Image Libraries using Georeferenced Image Tiles
It's very easy to create an image library component if the image tile files we would like to use are either:
In GeoTIFF, JPEG 2000 or ECW format and containing georeferencing information (although unusual, it is possible some ECW or JPEG 2000 files might have been created without embedded georeferencing information), or
Are accompanied by accessory files giving projection information in XML, PRJ or GSR files or are accompanied by world files that give shifts and scales. If accompanying XML files are used they must be the .xml files written by Manifold System to specify the projection / georegistration information for an image.
If image library image tile files fall into one of the above categories it doesn't matter what file names are used or what the size of each image file may be.
To link an image library into a Manifold project using image tiles with accessory projection files.
1. Choose File - Link - Image.
2. In the Files of type box choose Image Library Files.
3. Browse into the folder containing the image tile files. All image tile files to be used must be in that same folder.
4. Double-click any one of the image files.
5. In the resulting Link Image Library dialog, check the Georegister images using accompanying files option.
6. In the Mask box, provide a mask that matches the file type to be used, for example, *.tif if using .tif files and *.jpg if using .jpg files.
7. Press OK.
A new linked image library component will appear in the Manifold project, taking its name from the name of the folder that contains the image tile files. Opening the image library component will show a gray background that will begin populating with images as the individual image tiles are loaded.
Example
Consider a series of nine images saved in ordinary .tif files (that is, not GeoTIFF files but plain, ordinary tif files as might be processed by PhotoShop and saved without georeferencing tags) in a folder called Bay image. These images may be arranged in a mosaic to form an overall view of the San Francisco Bay area.



Each image is georegistered and was saved (using Manifold) so that it has an accompanying .xml file giving relevant coordinate system information. Each image when imported therefore will be automatically georegistered. The images are all different sizes.
We can create an image library component from these images by choosing File - Link - Image, choosing Image Library Files in the Files of type box and then browsing into the Bay image folder and double-clicking one of the .tif image names. In the resulting dialog, we check the Load coordinate systems... option and in the Mask box we use *.tif as the mask. Press OK.

When we open the resulting Bay image image library component Manifold will import all of the image tiles and use the accompanying .xml coordinate system file for each to know where each file should be positioned to make a combined mosaic that appears to be a single image.
In this example, each image tile neatly abuts the adjacent image with no overlaps or gaps. If any image tiles overlapped, the resulting image library would average the pixel colors in the region of overlap to create the pixels in that region for the image library composite. If there were gaps or no image tile in a particular region, the image library would have transparent pixels in that region.
Image libraries made up from image tile files that are accompanied by XML, PRJ or GRS files that provide exact coordinate system information for each image tile are very easy to work with because the placement of each image is completely automated by Manifold. There's really no need for any significant thought on the part of the user because the files themselves contain all information necessary to mosaic them together. The files can be named using whatever names they have and they can be different sized as well. Easy!
It's also easy to work with GeoTIFF, ECW, or JPEG 2000 files that contain georegistration information inside the files. In that case projection information comes from the files themselves.
We can also create image libraries from image files that are accompanied by world files. World files are a highly imperfect way of storing partial projection information, but they are better than nothing. See the discussion of world files in the Importing Images topic.
Specifying Image Locations using Image File Names
Creating an image library requires more effort when image tile files do not use a geographically aware format like GeoTIFF or ECW or when they do not have accompanying XML, PRJ or GRS files to enable automated mosaics. It is still possible to automatically mosaic such image tiles into an image library component, but we will have to organize the images by naming the files in a regular way so that Manifold can tell from the name of the image where to put each image tile.
Giving images names where the filename indicates where each image is located is nothing new: that's a common technique often used when saving images in various applications so that later on it is easy to tell from file names on disk the geographic area covered by a particular image.
To link an image library into a Manifold project using image tiles without accessory projection files.
1. Choose File - Link - Image.
2. In the Files of type box choose Image Library Files.
3. Browse into the folder containing the image tile files. All image tile files to be used must be in that same folder. All images must be the same size in terms of their height and width in pixels.
4. Double-click any one of the image files.
5. In the resulting Link Image Library dialog, check the Arrange images using filenames option.
6. In the Mask box, provide a mask that describes the style of file name used to specify the position of the image.
7. If parts of each image should be masked off (for example, to remove some unwanted common border or region of overlap) use the Margins settings to specify the region on each side to be removed.
8. Press OK.
With the above technique we must understand how the naming convention being used should be specified in the Mask box. Manifold provides flexible options so that different forms of file names may be accommodated.
Example
Consider a set of images similar to those used in the example above, which may be arranged to form a mosaic of the San Francisco Bay area. Each image is saved in an ordinary .tif file without any projection information.

However, in this case, each of the individual images forming the mosaic are exactly the same size in terms of numbers of pixels in width and breadth.

Images on the edge of the mosaic contain regions of black pixels in areas not represented in the original photograph. The images are saved in files that do not have accompanying coordinate system information. Upon import into Manifold, they will not be georegistered.
A collection of images like those above may be used in Manifold to form an image library if they are named in an orderly fashion so that Manifold knows from the file names for each image tile where that image tile is to be placed within the image library mosaic.

We can use a naming scheme that contains within the filename an indication of which X,Y position each particular image tile occupies within the image library mosaic. The conventional way to designate X and Y locations is to begin in the lower left hand corner and to number to the right for X values and upwards for Y values.

If we do this for the mosaic as seen above, we can provide an X,Y coordinate for each image tile. For example, the 3,2 tile is the one located in the third X position in the second Y position, that is, on the rightmost part of the middle row.

We can give each image tile file a name that incorporates the X,Y location of the tile in its name. For example, the image tile that is supposed to go into the 3,2 position will be named Bay0302.tif.
Why the use of leading zeroes as well as the name Bay within each file name? That's not required but it does help to keep things organized and easily legible. We could have just as easily named the 3,2 tile 32.tif or 003002.tif or thisoneisthe32tile.tif. Manifold's Mask specification used in the image library dialog allows variations like those, as we will see below.

We will give each tile a name using the above scheme. If we were to open the individual images in a package like PhotoShop we'd see that they are just a group of unregistered images that happen to have been given names that indicate where they should be placed if a mosaic of the entire Bay area is to be constructed.
If we create an image library component using the above images, we would use a Mask value of
Bay[X:2][Y:2].tif
to indicate the names of the image tile files. The [X:n] and [Y:n] escape sequences tell Manifold what part of the file name has to do with X and Y coordinates. The [X:2] specification tells Manifold that two characters in that position in the file name specify the X position of the tile in the mosaic and the [Y:2] specification tells Manifold that two characters in that position specify the Y position.
The above mask matches file name specifications ranging from Bay0101.tif to Bay9999.tif. It would not match Bay123ab.tif. Other masks and examples include:
|
Example |
Mask |
|
32.tif |
[X:1][Y:1].tif |
|
003002.tif |
[X:3][Y:3].tif |
|
thisoneisthe32tile.tif |
thisoneisthe[X:1][Y:1]tile.tif |
|
img_x3y2.tif |
img_x[X]y[Y].tif |

When the above mask is used to create an image library component, the individual image tiles will be placed into a mosaic based upon their file names to create an overall image of the Bay area.
Reverse Y Option
While it is virtually universal practice to number the X axis with increasing values to the right, not everyone numbers their Y locations counting up from the bottom left corner. Some people and systems prefer to begin at the top left corner and count down.

We can use this arrangement if we like, as seen above, and create different file names. In this case, the Bay0101.tif image is the upper left corner image and not the lower left corner image. If we prefer to name our image tile files in this manner we can still use the same Mask specification. We simply check the Reverse Y option in the Link Image Library dialog to tell Manifold we are numbering Y values from the top down instead of the conventional bottom up.
Exporting Image Libraries
An image library may be exported to a file using the File - Export - Image command. The image library will be exported as a single image using the specified image format.
Unlinking Image Libraries
An image library may be transformed into an ordinary image by right clicking the image library in the project pane and choosing Unlink.
Converting Image Libraries
Another way to convert an image library into an ordinary image is to open the image library in a window and then choosing Image - Convert. Converting an image library creates a local image in the project of the desired type, being equivalent to first unlinking it and then converting the new local image into an image of the desired type.
Limitations on Re-Projection
Except for limited exceptions of interest only to experts, compressed images, linked images and image libraries cannot in general be re-projected.
For example, opening an ECW compressed image and attempting to re-project it to a different projection or dragging and dropping either an ECW compressed image or an image linked from some image server into a map that uses a different projection will fail. In such cases, Manifold will pop open a dialog telling us of the projection incompatibility.
If we would like to re-project such images, we should first convert them to an unlinked local image (in the case of linked images) or to an uncompressed image type (in the case of compressed images) or to a regular local image (in the case of an image library). We can then re-project the image as desired.
Note by the way that attempting to re-project such images on the fly by dropping them into a map that uses a different projection usually indicates a conceptual error on the part of the user: usually, large images of the sort that are used as compressed images, linked images or image libraries are likely to be the largest, or among the largest, layers in any such map. It is therefore would be wisest to use their native projection as the projection for the map, so that when the map is displayed it is other, smaller layers that must be re-projected on the fly to display the map and not the large image layer.
To do so, create the map using the image layer first. This will assure that the map uses the image's projection. Next, drag and drop the other layers into the map. For maximum speed, re-project the other layers to match the projection used by the map. This is easily accomplished by (in the map window) right-clicking on the layer's tab and choosing Project to Map from the context menu.
Index Drawings
When an image library is open the Image - Create Index Drawing command is enabled. This command allows us to automatically create a drawing that contains areas showing the extent of each individual image file that makes up that image library together with desired information about each image file, such as the name of the file, the path to that file's location and the type of file.
Index drawings are used in a variety of applications. For example, we might not wish to display all of the images in an image library but need to fetch an image that is part of the library. An IMS application, for example, might show a variety of vector layers and use an index drawing to show where imagery is available in a particular region. The application could be programmed so that a user who wants to see that imagery can double-click onto an index drawing area to pop open the corresponding image in a new window or to make it visible in a map window.
See the Image - Create Index Drawing topic for an example that creates an index drawing for the image library seen in this topic and then uses that index drawing within a Manifold IMS web page.
Intermediate Levels
If we provide intermediate image levels manually using the [L] specification and user-supplied intermediate level files we can improve interactive performance. See the Intermediate Levels and Pyramids topic for an explanation of intermediate level images, with illustrations.
If we do not manually provide intermediate level files (it's rare that they are available) it is a good idea to keep the Automatically save intermediate levels option checked so that Manifold will create intermediate level images for us. Even if we manually provide intermediate level images it is not a bad idea to have Manifold supplement them with automatically created intermediate level images. Here's why:
Most image libraries make up an image mosaic that is far larger than can fit into a computer monitor screen at one to one scale (one pixel in the image appearing in one pixel in the monitor). When we zoom far out enough to see the entire image, we don’t see every pixel in the screen: instead, we see an interpolation or averaged out view where each pixel in the zoomed out image represents potentially hundreds of pixels at full resolution.
Computing such averaged out views takes time. The process can be speeded up a lot if intermediate level images, also known as pyramids, are computed in advance for intermediate zoom levels. Saving such intermediate zoom level images doesn't take much space but if they are available when we zoom in or out Manifold can simply utilize a pre-computed view for faster zooms and panning. This is much faster than re-computing an interpolated view on demand.
Most technologies for fast viewing of very large images, such as ECW, incorporate some scheme for pre-computing intermediate views in advance and then fetching them as needed to support faster zooming and panning. The Automatically save intermediate levels option allows us to utilize intermediate image levels even when working with image libraries that do not have intermediate levels. When the option is turned on, Manifold will automatically create intermediate level images and save them into the folder being used with the rest of the image library tiles.
Note: to use this option, our user login must have write permissions to the folder being used for image library tiles. If our login does not have write permission, Manifold won't be able to write intermediate level image files into that folder.
If the option is turned off, the image library will try to keep autogenerated intermediate image tiles in RAM cache. If the amount of available RAM decreases below an internally-computed safety level, the intermediate image tiles in RAM will be discarded and then regenerated again on demand.
[L] Level Specification
The [L] specification allows us to manually specify intermediate level image files to be used in the image library if we have intermediate level files available.
It is often the case that a particular region has images of greater and lesser resolution that cover it. For example, a region might be covered by sixteen images at high resolution and also be covered by four images at lower resolution and by one image at very low resolution. The different sets of images covering the same region represent intermediate levels of resolution.
Manifold can exploit the different levels of images to select the best level to match a given zoom into an image library. When zoomed far into an image library the higher resolution level images will be used. When zoomed out, so that very detailed pixels could not be seen anyway, Manifold can use a lower resolution image level for faster display.
The [L] specification in an image filename mask allows us to tell Manifold which images should be used at which level of zoom.
To specify the level to which different image files belong, we use the [L] specification within an image mask. Level number always uses zero based counting as in 0, 1, 2, 3... with level 0 being the highest resolution images covering the smallest regions and higher level numbers referring to lower resolution images that cover a larger region. The [L] specification is used together with the [X] and [Y] specifications to describe the organization implied by filenames.
|
Example |
Mask |
Comment |
|
132.tif |
[L:1][X:1][Y:1].tif |
An image tile that belongs to level 1 where levels are specified using one digit. |
|
01003002.tif |
[L:2][X:3][Y:3].tif |
An image tile that belongs to level 1 where levels are specified using two digits. |
|
level3position32.tif |
level[L]position[X:1][Y:1].tif |
An image tile that belongs to level 3 where levels are specified using one digit. |
It is easy to get confused as to what intermediate level image relates to which higher-resolution (smaller) images it covers. We can help keep things straight by using an orderly naming scheme which in the case of image libraries that employ intermediate levels should use zero based numbering.
When numbering X and Y, most people begin with 1 as illustrated above so that the first, corner tile is in the 1,1 position. However, if we like we can number beginning with zero in the series 0, 1, 2, 3... so that the first tile is in the 0,0 position. That means names such as Bay0000.tif for the first corner tile instead of Bay0101.tif are perfectly acceptable to Manifold.
Using zero for the first thing when counting is a bit atypical, though, as most people count their fingers (or anything else) using "one," "two," "three" and so on and do not count their fingers using "zero" for the first finger. Although our everyday experience of counting things such as our fingers argues against starting with "zero" for the first item, there is a very good reason why some programming languages and numbering schemes do so: that is to preserve the ability to do modulo arithmetic. In the case of image libraries if we number from zero we make it easier to retain a common naming scheme if intermediate levels are used.
The reason is that intermediate level images will be arranged by their names which, to facilitate a modulo arithmetically related connection to lower level images are always zero based. That is a mask of level[L]position[X:1][Y:1].tif will mean that a name of level2position00.tif is the corner second level image.
Notes
If we have Enterprise Edition installed, image libraries may be shared on an Enterprise server. Note that the image tiles are not actually stored on the Enterprise server: instead, the image tiles remain in the folder where they are located
If image tile files are accompanied by more than one different type of accessory projection file, then any XML files will be read first and other projection files ignored, next any PRJ files will be read, then any GSR files and finally any world files will be read. If image tile files are not accompanied by any projection files, or if the accompanying files are not in the correct format, the system will use coordinate system data embedded within the image files themselves if the image files are GeoTIFF, ECW or JPEG 2000 files.
Image libraries have many uses. They are especially handy when converting large numbers of legacy image files into a modern format such as ECW: assemble an image library from the many small legacy image files, unlink the image library to create a single image and then export the image as an ECW.
Manifold will use more than one thread to render image libraries if more than one processor or processor core is available on the computer system. Therefore, image libraries will render faster on multiprocessor or on multi-core processor systems. For example, using a dual-core processor will allow image libraries to render faster.
Tech Tip for Experts: Level Nomenclature Illustrated
If you never plan on manually using intermediate levels, you can safely skip this part of the topic. Use the Automatically save intermediate levels option and Manifold will create intermediate levels for you automatically and take care of all naming details. This discussion is intended for experts who will be manually working with intermediate levels.
Even for experts, the naming scheme used for levels can be confusing. It's best to use some illustrations to sort things out.

Consider an image library created from 25 image tiles. For this simple example, each image is 100 x 100 pixels in size and contains a solid green color. The illustration above shows the image tiles forming an image library with borders showing the edges of each tile.

We've now added labels that show the name used for each tile. The tiles were arranged into an image library using the Arrange images using filenames option. The mask used was
L[L]_[X:1][Y:1].tif
... with zero-based numbering so that a filename such as L0_20.tif means the file is the third X position over from the origin in the lower left, and is in the first Y row. The number 0 after the L in the filename means this tile belongs to the zero level, that is the first and highest resolution set of images.

To keep things simple, we will change the labels in the above illustration to simple X:Y representation so we can see more directly how the X and Y numbering scheme works. So far, so good.
Now lets show another layer of images that represent an intermediate level of images.

Shown in blue we see four images, also using the same mask of
L[L]_[X:1][Y:1].tif
...as a template for their file names. There are only four blue tiles, not quite enough to cover all of the green tiles. This set of illustrations deliberately does not use enough blue tiles to cover all of the green ones so that the illustrations can show both some uncovered as well as covered lower level tiles. Note that all of the blue image tile names begin with an L1 to indicate they are on the next level up from the zero level.
A nuance: it is easy to mistakenly think that a single intermediate level image must be 200 x 200 pixels in size if it covers four more detailed images which are 100 x 100 pixels in size. That's not true. The intermediate level image is also only 100 x 100 pixels in size, but when it is displayed it is automatically scaled (making its pixels "larger" or "smaller") so that it covers the same geographic region as four more detailed images. It covers four times as much ground using the same number of pixels, hence it is less detailed because one pixel in the intermediate level image cannot convey the same level of detail that four pixels in the more detailed level show. That doesn't coarsen the visual display because the intermediate level image is only used when the image is zoomed far out enough that the greater number of pixels in the more detailed images would in any event go to waste.
Let us now look at the numbering of these blue intermediate level images together with the numbering of the green images.
To make that easier to see, we will change the labels used on the blue images to X:Y labels as well, and we will move the labels on the blue image tiles from the center of the tile down to the lower left corner of the tile.

The above image shows the green tiles with their name numbering scheme indicated in X:Y form as labels in the center of the tile. The blue tiles also have their name numbering indicated in X:Y form in the lower left corner of the tile. There are two things we can see from this comparison:
First, both the blue tiles and the green tiles use the same mask, which provides a pattern for how each tile should be named based on its position in the image library. The same pattern applies to both the green and the blue tiles. In both cases, the leftmost lowest tile (at the origin) uses 0:0 for its naming. The three tiles adjacent to the leftmost lowest tile in both cases are named 0:1, 1:0, and 0:0.
Second, we can see why, as a result of modulo arithmetic (that is, integer arithmetic discarding any remainder), it makes sense to use zero based numbering when levels are involved. If we use zero based numbering we can easily calculate for each lower level tile what numbering name should apply to any higher level tile that covers it.
In our above example, each blue tile is twice (2 times) the size in X and Y of each green tile. Consider the green tile at the 3:2 position. What should the numbering name be of the blue tile that covers it?
To get the X part of the name we divide 3 by 2 and get 1 (three divided by two to get an integer without any remainder or decimal fraction is one). So the name will be 1:something. To get the Y part of the name we divide 2 by 2 and also get 1. So the name should be 1:1 and, indeed, 1:1 is the name of the blue tile covering the 3:2 green tile.
If we repeat the above arithmetic for every green tile we can see that it works in all cases to accurately predict the name of the blue tile that covers that green tile. If we extrapolate how any additional blue tiles would be named going to the right and upwards we see that the rule continues to work.
This rule may seem to be almost idiotically simple, but it not only can simplify programming that works with image libraries, it can also help save us from simple mistakes. It is such a strong and useful rule that level names always use zero based numbering.
We must keep that in mind to avoid conceptual errors. Let's consider an example of a possible conceptual error.

Suppose we have only four green tiles, and we have named them using one based numbering, that is starting the lower left tile at 1:1. The above illustration shows those four image tiles along with an empty matrix of where other tiles would be placed by name if they existed (and, in the case of green tiles, if we were to use zero based numbering).

Now, suppose we have created a single, new intermediate level image (shown in blue) that covers a region four times larger than a single green tile. If we name this image 1:1, see where it appears in the positioning matrix: it is not aligned to the lower left of the four green tiles but instead is aligned to the 2:2 green tile.

This is exactly what one would expect from the modulo arithmetic of the matter since 1 divided by 2 is zero using integer arithmetic. The 1:1 green tile is covered by what would be the 0:0 blue tile as can be seen from the illustration above.
So what would an actual image library consisting of many high resolution green images and four lower resolution blue images actually look like?

If we recall the situation shown above, we see that the four lower resolution tiles do not fully cover all of the green tiles.

If we open the image library and zoom far enough into the image library all we will see will be the green tiles. When we are zoomed far into the image Manifold will use only the highest resolution tiles.

As we zoom farther out, at some zoom level Manifold will begin using the blue image tiles since their lower resolution is a better match to the zoom level. In regions where there are no intermediate levels Manifold will have to interpolate on the fly from the higher resolution, green images.
Let's consider a photographic example using images of San Francisco Bay. We will use images that are all 200 x 200 pixels in size. Because they are identically the same size we can use the Arrange images using filenames option and manually specify an intermediate level image to use.


The overall image library will use nine images. Four of those images are seen above. These four images will occupy the lower left hand region of the image library.

We will also use one intermediate level image, seen above, which is also 200 x 200 pixels in size.

The intermediate image will cover the four higher resolution images in the lower left corner using the naming scheme shown above.
We will use the same mask as before so that the intermediate level image is called L1_00.tif and the nine higher resolution images have names such as L0_00.tif, L0_01.tif, L0_10.tif, L0_11.tif and so on up to L0_22.tif

When we open the image library window it looks like the illustration above, which has had an index drawing for the image overlaid on the image in a map window.
The index drawing has been formatted with transparent area background so the image can be seen. The area borders of the index drawing have been thematically formatted according to the value of the Tile Level field and labels have been automatically created using the X and Y columns from the index drawing. [The astute reader will immediately see that the illustrations for this topic have all been created in Manifold by using appropriately formatted index drawings.]
In the above illustration the intermediate level drawing does not cover all of the higher resolution tiles. It only covers the region within the red border. The regions outside of the red border are being interpolated by Manifold directly from the higher resolution images to create a seamless image mosaic regardless of which part comes from a higher resolution, lower level image and which part comes from a lower resolution, intermediate level image.
In fact, Manifold does such a good job at this that without the red border seen above it would be very difficult to tell by eye where the intermediate level image ends and where the higher resolution, non-overlapped images begin. Even if we carefully zoom in and out to be sure that we are seeing both the intermediate image and the high resolution images (just on the edge of the zoom value that would stop using the intermediate image), it is difficult to tell where one ends and the others begin.

It's easiest to see if we have a magnifying glass and can take a closer look at the actual pixels being displayed on the computer monitor. Seen above is a magnified view of a captured screen shot that shows the border between the intermediate image (lower part of the illustration) and the higher resolution images (upper part of the illustration). Note that the pixels in the lower image are "fatter" because they have to be inflated to cover four times the region each pixel in the higher resolution image can cover.
The above illustration shows one of two artificial effects at play in the illustrations in this documentation that are not typically found in image libraries in the real world:
Usually when intermediate images are used they have been automatically calculated so that they cover any higher level, more detailed images. There is never an opportunity in such cases to see both an intermediate image and a higher resolution image together to make a comparison so we never see a difference in pixel size as seen in the image above. In such cases Manifold seamlessly switches between using different levels as appropriate for the zoom level displayed.
To keep the example illustrations small enough to fit conveniently into this documentation, the intermediate image used above is only twice the X and Y extent of the higher resolution images. That makes the resolution difference relatively small so that the eye doesn't notice it as a great change even when the two resolutions are seen together. A more normal case would be to make a jump to four times the size so that each intermediate image covers sixteen higher resolution tiles.
Tech Tip on Performance
Image libraries are designed to work with large sets of small files, the kind that one gets when browsing an online mapping site such as MapQuest or Virtual Earth. Image libraries can be used with small sets of large files but performance will be significantly worse.
If we have ten large image files, it is better to use them directly without joining them into an image library. This can be done by showing the images together in a map with each image a different layer.
Alternately, if a single image is desired import the images into Manifold, uncompress them if they are in a compressed format, use Copy and Paste to create a single large image and then save the result as a single ECW or JP2 file. This process is tedious and very slow for large images but once the single large image has been created and saved as a ECW or JP2 file thereafter it will import and display with great speed.
The fastest way to store images is to use a spatial DBMS. Manifold can save images that are even tens of gigabytes into a spatial DBMS and then pan/zoom the image almost instantly.
See Also
Intermediate Levels and Pyramids