This topic assumes we have read the Tables topic as well as other introductory topics such as the Getting Started and User Interface Basics topics.



icon_image.png Images in Manifold provide a visual display of raster data, that is, rectangular arrays of pixels, stored in tables in the form of tile fields. Images are just a different way to see the information that is stored in some table:  an image cannot exist without a table somewhere that has a tile field from which it draws the information it displays.   Raster data can be many 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 also include layers that are other drawings, labels or images.  For example, an image might contain a drawing layer above it that provides context for the image below.  


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 Edit - Style dialog 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.

Many types of raster data

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.  

Storing Rasters in Tables

i_img_in_tiles01_00.pngWhen 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 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 nearby  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.


Importing Compared to Linking

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.


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 with 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.   


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.

Palette Images

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.




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 choose Edit - Style to open the Style dialog.




In the Style dialog we can see the image uses a Common color channel for the RGB primary colors with the palette used shown in the tally pane.   The palette is also exposed via the image's properties in the mfd_meta system table.


We can also open the image's table to see the type of data in the tiles.




For this image each tile is a 128 x 128 array of pixels where each pixel has a uint8 numeric value for the pixel.  With only one numeric value per pixel we know it is a palette image.


To see the palette used, with the focus on the opened image window we choose Edit - Style to launch the Style dialog.  



In the Style dialog we can scroll through the tally pane to see the different colors used.




The colors used are fully editable.   We can double-click into any of the colors and choose Custom to launch a color picker dialog that will show us the values assigned.


The palette shown in the Style dialog is fully editable:  by double-clicking into the color wells we could change the colors in use by the palette.




For example, if we wanted we could double-click into the various dark and green colors and change them to bright red.   We click Apply to apply the change and then Close to close the Style dialog,




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.

Intermediate Levels

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.



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: 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.




icon_message_red.pngTech tip:  If you open an image and do not see anything see if there is a message icon.   If so, choose View - Messages and build intermediate levels if there are none or if they need updating.   It could be that no intermediate levels have been built for that image so it will not appear at the zoom level required to zoom to fit, the default display


"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.   


What Manifold calls an image may simply be called a raster in other software packages.   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.    


Raster data intended to be displayed as photographic images, after all, can have one channel or multiple channels.   Raster data that is terrain elevation data might be intended for a variety of purposes, such as building 3D models, but more often than not it is simply displayed as an image of some sort, perhaps styled to be hill shaded and using a palette, but nonetheless displayed as an image.


It is really a toss-up whether a software package takes a more technical approach to nomenclature and uses terms like vector data and raster data, or whether it takes the broader approach of referring to drawings and to images, using drawing as a synonym for vector data and image as a synonym for raster data. Manifold takes the latter approach.  Raster data components are called images in Manifold since that is a more familiar word in most cultures for pixel-based data

See Also

Getting Started


User Interface Basics




Intermediate Levels


Images and Channels


Palette Images




Style: Presenting Images


Style: Autocontrast


Style: Palettes


Style: Formatting Drawings and Labels


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 Edit - Style dialog to change the contrast of an image.


Example: Use the BGR Button to Assign Channels - The BGR button in the Edit - Style dialog for images allows us to assign channels in the data to B, G and R outputs that create the displayed image, using BGR, RGB or Grayscale ordering.


Example: Assign Channels using Source - The Source control in the Style dialog for images assigns channels to display outputs such as R, G, B or A.  .  This topic shows examples of using Source and the visual results.


Example: Set Image Transparency using Alpha - The A row in the Style dialog 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 Edit - Style dialog 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 Edit - Style dialog 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.