The MapInfo Raster FAQ This FAQ covers frequently asked questions about raster support in MapInfo Professional 4.0. This FAQ specifically deals with the raster engine. The questions are numbered by category. 000 Modification History 00x Raster Formats 01x Zoom Layering 02x Bugs and Hacks 03x Performance 04x Registration and Correlation 05x Display, Colors, and Palettes 06x Engine Limitations Modification History ------------------------------------------------------ Q000: When has the FAQ been modified? A000: 7 Apr 97 - Added 007 and 008. 18 Feb 97 - Updated 043. Added 044, 045, and 054. 6 Dec 96 - Fixed typo of number of colors in A053 from 246 to 236. 4 Jun 96 - Created the FAQ by combining the Knowledge Base and my email message log. Raster Formats ------------------------------------------------------------ Q001: What's the best raster format to use with MapInfo? A001: MapInfo Pro 4.0 supports TIFF and SPOT images with new handlers which were written to handle very large images and still be fast. Of these two, TIFF is the better format. TIFF supports "stripped" and "tiled" raster images, which lets us find and display raster data more rapidly than a "monolithic" image. (SPOT uses monlithic images.) TIFF supports a number of compression schemes. I suggest compressing large images since it is usually faster to decompress an image than it is to read more data off the disk. Both TIFF and SPOT support having georeferencing information embedded in them. Use the GEOREG.MBX program to auto-register images with contain this information. See A006. If the customer has a choice, they should create (or buy) compressed, tiled TIFF images. Q002: Are there any differences with raster images between the 16 bit and 32 bit version of MapInfo 4.0? A002: There are different limitiations on supported raster images when in Win16 and Win32. Win16: Some TIFF images (rare) and all PCX, GIF, BMP, and TGA can be no more than 8192 pixels wide and 32K pixels tall. There is a bug in the JPEG Halo handler which keeps us from properly reading JPEG files larger than 4096 pixels wide or tall. Win32: Some TIFF images (even rarer) and all PCX, JPEG, GIF, BMP, and TGA can be no more than 64K pixels wide OR take up more than 60K to represent a line. For an RGBA image, this means ~15K pixels. Any formats not stated above can be 2 Gig pixels wide. Generally speaking, Win32 supports much larger images than the Win16 version. Q003: Do we handle internally tiled TIFF images? A003: We understand tiled images, but we are not fully optimized for them right now. We originally wrote the handler to be optimized for stripped images. We then added tiled support. Customers should create and use tiled images. We read them now as fast as or faster than strips. Q004: How do I open raster images which MapInfo doesn't support? A004: There is a toolkit and documentation for writing your own format handlers to work with MapInfo. Q005: Why do my SPOT images look different in 4.x compared to 3.x? A005: With the new SPOT handler, SPOT images will look very different than they did in MapInfo 3.x. Since users may have adjusted the contrast and brightness to make these images look good in 3.x, they will look bad in 4.x until you readjust them (See LONDON.TAB in our 3.x sample data). Q006: Do we support auto-registering images? Q006: Do we support GeoTIFF? Q006: Can I use the georeferencing information in SPOT files? A006: Some image formats support having georeferencing information in them. We support two of them: GeoTIFF and SPOT. (GeoTIFF is a standard for putting information in standard TIFF 6.0 files.) You can use the georeg.mbx MapBasic program to auto-register TIFF images which have geo-referencing information in them. Q007: My SPOT image won't load, why? Q007: Why do I get "Invalid Raster Format" whenever I attempt to load a SPOT file? A007: "SPOT files" are actually sets of files. Typically, there are three files in a set. The (required) BIL file is the raster data itself. The (required) HDR file holds the description of the file: it's length and width, etc. The third file (not required) is a STX or CLR file. This file is used to map colors to the raster data. If it doesn't exist, then the image will be considered grayscale. (Of course, if it is actually a color image, it will looks wrong-- there is no way to fix it.) SPOT images all come with these pieces. If they aren't there, then someone lost or deleted them. The following tags are used from the HDR file. They are case insensitive. These are required: NCOLS NROWS NBANDS NBITS BAND_RGB These are optional, but used if present: SKIPBYTES RECORDSKIPBYTES BANDROWBYTES TOTALROWBYTES Q008: I have a SPOT BIL file but no HDR, what do I do? A008: You're in trouble. Without the length and width of the image, it is probably hopeless. If you have the length and width, then make a HDR file with NCOLS equal to the width and NROWS equal to the length. You now need to guess what the rest of the required values are. If you think the image is 8-bit, you can try: NBANDS 1 NBITS 8 BAND_RGB 1 1 1 If you think the image is 24-bit, or the above doesn't work, you can try: NBANDS 3 NBITS 8 BAND_RGB 1 2 3 If it looks like an image, but has the wrong colors, try: NBANDS 3 NBITS 8 BAND_RGB 3 2 1 If none of those settings work, there's still one more thing they can try. Some SPOT images have extra information at the beginning of the file which needs to be skipped. There are two ways to figure out how much to skip. The first is to figure out what (NROWS*NCOLS*NBITS/8) is for the image. If it is smaller than the actual length of the file in bytes, then subtract it from the actual length. Put this value in the HDR like this: SKIPBYTES number_of_bytes If this method doesn't work, the last resort is to examine the file and try to guess where the data begins. Not an easy task, but a last resort nonetheless. If the image still doesn't load, then you really have no chance of making it work. Call SPOT and get a replacement file set for the pieces you lost. See A007 for a list of the required and optional tags. Zoom Layering ------------------------------------------------------------- Q011: After registering an image, I can't see it. Where did it go? A011: The image may merely be off the screen. Try zooming to the extents of the raster layer. If this doesn't work, then the image may be zoom layered. Go to the layer control and shut off zoom layering on the raster layer. See A012 and A013 for more information on rasters and zoom layering. Q012: Why does the image disappear when I zoom on it? A012: We set zoom layering on images so that they shut off when they are squashed down or scaled up a lot. To see the image all the time, go to the layer control and shut off zoom layering on the raster layer. See the A013 for the exact zoom levels. Q013: How does MI determine what minimum and maximum zoom levels to display raster images at? A013: We figure out the zoom level when the raster image is displayed at actual size (1 image pixel = 1 screen pixel) in a typical window (500 pixels across). We set the min zoom level to 1/20th of that zoom (1 image pixel = 20 screen pixels), and the max zoom is set to 20 times that (20 image pixels = 1 screen pixel) Bugs and Hacks ------------------------------------------------------------ Q021: Why do Group 4 compressed TIFF files display slowly? A021: If a customer complains that the display of Group 4 compressed TIFF files is much slower than it used to be, or if they complain that our display of Group 4 compressed TIFF files is too slow, there is a workaround. The workaround is to rename TIFF.RHL (found in the Mapinfo program directory) to TIFF.RHX. This rename should be done when MapInfo is not running. What this does is give Halo first crack at all TIFF files. If Halo (for some reason) says it can't handle the TIFF file, then our TIFF handler will try to handle it. The workaround has the ramifications that we will no longer support: B/W images which are greater than 16K pixels wide. Color images which are greater than 8K pixels wide. (Basically, we return to all of the limitations which Halo has.) The workaround can be undone by renaming TIFF.RHX back to TIFF.RHL. Again, this rename should be done when MapInfo is not running. Q022: What does "Raster Engine Error" mean? A022: Unfortunately, we don't always tell the user what the exact problem is when the raster engine runs into a problem. A partial list of reasons (the most common ones) is: The file is too large (see the question on size limitations) The file may be corrupt There may not be enough memory to display the image. Q023: Why can't I open an image in 4.x which I opened in 3.x? A023: Some raster images in v3.x will not open in v4.x. The problem is that the Halo handlers no longer allow images wider than 8K pixels to be opened. The old (and incompatible) Halo handlers allowed this occasionally, although their code handled these images dangerously. This problem is rare. Also see Q024. Q024: Why can't I read this JPEG file in Win16? A024: There is a bug in the Halo handler for JPEG which keeps us from properly reading JPEG files larger than 4096 pixels wide or tall. Also see A002. Performance --------------------------------------------------------------- Q031: How do I tweak the performance of the raster engine? Q031: How do I increase the number of colors displayed by MapInfo? A031: There are three parameters kept in the registry which can be used to change how MapInfo handles images. For 16-bit MapInfo add = pairs to MAPINFO.INI in the [MapInfo Common] section: For 32-bit MapInfo running on Win95, WinNT add the named values to the following Registry key: HKEY_LOCAL_MACHINE Software MapInfo MapInfo Common UseTrueColor Allows the user to stop the engine from dithering 24 bit images down to 8 bit. This lets people with true color displays to have better quality color matching. Unfortunately, there are side effects: transparency on these images is disabled, but the UI for the transparency is not. 0 - is default (off), dithers 24 bit color images into an 8 color space 1 - allows Windows to render 24 bit images with as many colors as possible TotalCacheSize This sets how much memory the raster engine will consume in order to speed up display of images. This is the total amount, which is used in chunks the size of ImageCacheSize. Once this amount is used up, images aren't allowed to cache data between displays. 1048576 - is the default 0 - disables using extra memory Any number is valid, but reasonable values range from 0 to about 1/2 of the available memory in the machine. ImageCacheSize This sets how much memory is offered to each image for caching data per image. 307200 - is the default Any number less than TotalCacheSize is valid, but a reasonable value would be: TotalCacheSize / typical number of images in a session of MapInfo Q032: How big an image does MapInfo support? A032: Although the internal raster engine supports up to 2 Gig pixels in X and Y, some of the current format handlers have limits around 8K pixels. See A002 for exact information. Although we handle images this large, it may not be advisable to have huge images. Cutting images down to more managable sizes and tiling them is better than one huge image. See A033 for more about this. Q033: What's the best way to use a huge image in MapInfo? A033: It is _possible_ to have a single raster image and have good performance. After a certain point, though, splitting it into seperate images has better performance. The best performance we can hope for with gigantic images (under Win32 MI4.0) is when you use a compressed and tiled TIFF image. Tiling an image breaks it up into smaller regions which keep pixels in the same neighborhood together. You want it compressed so that the reads from the disk are fast. You want TIFF because it can handle the gigantic images. Q034: Can you give some hints as to which size of data MapInfo will give up on or work will start to get "painful"? Let's also assume the availability of a Pentium PC with 32 MB RAM and a 32 bit Windows system for this task. A034: Under Win32, there are far fewer limits than on Win16. The number of images shouldn't cause "pain". The size of the images causes pain. I don't know where the pain threshold is on image size. Any file larger than 10 Meg or so is generally a pain, I think. If they are leaving the image in one place on their disk (and it's defragged) this limit could be much larger, especially if the image is tiled TIFF. Registration and Correlation ---------------------------------------------- Q041: What are MapInfo's raster capabilities in the area of rubbersheeting and orthorectification? A041: We do not specifically support rubbersheeting or orthorectification. When you register an image, you are creating a coordinate system which all of the other layers will use when they are displayed. This will cause the vector data to be put through an affine transformation in order to match the raster. We will "bias" an image (which means that we stretch the horizontal and vertical axes independently) if another image is present in the mapper and is forcing the coordinate system of the mapper to be its coordinate system. We will display previously ortho-rectified or rubbersheeted images. We do support tiling many images together so that they create a larger coverage. In fact, you could use the new seamless map feature. We do not support editing (warping, etc.) images to seam them together. The basic rule is that MapInfo never edits images. It only displays them. Although we may stretch them on-the-fly in X and Y, we don't do any other kind of transformation. Q042: When registering an image, where in the pixel is the registration point? A042: We register to the upper left corner of the pixel. If you put pixel 0,0 at 0.0 lat 0.0 long then the upper left corner of the pixel will be at 0.0 0.0 and the pixel will go to the east and south. Q043: What happens when you register an image? A043: When you register a raster, you define a number of control points which are then used to determine how to stretch the vector to match it. This is the image's coordinate system. MapInfo will apply an affine transformation to the vectors in order to match it. Affine transformations can scale and rotate data. The amount of scaling and rotation is the same across the entire coordinate system. It is not "rubbersheeting" (which is usually a polynomial transformation). When a user registers points, we try to minimize the total amount of error when calculating the affine transform. So, the user should choose registration points at locations where they want the raster to closely match the vector. Elsewhere, they may diverge. Due to the curvature of the Earth and the likely fact that the image hasn't been orthorectified (or rubbersheeted to match the vector data's projection and datum), they will diverge more the further from the registered points you get. A common misconception is that using more and more registration points will improve the registration. This is true only up to a point. ALL of the points are used to calculate the transform, but since the transform is simple affine, it won't match all of them perfectly. It will just reduce the total error as much as possible. Q044: What happens when you have multiple images in a mapper? A044: If you have multiple raster images in a mapper, the "most predominant" one will control the stretching. For example, if you have three images in a row, panning across them will change the affine xform as each image becomes the one which is most on the screen. This could make the vector look wrong when on top of the other two images. Seamless maps are even more complicated. In addition to the above, when the raster layer (as a table in the seamless map) goes out of "scope" and is removed, then the affine xfrom is also removed. Q045: Does the size of the vector data have effect on accuracy of coordinate measurements from registered image? A045: As with most data, the smaller data (geographically small, that is) you have, the more accurate it is. Because the Earth isn't flat and isn't a perfect sphere, the accuracy of a map at any one point varies. The smaller the area covered, the better the accuracy. (Of course, with photographic images you always have the problems of hills and mountains distorting the geography.) Display, Colors, and Palettes --------------------------------------------- Q051: What happens when you zoom in on a raster image? A051: When you zoom in to a raster image, each pixel in the raster image is expanded. At the image's native zoom level, each image pixel appears as one pixel on screen. At half that zoom level, each image pixel appears as a 2x2 pixel square on screen, and so on. There isn't any missing data being filled in -- MapInfo is enlarging the raster image. (MapInfo, not Windows, calculates how to enlarge it.) MapInfo should enlarge a raster image with repeatable results. If you zoom closely into a raster image and draw a polyline around the edges of an enlarged pixel, then that polyline will always surround that pixel even if you zoom in/out or scroll. Likewise, if you create a point object in the center of the enlarged pixel, it will stay there. Q052: Why doesn't MapInfo display all of the colors in an RGB image? A052: MapInfo always displays 24-bit color images in 8-bit color, using a fixed color palette and dithering to approximate the 24-bit color. We do this to allow transparency, to match MapInfo 3.x, and to guarantee that customers with 256 color displays see a good representation of the image. See the A032 for information on using true-color capabilities. Q053: Why do the colors of the first image change when I add a second one? Q053: How does MapInfo handle displaying all of the colors in my images? A053: MapInfo works within a 256 color palette. 20 of these colors are taken up by the predefined Windows colors. So, MapInfo has to take the many colors in the raster images and squash them down to only 236 colors. It does this by making a list of all of the colors which the images need and iteratively removing colors which are nearly alike. This yields a set of colors (a "palette") which should reasonably represent all of the images simultaneously. (There is some special processing done to make sure grayscale and RGB images are drawn well.) Each window in MapInfo has its own palette. The Layout window has one palette which is shared by all of the ports within it. See A052 and A032 for information about displaying more colors. Q054: What kind of equalization method is used by MapInfo? A054: Usually what is meant by "equalization" is the automatic modifcation of brightness and contrast of an image to bring out details. This is done by programmatically examining all of the image and making a histogram. We don't do any equalization at all. The user can set the brightness and contrast by hand through the raster properties dialog. Engine Limitations -------------------------------------------------------- Q061: Why can't I open more than n (62, 121, etc.) images? A061: Each raster takes up some memory. 120 rasters could take up a lot of memory, just to hold the list of raster images. I know offhand of no limit in Win32 (That doens't mean there isn't one.) I know that Win16 (both 3.x and 4.x) is limited due to memory constraints. I don't know what the limits are. Q062: What's the biggest image MapInfo can handle in pixels? Q062: What's the biggest image MapInfo can handle in bytes? Q062: There is no image size (in bytes) limitation in the raster engine. There are limitations in the number of pixels wide and tall an image can be. See A002 for these limits. --- End of MapInfo Raster FAQ ---