hijitter output scaling issue

[ascbot]

---

Author Name: Paul Geissler (Paul Geissler)

---

From Audrie Fennema at HiROC, highest priority per Rod Heyd: A bug in hijitter produces different results when applied to RED noproj than when applied to the red plane of COLOR noproj.

On 7/29/13 2:28 PM, Audrie Fennema wrote:
I was able to reproduce this behavior. I ran a few tests with the current version of ISIS. Apparently, the scaling of the resulting cubs from hijitter processing depends on which input ccds that are included. In this particular case, I originally processed all the reds (red0-red9) ccds with hijitter. That is where the RED noproj cube came from. A couple of weeks later, when I created the color products, I processed only the center reds (red4, red5 and red6(I don't know why I included 6?)) along with the all color ccds through hijitter. That is why there is a scaling difference between the RED noproj and the COLOR noproj.

I don't know if this is expected behavior, but it seems a little odd to me.

Audrie

On 7/22/13 2:17 PM, Audrie Fennema wrote:
I'm trying to remember what exactly I did to process these. These were my first attempt at processing color. It was before I had added color processing to the pipeline, so there was some hand processing involved. There is also a time difference of couple of weeks between when I created red and color... and possibly an ISIS version difference. Instead of trying to figure out what exactly went wrong, I will reprocesses this image with the current pipeline and ISIS version and see if there is any scaling issue. I'll let you know what I find.

Audrie

On 7/22/13 11:54 AM, Sarah Mattson wrote:
Hi Annie,

Before I reply to your email about the updated color scripts, I took a look at the attached PDF.

I think you did test the correct images. The RED band of the test_stack should be identical to the center swath of the full RED noproj cube. Just to be sure nothing funny happened when I stacked the three bands, I compared the RED4-5 noproj cube to the full RED noproj cube. I see the same scaling difference you did.

I'm not sure where this is happening. The test color products were made using the same procedure, now that hijitter will process them. I'm cc'ing Audrie so she is aware of this and can hopefully help track it down.

Thank you for finding this and bringing it to our attention.

Thank you,
Sarah

Begin forwarded message:

From: "Howington-Kraus, Elpitha" [email protected]
Date: July 19, 2013 5:12:53 PM MST
To: Sarah Mattson [email protected]
Cc: Randolph Kirk [email protected], Kenneth Herkenhoff [email protected], Elpitha Howington-Kraus [email protected]
Subject: Dejitter discrepancies?

Hi Sarah,

Here is the follow-up email to the one I just sent:

When validating the import of dejittered COLOR cubes for Socet Set, I noticed what looks like a scaling difference between the full 10-CCD RED dejittered image, and the RED band of the dejittered COLOR image. To make sure what I was seeing had nothing to do with sensor models, I displayed the cubes in qview, and saw the same discrepancy. The attached pdf file contains screen snapshots of what I am seeing.

Several things come to mind, first of which is an error on my part. The images I am comparing are:
/data/DTM_working/Projects/Valles_Marineris_RSL/ESP_027802_1685_dejittered_COLOR/test_stack.cub
and
/data/DTM_working/Projects/Valles_Marineris_RSL/dejit027802/ESP_027802_1685_RED.NOPROJ.cub.gz

Are these the images I should be comparing?
If yes, was the same dejittering process used for both products?
Has something else changed? (I'm wondering because of our issues this FY with dejittered images - especially in the Oudemans site.)

With our current procedures, in order to generate color orthos, we need a 1:1 correspondence between the full 10-CCD RED image and the COLOR bands.

Sorry to pass on issues on a Friday :)
Thanks,
Annie

Elpitha "Annie" Howington-Kraus
U.S. Geological Survey
Astrogeology Science Center
2255 N. Gemini Dr.
Flagstaff, AZ 86001
(928) 556-7244
[email protected]

==========================
Sarah Mattson
Sonett Space Sciences Building
University of Arizona
1541 E. University Blvd.
Tucson, Arizona 85721
(520) 626-0759
[email protected]

--
<>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Audrie Fennema
HiRISE Operations Center
Lunar & Planetary Laboratory
University of Arizona
1541 E. University Blvd. Rm. 213
Tucson, AZ 85721-0063
Work: 520.626.0756
Cell & Text: 520.235.8428
<><<<<<<<<<<<<<<<<<<<<<<<<<<<

--
<>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Audrie Fennema
HiRISE Operations Center
Lunar & Planetary Laboratory
University of Arizona
1541 E. University Blvd. Rm. 213
Tucson, AZ 85721-0063
Work: 520.626.0756
Cell & Text: 520.235.8428
<><<<<<<<<<<<<<<<<<<<<<<<<<<<

--
<>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Audrie Fennema
HiRISE Operations Center
Lunar & Planetary Laboratory
University of Arizona
1541 E. University Blvd. Rm. 213
Tucson, AZ 85721-0063
Work: 520.626.0756
Cell & Text: 520.235.8428
<><<<<<<<<<<<<<<<<<<<<<<<<<<<

Kirk, Randolph [email protected]
Aug 1

to Kenneth, Audrie, Sarah, Elpitha, me
My impression of this issue is that it's related to how we merge the highpass part of the jitter history from the HiJACK solution back into the lowpass pointing that originates in the CK. If one filters the CK over slightly different time periods one might somehow get a slightly different trend line and a different length image. I'm not sure we can make the results independent of the time interval except maybe by doing that filtering over the max time interval of all 14 detectors regardless of which ones are selected for fixing. If we want to try to fix this, then Debbie's help is probably going to be very valuable to get us started.

  Randy

[ascbot]

---

Original Redmine Comment
Author Name: Moses Milazzo (Moses Milazzo)
Original Date: 2015-05-14T15:29:22Z

---

Ken H. asked me to assign this to myself. I will begin researching its fix shortly.

[ascbot]

I am a bot that cleans up old issues that do not have activity.

Happy Birthday to this issue! 🎂

Unfortunately, this issue has not received much attention in the last 12 months. Therefore, I am going to close it. Please feel free to reopen this issue or open a new issue sometime in the future. If this issue is a bug report, please check that the issue still exists in our newest version before reopening.