Project

General

Profile

Bug #1545

Local Incidence and Emission computed wrong for certain types of images

Added by Jeff Anderson almost 5 years ago. Updated 5 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
API
Target version:
Impact:
Software Version:
Test Reviewer:
Story points:
4

Description

DoD:

  • Local angles are calculated correctly for the data mentioned.
  • If this calculation isn't right for this instrument, it isn't correct for other pushframes.
    • (If calculation isn't right for this instrument, and is correct for other pushframes, the camera model is messed up)

Hi Adam,

This certainly fixes the problem in phocube. It would just be a temporary fix. The problem is the local slope is computed in qview, campt and several other programs using sub-pixel coordinates. So for example, in campt or when zoomed in qview at line 14.2 adding 0.5 would cross the framelet boundary and the local slope would be computed incorrectly. I looked at the code and wonder to myself why we just didn't compute the slope strictly from the DTM?

For now if you are stuck I would make the quick change to adding .499 and just be aware that about campt and qview. I will get a ticket into our system to see if we can get this bug repaired correctly.

In terms of impacts on other cameras it would obviously impact MARCI which is identical to the WAC. I also suspect it would impact the CRISM camera model; it collects non-contiguous data because of an onboard gimbal. I can only see an impact to LROC NAC if the spacecraft attitude is being adjusted to paint ground that has already been covered. I've seen this only in images where folks wanted to try to collect super resolution images (I think MGS MOC tried this).

Thanks, Jeff

On Tue, Mar 5, 2013 at 9:29 PM, Adam Licht alicht@ser.asu.edu wrote:

Hi Jeff-

We've recently come across an issue when running phocube on WACs. Specifically when using the 'localemission'
and 'localincidence' options. The last line of each frame does not seem to be continuous with the rest of the
frame (I've attached a screenshot of this).

I've looked into this a bit and seem to of isolated the problem. When the camera create the local normal
vector, it takes a lattice of points around the pixel (+/- 0.5 in each direction). When this is done on the last
line in a frame, the 'bottom point' ends up in the next frame, causing the error. When changing these values to
0.49 the output for the WAC looks as it should. This would be a quick fix, however, I do not know how this would
effect other cameras.

There is a cub that can be used to reproduce this at '/home/ser/alicht/tmp/4janderson
/M146803466C.vis.even.cal.cub'
An example command line to generate the error is:
'phocube from=/home/ser/alicht/tmp/4janderson/M146803466C.vis.even.cal.cub to=out.cub phase=false
emission=false incidence=false localemission=true localincidence=true latitude=false longitude=false'

Do you have any insight regarding if this effects any other cameras? Or perhaps a better fix?

Thanks!
Adam

--
Adam Licht
Lunar Reconnaissance Orbiter Camera Science Operations Center
Arizona State University
School of Earth and Space Exploration
Interdisciplinary A115
Tempe AZ 85287-3603
http://lroc.sese.asu.edu

--
Jeffery Anderson
Supervisory Computer Scientist
Astrogeology Science Center
2255 N Gemini Drive
Flagstaff, Arizona
928-556-7167

Steps to reproduce:

Run phocube on a wac image and output the local incidence or emission images

wac_last_line.png View (10.8 KB) Redmine Admin, 2013-03-06 10:47 AM

History

#3 Updated by Anonymous over 4 years ago

  • Target version deleted (150)

#9 Updated by Tammy Becker 10 months ago

  • Target version set to 3.5.1 (Sprint 1)

#10 Updated by Ian Humphrey 9 months ago

  • Story points set to 4
  • Description updated (diff)

#11 Updated by Tyler Wilson 9 months ago

  • Assignee set to Tyler Wilson

#12 Updated by Tyler Wilson 9 months ago

  • Status changed from Acknowledged to In Progress

#13 Updated by Stuart Sides 9 months ago

  • Description updated (diff)

#14 Updated by Stuart Sides 9 months ago

  • Description updated (diff)

#15 Updated by Tyler Wilson 8 months ago

  • Status changed from In Progress to Resolved

#16 Updated by Ian Humphrey 8 months ago

  • Status changed from Resolved to In Progress

#17 Updated by Stuart Sides 5 months ago

  • Target version changed from 3.5.1 (Sprint 1) to 3.5.2 (2017-01-31 Jan)

Also available in: Atom PDF