ECW and JPEG 2000 are two different formats that are handled by the same File - Export - Image choice in Manifold. Which format is written depends upon the three letter extension used for the file name. Manifold can export either ECW or JPEG 2000 images without limitations on size other than, of course, the capacity of the machine in use and the patience of the user.
ECW or JPEG 2000 format is strongly recommended for very large images. Manifold can link an image from an ECW or JPEG 2000 file with great speed. Images linked from these formats that are many gigabytes in size will load and display in just a few seconds.
ECW and JPEG 2000 are two different formats even though they are handled by the same exporter within Manifold. ECW is strongly preferred because it can store projection information (see notes below).
To export an image as an ECW file:
1. Open the image to be exported in an image window.
2. Choose File - Export - Image
3. Choose ECW / JPEG2000 in the Save as type box.
4. Enter a file name for the file ending in .ecw and press Save.
5. In the Export ECW / JPEG2000 File dialog enter a Compression ratio and press OK.
To export an image as a JPEG 2000 file:
1. Open the image to be exported in an image window.
2. Choose File - Export - Image
3. Choose ECW / JPEG2000 in the Save as type box.
4. Enter a file name for the file ending in .j2k, .j2c, .jp2, .jpc, .jpf, or .jpx and press Save.
5. In the Export ECW / JPEG2000 File dialog enter a Compression ratio and press OK.
Important: We must explicitly specify the three letter extension, either .ecw or one of the allowed three letter .j-- extensions, to tell the exporter whether we want an ECW file or a JPEG 2000 file. Do not forget to specify this extension (it is not something Windows users are accustomed to have to do) as forgetting to specify the extension will result, unpredictably, in the exporter choosing on its own which format to use.
Compression Ratio
Set the compression ratio desired, such as 1:10 or 1:20 or even greater in the export dialog and the ECW / JPEG 2000 routines will do their best to compress the image to the degree specified. ECW export supports all projections available within ECW files.
Note that wavelet compression can provide remarkable compression without apparent degradation of the image; however, both ECW and JPEG2000 are "lossy" formats and are not appropriate for certain types of remote sensing data where not even a single pixel can be change. These formats are best for visual data where appearance to the human eye is the main criterion.
Projections
ECW format can save projection information although the list of projections supported by ECW does not include all projections supported by Manifold. (Manifold has grown to support so many projections that virtually no other software supports such a long list of projections).
Although JPEG 2000 in theory can save projection information, in actual practice for the reasons given below it should not be treated as a projection-aware format. When Manifold writes a JPEG 2000 file it will also create an accompanying .xml file giving full projection information. In the special case of JPEG 2000 files written by Manifold that still are accompanied by the .xml accessory file, Manifold will be able to write and read projection information perfectly with JPEG 2000 files.
However, that capability of storing projection information will not extend to JPEG 2000 files written by other applications which we try to import into Manifold, nor is it likely that other applications will be able to read projection information from JPEG 2000 files written by Manifold. See the discussion below for reasons why.
Good News and Bad News for Open Standards
The ECW and JPEG 2000 code within Manifold System provides a living example of both the benefits and the curse of cooperation between companies using open source and open standards. First, the good news:
The export code to export to both ECW and to JPEG 2000 used within Manifold is open source code provided by ERM (Earth Resource Mapping, the makers of ERMapper) to the GIS community. ERM invented ECW and developed it into an effective format for storing compressed images. ECW is not only elegant from an academic, computer science perspective, it is also supremely practical in that it incorporates "real world" requirements such as the need to store projection information in a perfect, unambiguous form. Years of focused improvement under the guidance of expert remote sensing applications programmers have also given ECW extraordinary performance.
To help establish ECW as a universal format, ERM had the great presence of mind to provide source code to ECW to other GIS and remote sensing companies. In addition, ERM implemented the new JPEG 2000 "open" standard for compression within the same software development kit (SDK) for which source code was openly provided. Having both formats supported by the same SDK with freely available source code removed any tension vendors might have as to which standard to support. It also showed that ERM had the confidence in ECW to allow the industry at large to make a choice even if the use of JPEG 2000 became free and effortless.
The ECW / JPEG 2000 SDK is now used throughout the GIS and remote sensing communities and is cooperatively maintained for use in UNIX, Linux and Windows by industry professionals with ERM managing the standard and taking the lead in UNIX and Manifold and others assisting with Windows notes. The objective is to have a single code base for all platforms to assure that the resulting ECW or JPEG 2000 files are fully interoperable.
Overall, the effort has been very successful, a shining example of how mutual support using access to source code can propel a commercial standard like ECW into universal acceptance by commercial vendors. About the only compromise required is that a side effect of using such shared code within Manifold for this exporter is the requirement to explicitly specify the three letter extension, either .ecw or one of the allowed three letter .j-- extensions, to indicate whether an ECW or a JPEG 2000 is required. This small matter aside, the release of source code for the ECW / JPEG2000 SDK by ERM has resulted in superb performance and quality for ECW.
And now, the bad news of "open" standards:
Given ERMapper's extensive experience in image compression, ERM had the experience to develop practical, effective and high quality JPEG 2000 code and has produced what is indisputably a best-of-breed JPEG 2000 implementation. The problem is that the JPEG 2000 standard itself has been weakened by too many "design by committee" compromises instead of a solid focus on practical software implementation and use. Those compromises may have been well-intentioned but they have resulted in a format that does not work as well for GIS use as ECW.
In particular, the JPEG 2000 standard attempts to incorporate too many different approaches in the matter of projections information storage and so succeeds in being darn near useless in this key area. It allows several different methods to store projection information in a JPEG 2000 file.
With different ways of storing projection information JPEG 2000 opens itself up to a Tower of Babel phenomenon where no two packages are likely to use the same method in exactly the same way. Even in the case of packages that attempt to support multiple methods or the same method the intrinsic ambiguity of the methods usually chosen for JPEG 2000 make it unlikely that projection information interchange will be accomplished in all cases. We can see why by looking at the best of the methods allowed in JPEG 2000, EPSG codes.
The most useful of projection storage methods within JPEG 2000 is the use of EPSG codes. These are also used by OGC (the inventors of famously incompetent "standards" like GML) for things like OGC WMS / WFS and are used by Manifold for the Manifold IMS implementation of OGC WMS / WFS as well.
For all the merits of EPSG, the available EPSG codes do not cover a sufficient number of projections. A further problem is that EPSG codes are not defined in a single, unique set and so different applications can end up using code sets that are not identical. As a result, even the use of EPSG codes imposes great limitations on what can be inside a JPEG 2000 and how that information can be interchanged. As the industry moves to greater standardization and a single set of EPSG codes this situation should be improved.
The JPEG 2000 inability to make decisions in a unifying way can be seen from the very nature of JPEG 2000 filenames. A standard which cannot make up its mind which three letter extension to use and instead compromises by allowing six different names for essentially the same thing (.j2k, .j2c, .jp2, .jpc, .jpf, or .jpx) obviously from the very beginning has a serious problem with squishy thinking. If the standard cannot even standardize its own name there is little hope it will do better on more contentious issues, such as methods for encoding projections.
Note that in no way do we suggest that JPEG 2000 is not well intentioned. It's actually a great project done for all the right reasons with the best of intentions. But as anyone who has ever participated in one of the committees that earnestly come up with such things can attest, it is good intentions that pave the road to you-know-where. It could well be that the press of evolution and the indisputable talent of the many people who work on JPEG 2000 will take a hand in guiding JPEG 2000 into more useful form. Perhaps there will emerge a JPEG 2007 or JPEG 2010 that one day will equal ECW in effectiveness. Until then, GIS professionals with a job to do will reach first for ECW.
Because source code for ECW is now freely available within the GIS and remote sensing vendor community, users and vendors can trust that ECW will continue to serve as the de facto standard for "real world" GIS and remote sensing applications. For the reasons set forth above, manifold.net strongly encourages Manifold users to employ ECW in preference to JPEG 2000.
Tech Tip
JPEG 2000 may be squishy about filenames but that doesn't mean you have to be. If for some reason you choose to save files into JPEG 2000 format, consider always using the .j2k three letter extension. There's no particular reason for this advice except that .j2k looks like a more memorable mnemonic for JPEG 2000 than, say, ".jpc" or the others. Although the original suggestion for JPEG 2000 was to use .jp2 as an extension, it appears that .j2k is now slightly more popular than the other choices. Within the Manifold community, we may as well voluntarily "standardize" on .j2k.
See Also