Project

General

Profile

Feature #4100

A different formula for calculating the detector resolution for the Camera class has been added, and it needs to be integrated into the following applications.

Added by Tyler Wilson about 2 years ago. Updated 3 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Applications
Target version:
Impact:

Pixel resolution will be greatly improved for limb images. There should be no impact to ISIS, other than providing the user with a better approximation for the detector resolution.

Software Version:
Test Reviewer:
Story points:
2

Description

This is the background:

The pixel resolution in the camera class does not compute an accurate pixel resolution other than at the sub-spacecraft lat/lon. The routine uses the proportion of

detectorSize / focalLength = groundPixelResolution / spacecraftAltitude

so

groundPixelResolution = spacecraftAltitude * detectorSize / focalLength

This does a poor job of approximating the pixel resolution at limbs or in the far range of wide angle cameras. A better approximation would be

groundPixelResolution = spacecraftAltitude * detectorSize / focalLength
groundPixelResolution = groundPixelResolution / cos (emissionAngle)

Of course this is not 100% accurate but is significantly better and is not too slow of an algorithm.

Obviously we have to decide how to deal with cos(emissionAngle) approaching zero. The other concern is how this will impact the iterative loops which converge on pixel resolution. Expect to see the truth data for many application and unit test to change slightly.

The status of things now:

The following functions using this new formula have been added to the Camera class:

  • ObliqueDetectorResolution()
  • ObliquePixelResolution()
  • ObliqueLineResolution()
  • ObliqueSampleResolution()

The output from these functions has already been added to

  • mosrange
  • campt
  • camstats
  • phocube

It needs to be added to:

  • The advanced Track Tool: qnet/qview
  • caminfo

It is important when testing this feature to consult with Tammy (tbecker@usgs.gov) or Lynn Weller (lweller@usgs.gov) before committing any changes, because the addition of this feature could negatively impact upon scripts they frequently run. Ideally if they have time, ask them to test your changes for you.


Related issues

Copied from ISIS - Bug #476: Camera class does not compute pixel resolution accurately for limb images Closed

History

#1 Updated by Tyler Wilson about 2 years ago

  • Copied from Bug #476: Camera class does not compute pixel resolution accurately for limb images added

#2 Updated by Tyler Wilson about 2 years ago

  • Private changed from No to Yes

Tyler Wilson wrote:

Description

This is the background:

The pixel resolution in the camera class does not compute an accurate pixel resolution other than at the sub-spacecraft lat/lon. The routine uses the proportion of

detectorSize / focalLength = groundPixelResolution / spacecraftAltitude

So:

groundPixelResolution = spacecraftAltitude * detectorSize / focalLength

This does a poor job of approximating the pixel resolution at limbs or in the far range of wide angle cameras. A better approximation would be

groundPixelResolution = spacecraftAltitude * detectorSize / focalLength
groundPixelResolution = groundPixelResolution / cos (emissionAngle)

Of course this is not 100% accurate but is significantly better and is not too slow of an algorithm.

Obviously we have to decide how to deal with cos(emissionAngle) approaching zero. The other concern is how this will impact the iterative loops which converge on pixel resolution. Expect to see the truth data for many application and unit test to change slightly.

The status of things now:

The following functions using this new formula have been added to the Camera class:

  • ObliqueDetectorResolution()
  • ObliquePixelResolution()
  • ObliqueLineResolution()
  • ObliqueSampleResolution()

The output from these functions has already been added to

  • mosrange
  • campt
  • camstats
  • phocube

It needs to be added to:

  • The advanced Track Tool: qnet/qview
  • caminfo
  • fx

It is important when testing this feature to consult with Tammy (tbecker@usgs.gov) or Lynn Weller (lweller@usgs.gov) before committing any changes, because the addition of this feature could negatively impact upon scripts they frequently run. Ideally if they have time, ask them to test your changes for you.

#3 Updated by Tyler Wilson about 2 years ago

  • Private changed from Yes to No

#4 Updated by Tyler Wilson about 2 years ago

  • Description updated (diff)

#5 Updated by Tyler Wilson about 2 years ago

  • Assignee deleted (Tyler Wilson)

#6 Updated by Tammy Becker about 2 years ago

  • Status changed from New to Acknowledged

#7 Updated by Tammy Becker about 2 years ago

Testing mosrange, campt, camstats, and phocube

/work/users/tbecker/IsisTesting/M00476_OliqueResolution

#10 Updated by Stuart Sides 11 months ago

  • Target version deleted (3.4.12 (FY16 R2 2016-03-17 Mar))

#11 Updated by Stuart Sides 7 months ago

  • Status changed from Acknowledged to Assigned
  • Assignee set to Kaitlyn Lee
  • Target version set to 3.5.3

#12 Updated by Kaitlyn Lee 7 months ago

  • Status changed from Assigned to In Progress

#13 Updated by Kaitlyn Lee 5 months ago

  • Status changed from In Progress to Resolved

#14 Updated by Lynn Weller 5 months ago

I will test the changes as soon as some time becomes available, however that could be a couple of weeks. I will not be determining if the resolution is correct, but rather the effect of the new information in the output of various apps. Please do not close the ticket until you have heard from me. Thanks!

#15 Updated by Lynn Weller 5 months ago

Could you build this for astrovm4? Thanks!

#16 Updated by Kaitlyn Lee 5 months ago

Hi Lynn,
It is now built for astrovm4. Sorry about that!

#17 Updated by Lynn Weller 4 months ago

  • Status changed from Resolved to Feedback

I've taken a look at the changes to caminfo and it needs a little more work.

The PVL output for geometry=true now includes the Oblique Resolution keywords, which is what is expected. However, when changing the format to CSV, the expected result is to have the new keywords at the end of the CSV file, not embedded within. It's important to put the new keywords at the end of the CSV output to make it backwards compatible, meaning the column position of the existing keywords does not change when new keywords are added. This is really important for scripting. It doesn't matter so much for PVL since users tend not to use the PVL files for scripts since CSV is easier to deal with), plus getkey can be used on PVL files to get keyword values and order does not matter. Take a look at the CSV output for camstats as comparison - the new Oblique keywords are appended to the end. Caminfo needs something similar.

Also, I don't see the new keywords in the PVL or CSV output when camstats=true. Since that application has already been updated I was expecting to see the updates here as well, but they are missing. Does caminfo run camstats or does it get the camera statistics in a different manner?

Once changes have been made the documentation for caminfo will need to be updated. The description includes the PVL output for camstats and geometry which should reflect the updates. Links to the Oblique keywords should also be added to the list of keywords already included in the last section of the documentation (SubSolarLat/Lon, etc.). Hopefully the example image being used is from the app tests, but if it isn't I can get you a copy to work with.

As for qview - looks like ALL of the various types of Oblique resolutions are now available, but probably only need one. If you take a look at what is available for Resolution, we only offer up Pixel (?)Resolution, but we don't include the LineResoluton or SampleResolution even though that information is available. We should probably only display Oblique Pixel Res (or maybe Oblique Detector Res) in the qview tracking and omit the other Oblique Res values, unless there is a request to include all of them (I'm not seeing it if there is).

Drop by if you have questions.

#18 Updated by Kaitlyn Lee 3 months ago

  • Status changed from Feedback to In Progress

Also available in: Atom PDF