Requirements gathering for operating VNIR & SWIR at higher speeds / lower spatial resolution

[dlebauer]

It will be useful to run the hyperspectral cameras at the same speed as other imaging sensors. This is not to replace the full field high resolution scans (which take >2 days) but to evaluate the feasibility of also running these cameras at lower resolution so that they can keep up with the other sensors.

This issue is to open a discussion that should address the following:

• What is currently preventing us from running the VNIR/SWIR at higher speeds lower spatial resolution?
  • triggering mechanism currently runs at max 0.1m/s. can we adjust it to go faster, is it necessary for the lower resoultion scans?
• What analyses do we need to do to compare the high res vs low res images?
  • @smarshall-bmr has already done some test scans at varying sppeds
  • can we also simulate lower resolution from full resolution?

TODO

• identify location of test scans
• make sure they are processed
• hold a discussion
  • define steps
  • include @remotesensinglab, @rmgarnett @smarshall-bmr and anyone else interested

Completion criteria

• [ ] @solmazhajmohammadi needs to run extractor on same dataset as @czender to compare output.
• [ ] document that describes
  • [ ] summary of the problem and proposed solution
  • [ ] all steps required to allow low res hyperspectral scanning alongside other sensors next sorghum season
  • [ ] analyses
• [ ] new issues in github.com/terraref/computing-pipeline that define each of the steps above

[smarshall-bmr]

The primary issue of accelerating the hyperspecs is that they have a fixed refresh rate that the triggering system runs up against at high speed. I'll inquire with Bob about how this works but I know that currently the SWIR is set up to fire once every trigger pulse, while the VNIR fires fires twice every trigger pulse. If the system is rolling too quickly the trigger pulses simply overwhelm the cameras and data comes out garbled as images are triggered before the previous one has completed. Theoretically we can modify the frame length and impose shorter exposure times to cycle the camera faster but images will come out noticeably darker.

Under the current settings I'm not convinced that running the gantry faster actually reduces resolution greatly (the same number of frames are still being taken on each stripe because the camera travels the same distance.) I'll ask some LemnaTec folks about this.

[smarshall-bmr]

I spoke to @solmazhajmohammadi about this. She showed me that running the scan faster does indeed start dropping frames. The cubes taken at 4cm/s are half the size of those taken at 2cm/s. Perhaps it works out that if a trigger signal is received while a frame is being taken that trigger is simply ignored? This still doesn't explain why data comes out garbled at speeds above about 12cm/s, it might be a limitation of the camera's ability to interpret the triggering signal? Maybe @rjstrand could comment once he's done being swamped with handover.

[remotesensinglab]

Can some provide the following information?

• Lens/aperture size
• Max Frame Rate
• Shortest integration time possible?
• Possible to trigger many frames per second instead of using cm/second?

We evaluated the data scanned with 20 - 55 ms integration. Basically, the 20 or 25 ms turns out to be good based on the data I was provided. I did know other setting used for the data collection, but based on that I think a shorter integration time, a faster speed may be possible.

Do we have data scanned at various speeds?

[dlebauer]

@remotesensinglab we should have this in our documentation / sensor metadata. @craig-willis can you help him find it, or put it there when we get this information? And @remotesensinglab it would be great if you could review our documentation and sensor metadata to make sure we have what we need. There will be a review in January but this is the type of information that we should have available.

[smarshall-bmr]

@remotesensinglab Just for brevity the lens is a 1.4/22.5, max frame rate is 100hz. I'm unsure on other limits. It's worth noting that Headwall's product page specifically states that the instrument is designed for f/2 so I'm guessing the internal optics may be limiting light gathering.

Lens data page: http://www.schneiderkreuznach.com/fileadmin/user_upload/bu_industrial_solutions/industrieoptik/11mm_Lenses/3MP_Compact_Lenses/Xenoplan_1.4-23.pdf

Camera data page (our camera is the E series): http://cdn2.hubspot.net/hubfs/145999/docs/VNIR.pdf?t=1484157838353

[dlebauer]

@remotesensinglab and @smarshall-bmr could you please update this issue with a summary of yesterday's conversation, and create new issues for the next steps? See https://github.com/terraref/computing-pipeline/wiki/Issue-Review-Examples

[craig-willis]

Sorry for the delay, I missed my mention in the earlier comment. The documentation we have for VNIR and SWIR are in the Sensor and Device Information collection in Clowder.

Until the main instance is stable, here are links to the development instance: SWIR: https://terraref.ncsa.illinois.edu/clowder-dev/datasets/57ea886ae4b00b25cabf8e69 VNIR: https://terraref.ncsa.illinois.edu/clowder-dev/datasets/57ea88dee4b00b25cabf8e9b

These include the LemnaTec specs, Headwall datasheets and calibration certificates. I'll open a separate ticket for adding these properties to the sensor metadata for programmatic access.

[remotesensinglab]

Maximum speed depends on frame rate (frames per second) * IFOV (mm).

Currently installed Lens:

• NIR and SWIR lens are: 23 mm and 25 mm.

Options to increase scan speed:

Option 1: The maximum frame rate without binning is (VNIR: 100 Hz; SWIR: 450Hz). Increasing the frame would help increasing the scanning speed. When we use max frame rate a spatial binning could help increase the hard drive writing speed.

Option 2: shorter exposure time, lower SNR. Images can be darker, but using lower reflectance targets (50 %, 30%); smaller f/stop, larger aperture can remediate. At a 25ms exposure time the speed would be double than what we would have with a 50ms exposure time.

Option 3: Changing the spatial binning – post grab tab may improve the speed but spatial resolution gets coarser. Spatial binning will decrease the spatial resolution drastically. It currently adds and averages two line of scan data in one direction. Can we use instead of percent binning, e.g., binning 25% of the data.

Option 4: The speed is directly related to the change in focal length so going from the 23 mm to a 17 mm would be 1.35x faster. The system mounted in the Inspector cabinet, the scanning mirror and window are not large enough for the angular FOV of the much shorter, e.g. 4.8 mm lens. The 17 mm lens is the shortest focal length we can use in the Inspector without vignetting some light.

Option 5. To increase the size of the entrance slit. This would reduce the spectral resolution but it would let more light into the sensor and reduce the exposure time required.

Option 6: Selective scanning. Define sample areas representative genotypes or plots, then develop algorithms to simulate or predict the rest.

Potential issues and other issues:

• Hard drive writing speed limits the speed as well. Frames can not be stored if the hard drive does not support high speed recording. VNIR may be limited because it is large, but SWIR file is smaller should be ok.
• Spatial binning can help when a max frame rate is used.

Action items:

• Create a table/matrix for various imaging options with shortest possible integration time (20 or 25 ms), various frame rate and spatial binning options. (@solmazhajmohammadi)
• Review the imaging options, collect and analyze the data. ( @remotesensinglab, @solmazhajmohammadi and anyone interested?)

[smarshall-bmr]

Just to clarify, current scans are done with a 45ms exposure time on the VNIR and 30ms on the SWIR. I don't know if this has been accurately quoted recently.

[remotesensinglab]

Hi Solmaz, Would it be possible to create a table/matrix for various imaging options with shortest possible integration time (20 or 25 ms), various frame rate and spatial binning options? I wonder if it is something can be configured through the software used to control scanning speed? Then, we could evaluate the data and find out the best options to optimize the scanning speed.

Thanks

Wasit

[solmazhajmohammadi]

@remotesensinglab Hi Wasit, We have been in contact with headwall to figure out if bining really would increase the light sensibility or it is just a image size reduction. I would follow up with them again and post their response here. Up to this point our option would be changing the triggering signal. We can change the external trigger signal via a signal divider manually. However, even in this case frame period is still gonna be our limit. Please note that frame period should be at least 5ms more than exposure time and we can adjust the triggering signal to fit the frame period. If this option is OK, we can try it in free run mode for now, Tino will be in Maricopa next week and he can change the triggering signal. (Free-run would affect georefrencing) During my call with headwall's costumer support, they have suggested to change the slit width instead of changing the lens.

[remotesensinglab]

Thank you for the update @solmazhajmohammadi. Changing the slit width is the option 5. Option 5. To increase the size of the entrance slit. This would reduce the spectral resolution but it would let more light into the sensor and reduce the exposure time required.

let's see what they recommend then. thanks

[solmazhajmohammadi]

@remotesensinglab Update: Binig is not an option, the bining is done after data collection, so it is not going to increase the amount of the light coming to the sensor. it will reduce the size and can help increase the speed only if the limiting factor is the write speed of the hard drive. I suggest changing the triggering signal for now, and using 20ms exposure time(instead of running the gantry twice speed and randomly downsampling the data). There is no improvement compared to the speed that we are running now, It is just going to give us reliable data

[craig-willis]

@dlebauer This is a stale issue with comments in last 2 months. Please create new issues if work remains or put this content in the documentation.