Images
provide a visual display of raster
data stored in a table.
The image is just a viewport that displays data: all of the data
is stored as records in the table from which the image takes data to show.
More than one image simultaneously can display data from the same
field in the same table, with each image displaying pixels differently
using different style. That allows us to show the same data in different
visualizations.
Image in Manifold is the name used for all kinds of raster data, including photographic images, terrain elevation data, aerial photographs, satellite images, multispectral data, and other raster data. Raster data consist of rectangular arrays of pixels, stored as tiles in tables, with one tile per record.
Images take zero storage
space. All the data for the image stays stored in the table.
We can create as many images as we want that all visualize data
from the same table, using different
styles for each such image, without making the .map
project file any bigger.
Image windows can also include temporary layers that are other images, labels or drawings. For example, an image may use a background layer that is pulled from an imageserver, such as a Bing, Google or OpenStreetMap server. Such temporary layers are lost when the image is closed. To permanently save an image with a layer structure, save it as a map using the Edit - Save as Map command.
An image shows data from a tile field in the table. A tile contains a rectangular array of pixels, such as a 128 x 128 array of pixels, where each pixel has one or more data values, called channels. For example, pixels for RGB images have three data values for each pixel, a value for each of the Red, Green, and Blue channels. Pixels for raster data that represents terrain elevations typically have one data value for each pixel, giving the height at that pixel. Pixels for images that use four bands, for example, pixels that contain Red, Green, Blue, and Infrared bands, or RGBa pixels that include an alpha (transparency) channel, will have four values per pixel.
We can Copy an image and Paste to create another image that shows the same data from the same table. We can then Style that image to use totally different parameters, such as a different palette, different hill shading, different arrangements of channels, or different interpretations of channel data, such as different contrast. Any such extra copies of images we create will not increase the size of the project, because the data they all show will be taken from the same table. Making copies of an image is a great way to get different versions of the same image, with different style settings, as shown in the illustrations of four Florida images below.
A table can contain more than one tile field for each record. That allows us to have multiple different representations of each record.
For example, table for an image might have one tile field that contains terrain elevation heights, a second tile field that contains a computed curvature, and a third tile field that contains an RGB imagery tiles. Normally we would keep such data in separate tables, but it could be combined in the same table. Three different images can simultaneously show data from each of the three different tile fields in the same table.
Images are just a different way to display pixel data that is stored in a table: an image will be empty without a table somewhere that has a tile field from which the image draws the information it displays. The image component contains just a few bytes of data, which we can see in the image's Properties, that specify which table stores the data to be visualized and what field in that table contains the tile data the image should display. All of the actual pixel data is stored in the table.
All four images illustrated below use the same table and the same data: the images were created by Copying the Florida image and then Pasting it three times to make three copies, with each copy styled differently, using a different palette and different arrangement of intervals to show terrain elevations. Each image simply provides a different way of visualizing the same data:
If we want to copy
an image and paste it into a different Manifold project, we must remember
to copy both the image as well as the table from which
the image displays data.
Raster data can be a photographic image, like the aerial photo of the Eiffel Tower at the beginning of this topic, or many other types of data, such as terrain elevations, ranges of temperatures, concentrations of chemicals or other data not intended as a photographic image. Raster components are called images in Manifold since that is a more familiar word in most cultures for pixel-based data.
Image windows can contain layers just like a map. See the discussion of layers in the Maps topic. We can add images, drawings and labels as layers to an image window, for temporary viewing. A key difference between layers in a map and layers in an image window is that hosting layers is the reason to have maps, while adding layers to an image window is a temporary convenience to allow us to quickly see the image in the context of other layers. In general, if we want to use layers we should use a map. It is so easy to add layers to an image window that it is easy to forget they are temporary. To save work invested into a nice arrangement of layers added to an image window, Manifold provides the Edit - Save as Map command.
An image window always contains the originating image as a layer, and the image window will always use whatever projection the image uses. If we change the coordinate system of the image, the image window will automatically use that different coordinate system as well. If any other layer is added to an image window, the image window will re-project that layer on the fly into the coordinate system used by the image and the image window.
Open the image by double-clicking it in the Project pane.
The image will appear as the only layer in the image window. The image window will use the projection of the image.
Drag and drop any additional desired layers from the Project pane into the image window.
The image window will automatically re-project on the fly all layers into the coordinate system used by the image.
Rearrange layers by dragging their tabs left or right, or by using the Layers pane.
Layers in an image window are temporary. To save the layer arrangement, use Edit - Save as Map.
There are three key differences between layers in a map and layers in an image:
Layers in image windows
are temporary: when we add layers to an image and then arrange
those layers in order, if we close the image and then open it again those
layers will be gone. To save the layer structure added to an image,
choose Edit - Save as Map and
save the window, together with the layers as specified, as a map.
Most images we use will be images created automatically when we import or link raster data from files or data sources that contain images. Such images will normally be imported using default style, which usually works well for photographic images but which will often require application of Style to provide a useful display of non-photographic rasters. We can also add layers to help understand the image better.
We now take a quick look at a non-photographic example of raster data as an image to see how layers in image windows can help us understand the data.
We import an image as described in the Example: Import DDF SDTS DEM Raster File topic. Opening the image, we see it uses default grayscale styling. We will improve on that in a moment.
The SDTS format from which we imported provides coordinate system information so the initial coordinate system is automatically correctly assigned.
The Info pane reports the image to be in UTM Zone 10 (N). The image's window therefore also uses UTM Zone 10 (N). An image's window always uses the same projection as the image. Any other layers dragged and dropped into the image's window will be re-projected on the fly into that projection for display so they will line up correctly with the image in the image's window.
We can see how that works by adding other layers to the image window. Normally we would use a map to display multiple layers, but we can also add layers to an image window as well.
We drag and drop two imageserver layers into the image window, one below the elevation raster and the other layer above it.
The layer we add below it is an ESRI layer, the world shaded relief layer, from the ArcGIS_REST_Servers.map sample collection of image servers, which may be downloaded from the Product Downloads page on the Manifold web site. That layer provides a hill shaded terrain background.
The layer we add above is a Google transparent streets image server layer, which provides streets and town labels with transparency between the streets and labels so the layers below can show through.
Right away we see that this particular image shows data located on the Eastern side of the Livermore valley in California. If we have a good eye and we are familiar with Google we will see that the Google layer has a very slightly distorted look. That is because Google uses Pseudo-Mercator projection, but when the Google layer is seen within this image's window it is being re-projected on the fly into UTM Zone 10 (N) projection.
Just like with drawings and labels, we can change the appearance of images using the Style dialog. That applies to all raster data, which Manifold calls images, including satellite photography, terrain elevation data, and raster image representations of vector data served by WMS and other web servers.
To better understand the data we can apply Style as illustrated in the Example: Import DDF SDTS DEM Raster File topic. In the Image tab we apply a thematic format that applies the Altitude palette, and then we click on the Options tab and turn on hill shading.
The result is a much more understandable display.
For more context, we could zoom out a bit. If we zoomed further out, we would see the 1475 ELEVATION Raster image is located just to the East of the San Francisco Bay region.
All data in Manifold is kept in tables. Viewing windows like drawings, maps and images do not contain any data: they just visualize data from fields in tables based on what that viewing window has been told to show and how it has been told to show it. For example, we can have as many images as we want that all show the same data from the same field within a table with each image providing a different Style, a different selection or even a different subset of or different computed values for pixels.
Each image opens as a viewing window that displays the data from a tile field in some table. More than one image can display data from the same table and even from the same field. The image does not duplicate the data that is in the table; instead, the image just shows the data in the table using whatever are the display properties of that particular image, as specified in the image's Style pane and other dialogs. For example, two different images can show data from the same table with different contrast settings to show that data.
If we copy an image and paste that image we are just making a second copy of the "viewport," as it were, and not making a second copy of the actual data. The data, as always, stays in the table. If we want to make a second copy of the data we should copy and paste the table.
Images provide a visual display of many different types of pixel-based raster data, data that intrinsically is organized as rows of pixels, and which for the sake of efficiency is stored as tiles in a table. Each pixel in a raster data set has a value that could be either a single number or a vector numeric value, one of the data types described in the Tables topic.
Ordinary consumer applications like Adobe Photoshop or Microsoft Paint encourage us to think of images as simple RGB images made up of rows of pixels where each pixel shows a color that is defined by the three red, green and blue integer values for that particular pixel. Most consumer images are small as well, rarely over a few tens of megabytes in size.
Raster data encountered in spatial data or other big data can be far larger, easily involving tens of gigabytes of pixels and more complex data where each pixel is a vector numeric value, such as a quad (four numbers) of float64 numbers.
Such data might represent not a visual image but scanned data acquired by radar, multispectral sensors on satellites, scanners measuring temperatures and other devices that acquire enormous numbers of pixels at once to gather information about terrain heights, the composition of materials, the species of trees in forests, the temperatures of scenes, the presence of subsurface structures and many, many more applications.
The nearby illustration of Australia around the Gulf of Carpentaria shows gamma ray intensities that reveal the prevalence of radioactive potassium (red), uranium (blue) and thorium (green). It is a classic example of non-visual data that has been colored in "false color" to convey the data content visually. At a glance we can see where all three elements are distributed: all three elements abound in white regions, purple regions abound in uranium and potassium but are poor in thorium and turquoise regions abound in uranium and thorium but are poor in potassium.
Much raster data, of course, represents a visual image such as a high resolution satellite photo of the sort stitched together in applications like Google Earth. For example, the image at the top of this topic shows the Eiffel Tower in an image snapped by a satellite.
What such raster data sets have in common is that they typically involve large data sets, they often involve some sort of spatial context such as geographic location or a coordinate system (projection) used to acquire the data and they usually can be visualized in some meaningful way by simple relationships between colors and the numbers that are attached to the pixels as values.
In Manifold we use the word image as a synonym for raster data set with the understanding that what we call an image, while it may be conveniently visualized in some way, may just as likely be some abstract raster data set representing non-visual data like temperatures or gamma ray intensities as it may be intended as a visual image like a photograph. We also will use the word raster as a synonym for image and for raster data set.
When we import
a raster data set Manifold converts the pixels stored in the original
file format into records in a table, with each record storing a tile's
worth of pixels, with an appropriate data type used for the pixels within
the tile. Manifold will then create an image based on that table
so we can visualize the raster data in an image window.
For example, if we import an image from a file called bronze.jpg that contains an image of a bronze equestrian monument in Paris, Manifold will create a table called bronze Tiles and an image to display the data in that table called bronze. So why does Manifold store data in tables instead of packing into some sort of image container like regular graphics editors do? The main reasons are to provide support for very large images, to do so in a way that is orthogonal, that is uses the same sorts of interfaces and approaches as other big data source such as databases and tiled web servers, and finally, to ensure the data can be sensibly reached within a table by SQL and other "everything is a table" mechanisms within Manifold.
Storing big data within tables is not as simple as saving each pixel as a single record at the one extreme or, at the other extreme, storing the entire image as one huge blob in a single record. Fetching big data at the rate of one pixel per record requires far too many fetches of records, each of which is too small. At the other extreme, storing an entire image in a big blob within a single record in a blob is fine for smaller images within tables containing many small images, but that approach breaks down when images are large: storing 15 GB of pixels in a single record is poor design, with each record being too large.
The approach that works best, as many applications independently have determined in their various ways in modern times, is what Manifold does: each image is stored in its own table, with the image data being stored as one tile per record where each tile is some convenient array of pixels, typically on the order of 128 x 128 or similar size.
Consider the illustration above, which shows our bronze sample image, a very small image that requires only four 128 x 128 tiles with 3 channels per pixel to store, a mere four records in a table. The illustrations show the opened image and the opened table for the image, with arrows showing how the tiles that are records in the table compose the image based on where they fit within the X,Y matix that says where the tiles should go.
The illustrations show non-square tiles in the actual image because the image size does not evenly divide into modulo 128 by 128 square tiles. Tiles easily handle that situation at the edges of images where full tiles are not used. We can see that tiles do indeed store data for regions of an image by setting tow of the tiles to a NULL value.
Where the tile values have been set to NULL the image disappears, because there are no pixels in those regions.
Using tiles to store image data provides many operational benefits. To name just a few, we can query data from the middle of a big raster without having to read through many rows or columns of unwanted data, we can leverage sparse storage to avoid wasting storage space where there is no data, we can effectively utilize tiles to build intermediate levels that provide faster rendering at zoom levels other than a native one pixel per monitor pixel and we can increase or decrease the dimensions of a raster image without rewriting the entire raster.
When we import a raster data set Manifold converts the pixels stored in the original file format into tiles stored within a table, with an appropriate data type used for the pixels within the tile. Manifold will then create an image based on that table so we can visualize the raster data in an image window. When we link a raster data set Manifold will leave the pixel data in the original file format while the dataport on the fly creates within the project an interface to that pixel data that is, once again, a table with the pixel data shown as tiles plus an image based on the table.
In the case of an import the raster data is brought into Manifold and organized in a Manifold table as tiles. In the case of a link the raster data stays in the original file or source in whatever original form it is stored or provided while the dataport connecting that source into the Manifold project automatically presents the data as though it were stored in a table as tiles.
To fit into this documentation, illustrations show an artificially small Manifold desktop, with only two panes, docked to the right side. In real life we use a much larger Manifold desktop, and all panes would be turned on, with some panes docked to the left and others docked to the right.
We can see the translation on the fly into Manifold representation by taking the sample bronze.jpg image used in this topic's examples and linking it into a Manifold project:
Linking the bronze.jpg image into the project creates a new data source with a table, bronze Tiles, and an image, bronze. If we open the table we see that it has four records, each containing a 128 x 128 tile.
In the illustration above we have right-clicked the column header for the Tile field and chosen Style, to change the format for the Tile field from the default format that shows the size of the tile and the number of channels, to a format that reports the size of the tile as well as the data type of each channel and the number of channels.
The Tile field reports that each tile has three channels, a triplet vector numeric value for each pixel that is three uint8 types, the classic way RGB color values are represented for a color image.
If we double-click open the image we see that it is, indeed, the sample bronze image in our project. But nothing about the linking process in any way altered the contents of the JPEG file that is the source for what Manifold shows us as a table with tiles or the image created from that table. The JPEG stays the same it always was, a file full of bytes encoding an image using the JPEG standard but definitely not storing pixels as tiles. The Location readout has been set to report pixel coordinates, a useful setting for non-geographic images.
When Manifold shows us the linked image as if it consisted of a table storing tiles that is Manifold computing and translating on the fly to make the data within the JPEG appear to be in Manifold infrastructure form so that we can work with it seamlessly like all other data in our Manifold project.
Most images we work with will use channels to assign data to Red, Green and Blue display pixels in a monitor. To learn how to operate channel controls, see the Style: Images topic as well as the many step by step examples using channels.
Starting with an RGB image as seen above, the Ginevra de' Benci by Leonardo da Vinci, the Style: Images pane allows us to manipulate what data is used for which channel.
See the discussion in the Images and Channels topic as well as in the Example: Assign Channels topic.
Many images are visualized by simply taking the values for pixels within tiles and, if they are a single value, displaying them as a monochrome scale from black to white, resulting in a grayscale display, or using triplets of numbers as RGB values or quads as RGBA, that is RGB plus an "alpha" channel indicating a level of transparency.
Another type of image is a palette image, where a single number per pixel is interpreted as an index into a table of colors. The pixel is colored with whatever color that number indicates in the table.
To fit into this documentation, illustrations show an artificially small Manifold desktop, with only three panes, docked to the right side.
If we import an image from a format that stores images as palette images we will see the image appear in the Project pane just like any image, along with the table that stores the data for the image. The quickest way to see it is a palette image is to use the Style pane, illustrated below as an undocked pane.
To see the type of pixel data stored as tiles we can open the image's table:
For this image each tile is a 128 x 128 array of pixels where each pixel has a uint8 numeric value for the pixel (we have again right-clicked the Tile column head to change the format to showing the data type used by pixels). With only one numeric value per pixel we know it is either a grayscale image or a palette image.
We close the table and we switch to the Style pane.
To provide more vertical room in the Style pane, we undock the Style pane by Shift-clicking the tab. We can now resize the Style pane to be very tall:
In the Style pane we can see the image uses a single color channel, Channel 0, conveying the numbers to be used for the palette shown in the tally pane. The palette is also exposed via the image's properties in the mfd_meta system table.
We can scroll through the tally pane to see the different colors used.
The palette shown in the Style pane is fully editable: by double-clicking into the color wells we can change the colors in use by the palette. In photographic images we do not normally do that manually, but if we want to we can for special effects or to mark certain zones of color.
To change many color wells at once it is quicker to use selection. We Ctrl-click on the top row desired to select it, and then we Shift-Ctrl-click on the bottom row and all rows in between are selected.
When we double-click into any of the selected color wells and change it to bright red, all of them are changed from various dark and blue colors to bright red. We click Update Style to apply the change.
The image will be displayed using the palette as we have modified it to replace the original colors to bright red for the selected palette color entries.
See the Palette Images topic for a discussion of palette images.
Large images contain far more pixels than can be seen at once on a computer screen. A typical monitor with resolution 1920 pixels wide by 1440 pixels high shows less than three million pixels but a 30 GB image can easily have ten billion pixels in it.
When we display an image with ten billion pixels in it on our monitor with a Zoom to Fit command the system cannot show all ten billion pixels so instead it shows an approximate view that fits into the less than three million pixels available. The approximate view shown is not the real image: it is a summary. As we zoom further into the big image we see other summaries of the different parts of the big image that fit into whatever is the zoom level we are looking at. Such summary views are called intermediate levels. See the Intermediate Levels topic for background.
Intermediate levels can take a while to compute: to compute an intermediate level image that will fit onto a typical monitor for an image that has ten billion pixels can take a fair amount of computation. Manifold, like most packages that work with large images, can reduce that time by pre-computing information for intermediate levels in advance. That allows much faster panning and zooming.
Such pre-computation is normally done on a one-time basis when the image is first imported or linked. However, if the image changes or otherwise intermediate levels need to be recomputed, we will see a red message icon in the lower right corner of the image. Choosing View - Messages will show a message that image data for intermediate levels is out of date and will provide a button to update the data. Until we update intermediate levels we may not be able to see the image at certain zoom levels.
We can add layers to an image window as a temporary convenience and the image window will show those layers like a map window does. However, while a map maintains its layer structure even after the map window is closed, layers in an image window last only as long as that window is open. If we close the image window and then open it again, it will have only one layer, the image itself.
If we have added layers to an image window and want to keep that organization of layers with the image for later use, we choose Edit - Save as Map to save that window with its collection of layers as a map. Maps take zero space since in actuality they do not store any data: they are simply references to other components that are the constituent layers of the map. Therefore, we should not hesitate to ever use Edit - Save as Map to save any interesting or useful collection of layers we have added to an image window.
Images themselves contain no data: they simply provide a viewport to visualize raster (pixel) data that is stored within tables using the tile data type. If a table contains tile data and we know how that tile data is organized, we can create new images based on the table.
The trick is usually knowing the Bounds of the data the tile data contains. Manifold will sooner or later add an auto-compute facility to the New Image dialog that provides this automatically, but for now we must know the Bounds. For an existing image, the Bounds will be given in the Rect property of an image. If we are creating an image from the same table, or from a query which preserves the extents of the data, we can copy the value of the Rect property for the existing image and use that for the Bounds in the New Image dialog.
Right-click on the table in the Project pane.
Choose Create - New Image.
Choose the Tile field to use if there is more than one in the table. Choose the data type in the tile and the tile size if not the default shown.
Choose the X and Y fields to use for tile arrangement.
Check the box to create a spatial index if one does not yet exist.
Enter the correct Bounds value. Unless the image consists of a single tile (single record), the default value of Bounds will be wrong and will need to be changed.
Assign the correct coordinate system if the coordinate system is reported in red text.
Press Create Image.
Open the image, and choose View - Messages to update intermediate levels if necessary.
In the Style pane, specify the desired style.
Just like creating drawings from queries, we can also create images from queries, if the query reports a schema and the results table for that query includes tile data.
Right-click on the query in the Project pane.
Choose Create - New Image.
Choose the Tile field to use if there is more than one in the table. Choose the data type in the tile and the tile size if not the default shown.
Choose the X and Y fields to use for tile arrangement.
Enter the correct Bounds value. Unless the image consists of a single tile (single record), the default value of Bounds will be wrong and will need to be changed.
Assign the correct coordinate system if the coordinate system is reported in red text.
Press Create Image.
Images created from queries will appear only when used as a layer in a map that contains at least one other layer.
To update the image after any changes in source table data, choose View - Refresh.
Open the image, and choose View - Messages to update intermediate levels if necessary.
In the Style pane, specify the desired style.
We can create an image from a query if the query's results table contains a tile field. The query must also report a schema if we right click on the query in the Project pane and choose Schema. The source table for the X, Y and Tile fields reported in the result table should have a spatial index on those fields. If the query text is changed, we must run the query at least once after changing the text, so that any future refreshes of the image will use the new query text.
We can also create an image from a database view that provides a result table matching the above criteria.
Given that we must know the Bounds of the data in the table to be able to create an image from that table, as a practical matter for now we will usually create images for tables where already there is at least one image created on that table. We can then simply copy the Rect value from that image's properties and paste that into the Bounds box in the New Image dialog. Likewise, for now we will usually create images for queries where the query does not change the bounds of the table for which an image already exists.
Images are popped open in Manifold zoomed to fit the size of a new, docked image window, given whatever is the size of the Manifold desktop and the space available next to any docked panes. That normally will involve some interpolation to put more or fewer image pixels into each pixel in the display screen, since it is not likely that the docked size of an image window will match the pixel dimensions of the image we open.
If we want to see the image in native scale, where one pixel in the image occupies one pixel on screen we choose View - Zoom to Native. That command will automatically zoom the image in or out so that one pixel image is exactly one pixel on screen.
In most cases, we will run out of machine resources before hitting any limitations of Manifold. There are a few limitations that may be encountered even in large machines:
256 GB max size for .map files - Using 64-bit Manifold, the amount of data stored within a .map file cannot be larger than 256 GB, although a .map file can contain data sources linking to a DBMS that contain far larger data, petabytes, in size. The maximum size limitation will be increased in future builds.
256 GB max size for changes to data - .map files can work with data far larger than 256 GB when that data is stored in external data sources, such as an enterprise class DBMS. Although there is no theoretical limit to the size of data Manifold can work with on the desktop, a hard limit on the amount of data that can be changed in a single operation is 256 GB. For example, if we have a single image that is 1 terabyte in size we can display that and manipulate it, but if we want to change all of the values in all of the pixels in the image we will have to do that in four operations, each up to 256 GB in size. The 256 GB limit is the current, somewhat arbitrary, setting for temporary caches utilized internally by Manifold. This limitation will be increased in future builds.
16 terapixel limit on .map images - Images stored in a .map file are limited by dialogs to 16 terapixels, that is, no more than 16,000,000,000,000 pixels. Due to compression and other storage methods, that is an outer bound that will not be reached before other limitations, such as the maximum size of a .map file or the maximum number of tiles in a table, will be reached. This limit might be hit accidentally when using the Reproject Component dialog to reproject an image, using an unrealistic size for pixels.
2 billion tiles in .map images - Because individual tables stored within the .map file cannot have more than two billion records in the table, an image that takes tile data from a table stored in a .map file is limited to 2 billion tiles. This limitation will be increased in future builds. Tables stored in external data sources such as Oracle can have many more than two billion records, so images based on those tables can have many more than two billion tiles.
See the Limitations topic for a current list of limitations.
Message Icons
- If we double-click open a component and a red message
icon appears in the window's lower tab, we should choose View - Messages
from the main menu to read the message. Blank drawings showing
a message icon usually indicate lack of a spatial index,
which Manifold will offer to build for us. Blank images showing
a message icon usually indicate a need to build or update indexes or intermediate
levels, which Manifold will offer to do for us.
Pixels are Visible or Invisible - Pixels in Manifold images can be visible or invisible, a flag used in addition to whatever an alpha channel specifies for the opacity of the pixel.
Getting X, Y pixels from tiles - Grouping many pixels into a tile for each record is a much faster way to store images than to store individual pixels as records. Sometimes, however, we might want a table full of individual pixels. That is easy to create using a bit of simple SQL. Give a table for an image called alps, with single-channel tiles of the default 128 x 128 size, we can produce a table with a record for each pixel and x, y, and value fields for each record:
VALUE @tilesize_x INT32 = 128;
VALUE @tilesize_y INT32 = 128;
SELECT tile_x * @tilesize_x + x AS x, tile_x * @tilesize_y + y AS y, value FROM (
SELECT x AS tile_x, y AS tile_x, SPLIT CALL TileToValues(tile)
FROM [alps]
);
The inner query splits all tiles into pixels and keeps the tile X and tile Y coordinates for each pixel, along with the value for each pixel. The outer query combines tile X, Y coordinates and pixel X, Y coordinates within a tile into overall pixel X, Y coordinates within the image, reporting also the value for each pixel. We can convert the outer query into a SELECT .... INTO query to write the results into a table.
Everything is a table - Spatial data in Manifold is stored in tables. Spatial data in tables is also self-describing, with the system using indexes on that spatial data to describe the structure of that spatial data. Drawings and images that show spatial data in visual form are used only for visual display purposes. When topics such as this one show tiles in visual settings like images, those visual displays are just a convenient user interface for interacting with the actual spatial data (in the case of images, the spatial data being tiles), which remains, as always, stored in the associated table.
Image = Raster - What Manifold calls an image may simply be called a raster in other software packages. Manifold also uses the word raster. Earlier Manifold GIS products up through Release 8.00 used two component types, called images or surfaces, to display raster data. In both cases the data is raster data and whether that raster data is considered an "image" or a "surface" is more a matter of how it is intended to be used and how it is styled for display. Release 9 and later products simply call all rasters images.
"That which we call a rose by any other name would smell as sweet" - So Shakespeare put it in Act II, Scene II of Romeo and Juliet.
Migrating Images from Manifold Release 8 - Opening a Release 8 .map file in Release 9 will automatically migrate images with two nuances:
Migrated images will no longer have a Level field, which is not used in 9.
Compressed images within the Release 8 .map project will be migrated into a new ECW / JP2 image file created in the same folder as the opened Release 8 .map project, and automatically linked into the 9 project. The new file will be named by concatenating the Release 8 project name and an iterated number starting with 1.
Example: How Images use Tiles from Tables - An example showing how an image is made up from data stored in a table in tiles.
Example: Create Two Images From One Table - More than one image can show data from the same table, including from the same tile field.
Example: An Image using Computed Fields in a Table - How an image can be created from tiles where the data for the tiles is taken from a field that is computed on the fly.
Example: Change the Contrast of an Image - In this example we use the Style pane to change the contrast of an image.
Example: Using the Assign Channels Button - The Assign Channels button in the Style pane for images allows us to assign channels to the standard three Red, Green, and Blue display outputs using frequently-desired arrangements. The button provides a short cut way to assign all channels at once instead of doing each channel individually.
Example: Assign Channels - How to use the Style pane for images to assign channels to display outputs such as R, G, B or A. This topic shows examples of channel combinations and the visual results.
Example: Set Image Transparency using Alpha - The A row in the Style pane allows us to specify what transparency we want to apply to the image, either by applying the same value for A for all pixels or by using one of the other channels to also control the A value.
Example: Autocontrast and Hill Shading Images using Style - This example shows how the Style pane can hill shade an image using the values of pixels as heights and generating shadows as if the Sun were located at the specified azimuth and altitude. This capability is used most frequently with raster images to give an impression of three dimensionality in cases where the values of pixels represent terrain elevations.
Example: Style Applied to an Image Server Image - Because the Style pane simply changes the way an image is displayed and not the data, it can operate on read-only data served by various web servers such as WMS REST servers. In this example we look at every detail of creating a data source using an image server and then manipulating the appearance of the display with Style. We will connect to a WMS server that provides LiDAR data in various forms, including as terrain elevation.
SQL Example: Process Images with 3x3 Filters - Shows a step-by-step example of developing an SQL query that takes a query written by the Edit Query button and then modifies that query into a general purpose query that can apply any 3x3 filter. This makes it easy to use matrix filters we find on the web for custom image processing. We extend the query by using parameters and adding a function, and then show how it can be adapted to use a 5x5 filter.