Skip to main content.

FAQ

Non-Technical

What was the origin of OpenEV?

The original version of OpenEV was developed by Atlantis Scientific as a prototype viewer for the Canadian Geospatial Data Infrastructure (CGDI). Its development was supported by the Canada Centre for Remote Sensing GeoConnections program and J-2 Geomatics (Canadian Department of National Defence). The goal was to create a free, downloadable advanced satellite imagery viewer that allowed users to work interactively with CGDI data.

OpenEV runs on a variety of platforms (Windows, Irix, Solaris, and Linux) and contains a number of data and image manipulation functions, which support the interaction with, fusion of, and analysis of information. The power of the viewer comes from its design which exploits the cross-platform OpenGL library and the hardware accelerator cards that have become commonplace in Unix workstations and PC computers.

The open source nature of OpenEV permitted widespread distribution amongst members of the remote sensing community and beyond. The business benefits include the ease with which the base library has been leveraged to create custom, proprietary tools, and the contributions of the open source development community back to the project.

Who are Vexcel Canada and Atlantis Scientific?

OpenEV was originally developed by Atlantis Scientific Inc. in 2000. The company was purchased by Vexcel Corporation, Boulder, CO. in 2001, and was renamed Vexcel Canada Inc. in 2005. In May 2006, Vexcel was acquired by Microsoft and is no longer involved with OpenEV.

Technical

What is the difference between the Vexcel build and FWTools?

Posted by Gillian Walter on the OpenEV Discussion mailing list, November 9, 2005.

Aside from somewhat different packaging, the main differences between the Vexcel builds and Frank's FWTools builds are:

  1. FWTools includes more formats built into GDAL, and also a lot of executables ... (Mapserver, OGDI, etc.). The Vexcel builds only include OpenEV and its components, and use GDAL built with only default formats.
  2. FWTools includes a large number of drop-in tools by default; the Vexcel builds only include a few (OpenEV is used in our products, and we only include tools that are relevant to what we are doing and that we have had time to test). However, additional drop-in tools can be copied from the FWTools/tools directory to the Vexcel OpenEV/tools directory to be installed.
  3. The Vexcel builds are done from a branch of the OpenEV CVS. It is fairly similar to the main trunk, but not identical. This shouldn't result in problems with tools, unless the tool relies on some particular version of an openev python file.
  4. The FWTools releases are much more frequent.

When I use the 3D mode everything still looks flat?

Posted by Gillian Walter on the OpenEV Discussion mailing list, December 16, 2005.

Usually when I've run into problems with 3d draping, it's fallen into one or more of these categories:

  1. The drape and dem have different coordinate systems for their georeferencing (eg. one in lat/longs, one utm). If you can overlay the dem and drape in a single view in openev and verify that they overlap by toggling the visibility on the top layer, this is not the problem. If it is the problem, you need to adjust either the drape or the dem so that its georeferencing matches the others'.
  2. The x and y extents of the image are much greater (or smaller) than the dem's z values. OpenEV only scales in the z dimension, by a default scaling factor of 1. For instance, if your dem and drape are in a lat/long coordinate frame (varying by a degree or so across the width and height of the image) and your dem values are in meters (say 0-100), you can end up with a result that is really stretched in the z direction. Or, if you have a utm-projected image that varies by kilometers in the x and y direction and a dem with relatively little variation (a few meters or less), it could appear flat. To check whether this is the problem, you can load the dem up in 2D and turn on georeferencing for the tracking tool (Edit->Preferences->Tracking Tool->Coordinate: Georeferenced; also make sure that "Pixel Value" is set to "On" under this dialog). Scroll the extent of the image and see the variation in the vertical and horizontal directions, and compare this to the variation in values in the actual dem (the dem values should appear next to the coordinates in the tracking tool at the bottom of the view as you move over the image). You can enhance or reduce the z scaling by changing the "Height Scaling Factor" entry if this is the problem.
  3. The DEM has no-data values that throw things off (eg. ranges from 0-a few hundred over most of the area, but then has -32767 over parts). This tends to give a result with large dips in the surface. You can deal with this by toggling on the "Clamp Minimum Height" button and specifying a value to use as a minimum.

What is OpenEV2 and the status of porting OpenEV to GTK2?

Vexcel released a port of OpenEV from GTK 1.3 to GTK 2.0, the source code for which is availble here. It is very much a development version and is not ready for users. Only the C layer of the OpenEV code has been ported, not the Python layer.

This port of OpenEV to GTK2 has been referred to as OpenEV2 on the mailing list as it represents a significant advancement, particularly with respect to the the OpenEV GUI.