FAQ

•Where can I get the code?

Run 'git clone https://github.com/mdaus/nitro.git' from the command line

• **What languages does NITRO support? **

The core of NITRO, along with the TRE and compression plug-ins, is written in C. We currently have bindings for Java and Python. The Java bindings are considered to be fairly stable while the Python bindings are more experimental. We plan on solidifying these APIs for the 2.0 release. Please tell us if you have any feature requests∞ or if you find any bugs∞. Check out the APIs for more information.

• **Does NITRO support compression? **

NITRO supports both JPEG and JPEG 2000 decompression when reading imagery. Compression, when writing, is not yet supported. This means that "round-tripping" a compressed NITF file will always result in a larger (uncompressed) output file. NITRO uses a plug-in interface for decompression, and comes shipped with both libjpeg (JPEG) and libjasper (JPEG 2000) plug-ins. If building yourself, these plug-ins are in the top-level external/ directory. Build using Waf or configure/make. The Windows installer comes with both plug-ins. Refer to the JPEG Decompression Plugin documentation.

• **What is NITF_PLUGIN_PATH all about? **

Set the NITF_PLUGIN_PATH environment variable to point to the directory containing your plug-ins (TRE and image decompression). Otherwise, the library won't be able to parse TREs or decompress imagery. You can alternatively use the PluginRegistry to load plug-ins at runtime. See the Snippets page for an example.

Update: You can now register static handlers if you don't want to use plug-ins.

• **How do I build NITRO with Waf? **

See Building With Waf for detailed information.

• **How do I build NITRO on Linux/UNIX? **

See Building on Linux/UNIX for detailed information. Make sure to first read the page on Building With Waf to learn more about the Waf build process.

• **How do I build NITRO on Windows? **

See Building on Windows for detailed information. Make sure to first read the page on Building With Waf to learn more about the Waf build process.

• **How do I build my code against NITRO within Visual Studio? **

See Building with Visual Studio for detailed information.

• **How do I build NITRO on Darwin? **

Make sure to first read the page on Building With Waf to learn more about the Waf build process. If you are on a powerpc, your build should work properly -- just configure and make. The 1.5 code doesnt yet support universal binaries, though the 2.0 branch will. The DSOs will still be suffixed 'so' instead of 'dylib.' That is because the library checks for that extension currently. However, it should still work just fine.

The intel macs will need an additional configure case statement inside of build/conf/configure.apple.in. which they do not currently have. We expect this to be resolved for 2.0. To build on the intel macs, copy the linux version and modify the name accordingly and the code will probably build.

• **I can't get NITRO C to build on platform X? What should I do? **

The C library works on most systems, so there is a good chance if you can give the makefile the right flags, you will be able to build it. Try and run the config.guess by itself and see what it produces. If it doesnt work, that means that it probably needs to be updated to include your system. If it does, check the configure.in and see how your target system is handled (if at all). If need be, you can add the case, and re-autoconf the configure and it should build.

• **How do I build the Java library? **

See Building the Java library for detailed information.

• **How do I build the Python bindings? **

See Building the Python bindings for detailed information.

• **How do I use the Java library? **

First, you have to build it. See the sections on building for more information. Once both the JNI library and the Java library are built, you are ready to go. You can use the Java library much like any other open source Java library. If you are using an IDE, such as Eclipse or IntelliJ Idea, you can just include the NITRO jar in your build path. When running an application that requires NITRO, make sure to add the following to your VM arguments: -Djava.library.path=$PATH_TO_JNI_DLL_DIR Where $PATH_TO_JNI_DLL_DIR is the directory where nitf.jni-c.dll (or libnitf.jni-c.so on Linux) is located.

Note: Depending on how you retrieve image data, you may need to increase the Java heap size. We recommend that you retrieve data in small window chunks to keep the memory footprint low.

• **Where is the API? Can I generate it myself for offline use? **

There are a few ways to get both the C and Java APIs.

• Online: NITRO API page cd c/nitf, then doxygen *Java API Maven: cd java/nitf, then maven javadoc Ant: cd java/nitf, then ant javadoc Installers: The Windows installer is now bundled w/the C and Java API documentation. (The linux java binaries also come bundled with the respective docs).

• **What fields are automatically composed during writes? **

Some fields in the library are figured out by the writer as it is writing. These values will be re-written or ignored, meaning also that you cannot affect them by setting (whether correctly or incorrectly):

• COMRAT (compression rate), will set automatically if IC (image compression) - NC or NM • user-defined/extended header lengths/overflow (UDIDL, UDOFL, etc.) • FL/HL (file length, header length)- These are set to zero in writeHeader, and subsequently re-written after the rest of the file has been written. • All NUM (NUMI, etc.) • All component infos (LISH, LI, etc. -- this includes length) • 2.5 CLEVEL (automatically measured only if the value is set to '00' -- the default)

Most of the fields default when the Record is created, and the user can set them to other values later.

• I looked at the plugins, and there is not a handler for XXXXXX tre. What should I do?

Even though the library ships with a large number of plugins, you may find that you need to support a TRE that we do not already handle. If the specification is available to us, you can put a feature request in our issue tracker, and we will try to get around to it as soon as possible.

If you want to implement the TRE support, you just need to write a very short file that describes the TRE. If you have a look in the C library's shared/ directory, you can see how to add one, or you can check out our snippets to get an idea of how to do one. There are examples for simple and complex plugin creation.

• **The implementation of a plugin does not match the description in the spec. What should I do? **

Our support plugins can handle multiple definitions for the same TRE. We do that to be able to be backwards compatible with older specs. Usually, if there are multiple specs for the same TRE, we make an effort to support all of them. Sometimes that is not feasible due to time limitations, etc. In other cases, we may have overlooked something, or there may be a bug.

If you find a defect in a specification, please post a reference to the specification that you are using, along with the locations of the handler that should be patched. If you have a dubious spec. or if you know that some data that you are viewing is formatted incorrectly, but the plugin is handling the information correctly (and thus causing a problem), you can write your own version of the plugin and install it to the plugin path over the default one.