SourceForge has been redesigned. Learn more.
Close

Hypercube

Help
2014-02-19
2014-02-23
  • Y. A. Coder

    Y. A. Coder - 2014-02-19

    I am trying to build hypercubes from hyper-spectral images obtained from a Headwall VNIR imager (1004 pixels with 327 bands each). I have tried building these using both the nevi.create_image() and the nevi.save_image() functions with the same result. Two of the faces are just wrong and I can't work out where the problem might be. I have attached two images, one showing the faces that are "good" and the other showing the faces that are not "good". I would appreciate any help. The data looks good using just the view() function and the spectra appear to be fine.

     
    Last edit: Y. A. Coder 2014-02-19
  • Thomas Boggs

    Thomas Boggs - 2014-02-19

    What are the dimensions of your image (# rows/cols)? Can you perhaps post the header file for your image?

    And does the top of your cube look correct (i.e., the same as when you call the view function)?

     
  • Y. A. Coder

    Y. A. Coder - 2014-02-19

    Thanks for the response. The header file is attached. Yes, the top looks correct with the view function.

    The image parameters in python:

    In [5]: img
    Out[5]:
    Data Source: '././hc.img'
    # Rows: 347
    # Samples: 1004
    # Bands: 327
    Interleave: BIP
    Quantization: 16 bits
    Data format: uint16

    In [6]: img.shape
    Out[6]: (347, 1004, 327)

    Also attached, the output from view(img)

     
    Last edit: Y. A. Coder 2014-02-19
    • Thomas Boggs

      Thomas Boggs - 2014-02-19

      The top of the cube looks odd to me. The right half looks like it's from an image and the left half looks like a constant value (in the second image you posted). That is how it is supposed to look? If so, have you tried calling the view function with bands farther down in the cube to see if they look correct? For example, if your image data is in array mycube:

      view(mycube[:,:,100])
      

      or

      view(mycube[:,:,200])
      

      Also, it isn't clear to me if the cube you are showing is from the data before saving or after being read from the file. If it is the latter, I recommend viewing the image data array from before saving as well to see if there is a difference.

      If that is really how your image is supposed to look for particular bands, perhaps there is a large difference in pixel magnitude between the two sides of the image that causes the color scale along the sides of the cube to look odd. What happens if you try to view a subset of the image that doesn't include both regions? For example,

      view_cube(mycube[0:100, 800:900, :])
      
       
      Last edit: Thomas Boggs 2014-02-19
  • Y. A. Coder

    Y. A. Coder - 2014-02-20

    I viewed the cube before writing it to file and it displays the same as what I get after reading it back from the file. Also looked at several bands using view() and they all look good (especially at the edges, say bands 0,1,325,326).

    The headwall is mounted on a robot looking down at the floor. A spectralon target is mounted on the robot and close to the floor so that it covers the left 1/3-1/2 of the image. The image data is collected as the robot moves in a straight line, looking at the floor and the target.

    The second screenshot in my original post looks right. The target shows up as the bright strip and the floor shows up as a darker strip with some minor variations. However, the two faces in the first screenshot don't make sense. In that photo, the front facing image (with a lot of yellow) seems to be mirrored. I can't really make sense of the image on the side face. Could there be an issue in rendering these two faces?

     
  • Thomas Boggs

    Thomas Boggs - 2014-02-20

    You found a bug! It appears that the front (nearest) and left sides of the cube were being flipped left-right. I think this bug was introduced in a recent version of the code. I also noticed there was a scaling issue that distorts the cube wen the row/column aspect ratio becomes large (or small).

    I fixed the bugs and will release an update to the module soon. In the mean time, you can get an updated version of the module with the fixes included from the git repository. If you don't have/use git, you can just go the the URL and click the link that says "Download Snapshot", which will give you a zip file with the current version of the code.

    Thanks for bringing this to my attention.

     
  • Y. A. Coder

    Y. A. Coder - 2014-02-21

    Thanks a lot. I pulled out the code from the git repo. Unfortunately, I think there may still be a problem with one of the faces. See attached views. The view called notgood has a discontinuity between faces and that is why I suspect there may still be a problem with this particular face. However, as you mentioned above, could this simply be due to different scaling of the data for this face? I have also attached views of the partial cube that excludes the comparatively bright target, obtained using the command view_cube(img[:,500:1003,:], bands=[100,200,300]). Finally, the cubes labelled small1 and small2 were obtained with the command view_cube(img[:,900:1003,:], bands=[100,200,300]).

     
    Last edit: Y. A. Coder 2014-02-21
    • Thomas Boggs

      Thomas Boggs - 2014-02-21

      I see the issue and I belive it is due to the color scale being auto-scaled individually for each face. This isn't issue for typical cubes but it is safer to just disable auto-scaling, which I just did. Try taking another snapshot of the code and see if this fixes the issue.

       
  • Y. A. Coder

    Y. A. Coder - 2014-02-21

    Great. Thanks a lot for your timely help. It looks good now. I owe you one! Is there a reference for the library that I can cite?

    I noticed that your changelog comments are still 2013.

     
    • Thomas Boggs

      Thomas Boggs - 2014-02-21

      Ha ha. That's what I get for using copy/paste in the change log.

      You can just cite the web site URL. Normally, you would include the software version number but since the version you used is modified, I would just note the git revision number for the source code (9c974a). The changes I just made will be included in a new software version (0.14) in the next couple days. I will send you a note when that is released, in case you want to reference it by version number.

       
    • Thomas Boggs

      Thomas Boggs - 2014-02-23

      Version 0.14 was released today (on PyPI and sourceforge). So if you would like an "official" version to cite, that is the one that includes the fixes.

       

Log in to post a comment.