Recent Posts

Pages: [1] 2 3 ... 10
Isis 3 Support / Re: gllnims2isis
« Last post by kbecker on May 25, 2016, 10:36:33 AM »

We are developing methods and techniques to make use of the NIMS data in ISIS. We currently support (some) tubes and g-cubes. The gllnims2isis application can be used to ingest the PDS NIMS archived g-cubes creating a multi-band core cube and a suffix cube that contains the band suffix images you mentioned in your post.

Once you have the NIMS data in ISIS3, you should use nocam2map to reproject the data to whatever projection you need. Note, however, that latitude and longitude coordinates must exist in the upper left and lower right of the respective suffix images to compute the input resolution of the NIMS data. And many of the NIMS observations are flybys which may not have these values defined. In that case, you must specify the resolution in nocam2map.

Processing several of the g-cubes in this manner can then be combined into a mosaic using automos.

Here is an example of the processing for an Io NIMS observation:
Code: [Select]
gllnims2isis from=/PDS_Archive/Galileo/NIMS/go_1120/io/31i005ci.qub to=31i005ci.qub.cub suffix=31i005ci.qub_sfx.cub
nocam2map from=31i005ci.qub.cub latcube=31i005ci.qub_sfx.cub+1 loncube=31i005ci.qub_sfx.cub+2 londir=PositiveWest to=31i005ci_equi.cub pixres=map

Here is the file used for nocam2map:
Code: [Select]
  Group = Mapping
    ProjectionName       = Equirectangular
    CenterLongitude      = 180.0
    TargetName           = Io
    EquatorialRadius     = 1821460.0
    PolarRadius          = 1821460.0
    LatitudeType         = Planetocentric
    LongitudeDirection   = PositiveWest
    LongitudeDomain      = 360
    MinimumLatitude      = -90.0
    MaximumLatitude      = 90.0
    MinimumLongitude     = 0.0
    MaximumLongitude     = 360.00
    PixelResolution      = 1000.0  <meters/pixel>
    CenterLatitude       = 0.0

We have plans to start a NIMS wiki sometime soon on our ISIS Issue Tracking System website where progress, discussion and issues can be found.

You also should start a ticket there since this site is going readonly soon and will be replaced with the Issue Tracker site.

Policies and Announcements / Closing of this forum site
« Last post by isis3mgr on May 20, 2016, 05:09:03 PM »
The ISIS, Planetary GIS, and other Discussions boards have moved. Please use the new issue tracking system to post bug reports, features requests, and questions.

Issue tracker:
Sign up for a new account at:

Thank You
Isis 3 Support / gllnims2isis
« Last post by m_valenti on May 11, 2016, 01:45:23 PM »
I trying to import NIMS images using gllnims2isis. The main issue I'm trying to figure out, is how to add the camera pointing information to the image. The suffix data contains the back planes, and I'm looking for a command that can add these back into the image.  So, far the closest I've found is phocube, but it appears to only be for extracting backplanes.

These are what I think each band contains in the NIMS suffix image, based on what I see with the Isis2 NIMS images:

band1: lat
band2: lon
band3: incidence angle
band4: emission angle
band5: phase angle
band6: slant distance
band7: intercept altitude
band8: phase angle std dev
band9: spectral radiance std dev
Isis 3 Support / Re: Trouble Using Kaguya TC Mosaic Tiles
« Last post by ANahm on May 10, 2016, 01:27:35 AM »
Hi Trent-

Thank you for your quick and detailed reply!

I am using 10.3.1. I zoomed in to the raster resolution and it was just white. So I conclude that the download was bad. I'm downloading it again just to make sure, but that will take about a week to see the results.

I have connected the WMS lunar server to my map project. I didn't know it existed! It is working perfectly. I still intend to try to get the downloaded version to work, so that I can have a little more control over how it's displayed (like the stretch etc).

Thank you again and I will update when and if I can get the jp2 to work.
Isis 3 Support / Re: Trouble Using Kaguya TC Mosaic Tiles
« Last post by thare on May 09, 2016, 05:56:42 PM »
First what version of ArcMap are you using? I am testing this file in 10.3.1 and it is working fine (but slow). I am suspicious that the download is bad...?  ArcMap should not show 0 to 0 but default to 0 to 255 (8bit). How to test. Right click on layer name in the table of contents and "zoom to raster resolution". Once zoomed-in, the map will draw very fast. If still all black then something is wrong with the file or ArcMap is having issues.

Other ways to check the image.

1.) kdu_show can open this image also. You can get this small viewer free from Kakadu.  Note that kdu_show isn't on all platforms but it is on Windows (which I assume you have since you are using ArcMap).

2.) check image with kdu_jp2info
Code: [Select]
> kdu_jp2info.exe -i Lunar_Kaguya_TC_Ortho_Global_4096ppd_v02.jp2

  <ftyp name="file-type box" header="8" body="12" pos="12">
    <brand> "jp2_" 0x6A703220 </brand>
    <minor_version> 0 </minor_version>
    <compatible_brand> "jp2_" 0x6A703220 </compatible_brand>
  <jp2h name="JP2-header box" header="8" body="37" pos="32">
    <ihdr name="image-header box" header="8" body="14" pos="40"></ihdr>
    <colr name="colour box" header="8" body="7" pos="62"></colr>
  <asoc name="association box" header="8" body="4,346" pos="77">
    <lbl_ name="label box" header="8" body="9" pos="85"></lbl_>
    <asoc name="association box" header="8" body="1,818" pos="102">
      <lbl_ name="label box" header="8" body="18" pos="110"></lbl_>
      <xml_ name="xml box" header="8" body="1,784" pos="136"></xml_>
    <asoc name="association box" header="8" body="2,495" pos="1,928">
      <lbl_ name="label box" header="8" body="18" pos="1,936"></lbl_>
      <xml_ name="xml box" header="8" body="2,461" pos="1,962"></xml_>
  <uuid name="UUID box" header="8" body="486" pos="4,431"></uuid>
  <jp2c name="contiguous-codestream box" header="8" body="rubber" pos="4,925">
      <width> 1474593 </width>
      <height> 737297 </height>
      <components> 1 </components>
      <tiles> 296 </tiles>

3.) Crop out a section to test file. This command says decompress a limited region of the original image (starts 50% down and 50% in from left, extends for 2% of the original height and 1% of the original width). Now I'm not sure the geoTiff header updated correctly. For this would need to use gdal_translate (with Jp2 support - not always easy to find).
Code: [Select]
> kdu_expand -i Lunar_Kaguya_TC_Ortho_Global_4096ppd_v02.jp2 -o region_test.tif -region {0.5,0.5},{0.02,0.01}

Using this image:

Once you can figure out if the file is good, there are methods to make this file more usable. So Jpeg2000 is suppose to have built-in "pyramids" but for files this large I think it is still hard for any application to use. So what to do. 

1.) Build pyramids for Jp2 file (leave for the night since it will probably take all night). You can do this in ArcCatalog or ArcMap toolbox or using "gdaladdo".

2.) Convert to BigTiff using free kdu_expand routine and then build pyramids. This will be 500GB in size and pyramids will be huge too. Note gdal_translate can clip out small regions too.
$ kdu_expand -i Lunar_Kaguya_TC_Ortho_Global_4096ppd_v02.jp2 -o outFullImage_geo.tif

If you can't get those to work, there are the smaller tiles available:

And remember this full-res layer is available as a live WMS layer. It is best to add in a lunar image or shapefile to initialize ArcMap as on the Moon and the map projection you want to use. Now in ArcMap, use "add data from ArcGIS Online", type in "WMS Lunar" into the search window, and click "add" under "WMS Lunar Server, Astrogeology". Note all layers will be turned on. Just leave "Kaguya TC Ortho Mosaic" layer on. It is fairly fast, even online, since it has pyramids built on the server.

let us know,
Isis 3 Support / Re: Trouble Using Kaguya TC Mosaic Tiles
« Last post by ANahm on May 09, 2016, 04:35:43 AM »
It took me several days to download the 4096 ppd jp2, but I got it. However, when I open it in ArcGIS, it is one big black box. The range in values is 0 to 0, so stretching doesn't seem to help. Do you have any suggestions besides waiting another week for the download again?

Isis 3 Support / Re: Misalignment with the blend command (OPEN TB)
« Last post by tbecker on May 02, 2016, 02:19:37 PM »
That's good news the automos average option helped!  Keep in mind your output mosaic now has a 2nd band, it is the count of images for every mosaic pixel.  It's fun to check out on how many images contributed to the the long run though, to remove the 2nd band, I use cubeatt   from=avgmosaic.cub+1  to=avgmosaic-1band.cub

Back to 'blend',  I have been told that it will definitely be affected by mis-registered input files.   The stats would be computed and applied in the overlapping areas that not well aligned.
Isis 3 Support / Re: Misalignment with the blend command (OPEN TB)
« Last post by m_valenti on May 02, 2016, 01:16:18 PM »
I wasn't aware of the  priority=average option in automos.  I went ahead and tried it, and the results came out better than the blend-mosaic.  I compared it with blend-mosaic, and the misalignment is the same.  It looks like I've gotten alignment to be reasonably accurate.  All of the images have been photometrically corrected, and the current mosaic is looking more even without equalizer.  I think I've gotten it as good as I need it to be for now.
Isis 3 Support / Re: Misalignment with the blend command (OPEN TB)
« Last post by tbecker on April 28, 2016, 06:12:42 PM »
I see what you mean.  For equalizer, you need to try to include a normalized basemap or registered low-res, low-phase image that covers the entire region of your mosaic and use 'hold' to influence the brightness adjustments.   Also, have your images been photometrically normalized?  This might help also...

I have  theory about 'blend'.  I suspect you have misalignment among your images to begin with.  Your mosaic without blend does not reveal this, most likely because the misalignment is about one pixel or less.  One way to confirm this is to create an average mosaic of your original images without blend (automos priority=average).  Blink the average-mosaic with your original mosaic and I suspect you will see the same movement along the image boundaries (as we can see in your gif movie).  Then, blink the blend-mosaic with the average-mosaic and I suspect you will see minimal movement.  Let me know because this is what I observe with my own set of images.

I have confirmed with others that blend does not shift images.  But, when I apply blend to a collection of images and compare the .blend.cub output directly with it's input version, I observe slight movement where the image overlaps another image.  My theory is how the statistics are computed and applied to each overlap region of each image, that parallax or mis-registration is slightly propagated to the output.  This might NOT be a correct explanation and I need to demonstrate what I see to our developer to confirm this might be what is going on.  I will let you know!

Isis 3 Support / Re: Misalignment with the blend command (OPEN TB)
« Last post by m_valenti on April 28, 2016, 05:26:41 PM »
I tried equalizer with noseam, and with this example the top ends up brighter than the bottom.  I'm looking more for even brightness and blend has done this the best so far.  Here's an example of what equalizer/noseam  produces:
Pages: [1] 2 3 ... 10