IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3  
Reply to this topicStart new topic
Juno PDS data
Gerald
post Sep 6 2017, 07:11 PM
Post #31


Senior Member
****

Group: Members
Posts: 1904
Joined: 7-December 12
Member No.: 6780



I'll try to squeeze it in appropriately during the first half of October, at least partially. I could also take some of the (vast amount of) pretty unstructured material to Riga, and meet with your colleague Michael Ravine. This week, and most of next week, PJ08 processing and preparing the EPSC talk(s) have priority.
Go to the top of the page
 
+Quote Post
Bjorn Jonsson
post Sep 19 2017, 12:38 AM
Post #32


IMG to PNG GOD
****

Group: Moderator
Posts: 1918
Joined: 19-February 04
From: Near fire and ice
Member No.: 38



QUOTE (Gerald @ Sep 6 2017, 12:02 PM) *
Unfortunately, I need to deviate from the best fits derived from star positions in order to obtain best-fits of local RGB alignment, the latter two orders of magnitude more accurate. There must still be some unconsidered effect, at least in my models. I hope, that I'll find more time for geometrical calibration near the end of this year. Possibly K3 plays some role near the margins. And I'm inclined to verify, whether there is some small chromatic aberration, and whether the pixels are perfectly square.

k1 and k2 values that result in more accurate RGB alignment would be very useful.

Using the updated radial distortion function parameters (k1 and k2) and focal length from the new JunoCam kernel file has reduced the RGB color alignment errors I'm getting (the updated frame kernel is probably also significant here). After reprojecting the framelets to simple cylindrical projection I usually warp the green and blue channels into the red channel because even an alignment error of just ~2 pixels is noticeable in enhanced/sharpened images - I want 'perfect' alignment. However, when I use the new kernels the alignment errors are smaller than before (I need to process more images to completely confirm this though). The area where I need to warp the GB channels is also smaller (it's near the image edges - close to center the alignment is/was perfect). Some of the alignment errors might be due to slight inaccuracies in the camera pointing parameters I'm using when reprojecting the images.

Regarding a possible small chromatic aberration: Is it possible that the best way to get rid of RGB alignment errors might be to use slightly different k1 and k2 values for the different color channels? Has this been tried?
Go to the top of the page
 
+Quote Post
mcaplinger
post Sep 19 2017, 02:34 AM
Post #33


Senior Member
****

Group: Members
Posts: 1607
Joined: 13-September 05
Member No.: 497



QUOTE (Bjorn Jonsson @ Sep 18 2017, 04:38 PM) *
Is it possible that the best way to get rid of RGB alignment errors might be to use slightly different k1 and k2 values for the different color channels?

I'd have thought that the focal length would be a larger variable than k1/k2.

Gerald has said that he is getting residuals much smaller than 0.1 pixels. I haven't been able to get anything close to that good, so it would be very useful for him to document his processing in a way that could be incorporated into the I kernel.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post Sep 25 2017, 05:24 AM
Post #34


Newbie
*

Group: Members
Posts: 6
Joined: 18-September 17
Member No.: 8250



QUOTE (mcaplinger @ Sep 5 2017, 03:58 PM) *
For this most recent kernel update, we (a summer intern and I) measured thousands of cruise star image locations and then used Nelder-Mead nonlinear optimization to minimize camera model error while varying seven model parameters: image optical center (cx, cy), the first two terms in the radial distortion function (k1, k2), camera focal length (fl), and camera boresight angular misalignment in X and Y (xr, yr). The residual error is still about 1 pixel cross-spin and ~2.5 pixels down-spin (1 sigma); the latter higher because of remaining timing slop.


Hi Mike,

Iíve also been looking at PDS cruise phase full-rotation color images for camera geometry calibration. I noticed what appear to be changes in compression artifacts between datatakes without an indication of a change in the .LBL file. For example, between JNCE_2016026_00C00063_V01 and JNCE_2016026_00C00064_V01.
Could you comment on that?

I also wonder if there are opportunities for non-standard imaging around apojove (or any time Jupiter is fairly small in the FOV). If so, some imagery I think could be useful are:

1. Command JunoCam to disable TDI and capture a full rotation of color frames with EXPOSURE_DURATION around 464ms to 816ms. The goal being to capture bright stars or moons as slightly curved trails passing over filter boundaries, which could then be used to help characterize chromatic aberration and geometry. Ideally, collect several of these at different altitudes to capture trails from the moons in different sets of CCD columns.

2. Collect a sequence of low compression color frames spanning more than one full rotation. The goal being to allow wrap around linkage for FOV measurement to be performed with more stars (and away from the first frame which seems to have a higher noise level). Ideally, collect a series of these, each starting at a different random rotation angle.

Thanks,
Brian Swift
Go to the top of the page
 
+Quote Post
mcaplinger
post Sep 25 2017, 04:14 PM
Post #35


Senior Member
****

Group: Members
Posts: 1607
Joined: 13-September 05
Member No.: 497



QUOTE (Brian Swift @ Sep 24 2017, 09:24 PM) *
I noticed what appear to be changes in compression artifacts between datatakes without an indication of a change in the .LBL file. For example, between JNCE_2016026_00C00063_V01 and JNCE_2016026_00C00064_V01.
Could you comment on that?

A visual example of what you are reacting to would be helpful.

Without looking at these specific images, we've observed an effect where as the sensor warms up during operation, the dark level in the images interacts with the companding table in such a way as to (paradoxically) make the images less noisy, which changes the behavior of the lossy compressor. Unfortunately, the PDS archive product wasn't defined with a field to record what the actual compression factor was (that is, we don't record how big the original downlink file was), which would give some indication of what level of compression artifact to expect.

QUOTE
I also wonder if there are opportunities for non-standard imaging around apojove

At the moment Junocam is turned off except near perijove, and the time near perijove is fully subscribed with images of the planet.

With regard to calibration, my philosophy is to try to extract all the information possible from images that we already have before taking new images. There were a few instances in cruise where the TDI was commanded assuming the spacecraft was spinning at 1 RPM and it was really spinning at 2 RPM, and these images have the kinds of streaks you're describing. We just ignored them when we were doing our calibration, but maybe they have some utility.

There are many, many images taken all the way around the orbit on orbit 1 of the moons with no TDI, and that's a good source of geometric information that we are in the early stages of looking at.

Taking long exposures without TDI is outside the parameters that the instrument was designed to work within. It might be possible to command this, but obviously you can't take contiguous frames around a spin so you'd be taking images of somewhat random star fields.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post Sep 26 2017, 05:09 PM
Post #36


Newbie
*

Group: Members
Posts: 6
Joined: 18-September 17
Member No.: 8250



QUOTE (mcaplinger @ Sep 25 2017, 09:14 AM) *
A visual example of what you are reacting to would be helpful.

As an example, the below images are the third frames from JNCE_2016026_00C00063_V01.IMG and JNCE_2016026_00C00064_V01.IMG which have START_TIMEs 2016-01-26T08:56:02.168 and 2016-01-26T09:01:02.082. The images were decompanded and DN 0 to 8 were stretched full display range.
Attached Image


Attached Image

QUOTE
Unfortunately, the PDS archive product wasn't defined with a field to record what the actual compression factor was

Besides compression factor, are there other instrument configuration parameters that effect imaging characteristics which are not recorded in the metadata?

QUOTE
At the moment Junocam is turned off except near perijove, and the time near perijove is fully subscribed with images of the planet.

OK. If I decide to request some special imaging Iíll run it though the perijove voting process, with the imaging to occur during or at the end of the departure movie collection.

QUOTE
There are many, many images taken all the way around the orbit on orbit 1 of the moons with no TDI...

Great, Iíll go look for them on PDS. Iíd assumed all the non-cruise imagery was on the missionjuno web site.

One more question: is the imagery collected for the Junocam Calibration Report available online anywhere?

Thanks again.
Go to the top of the page
 
+Quote Post
mcaplinger
post Sep 27 2017, 01:05 AM
Post #37


Senior Member
****

Group: Members
Posts: 1607
Joined: 13-September 05
Member No.: 497



QUOTE (Brian Swift @ Sep 26 2017, 09:09 AM) *
As an example, the below images are the third frames from JNCE_2016026_00C00063_V01.IMG and JNCE_2016026_00C00064_V01.IMG

Yes, that's an example of the effect I described.
QUOTE
Besides compression factor, are there other instrument configuration parameters that effect imaging characteristics which are not recorded in the metadata?

If we ever changed any of the piecewise linear companding parameters (which we don't plan to do) there is no place to record them in the metadata. One issue is that the PDS doesn't easily provide a way to define new keywords and has a pretty sparse set of standard keywords (for example, we had to lobby to get a keyword to describe the amount of TDI -- even though TDI has been used on earlier instruments, there is no standard keyword for it.)
QUOTE
One more question: is the imagery collected for the Junocam Calibration Report available online anywhere?

Not publicly, no, not at this time. Some missions archive their ground data and some don't, and of the ones that do, some of them spend a lot of effort to make that intelligible and some don't. Most of our ground images were taken with ground support equipment that read out a large area of the CCD including the "junk" between band edges, and so it doesn't fit perfectly into the definition of the standard PDS product.

If I thought any of the ground images were generally useful, I'd be more interested in trying to get them into some releasable form.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Bjorn Jonsson
post Sep 27 2017, 11:00 PM
Post #38


IMG to PNG GOD
****

Group: Moderator
Posts: 1918
Joined: 19-February 04
From: Near fire and ice
Member No.: 38



Is there any possibility the compression factor could be included in future PDS releases? There is a PDS keyword for a compression factor - the Galileo and Cassini PDS files include it and it's *very* useful, especially in the case of Galileo (I always check the compression factor when processing Galileo images).
Go to the top of the page
 
+Quote Post
mcaplinger
post Sep 27 2017, 11:43 PM
Post #39


Senior Member
****

Group: Members
Posts: 1607
Joined: 13-September 05
Member No.: 497



QUOTE (Bjorn Jonsson @ Sep 27 2017, 03:00 PM) *
Is there any possibility the compression factor could be included in future PDS releases?

I see "encoding_compression_ratio", is that what you're talking about?

It's more difficult than you would think to add because we can't make any changes without going through another lengthy review/approval cycle. And frankly, while I admit it was an oversight, I am not seeing a really compelling need to know it. We could perhaps consider having some kind of ancillary table or text file and I'd be happy to informally distribute that.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Bjorn Jonsson
post Sep 28 2017, 01:01 AM
Post #40


IMG to PNG GOD
****

Group: Moderator
Posts: 1918
Joined: 19-February 04
From: Near fire and ice
Member No.: 38



Yes, ENCODING_COMPRESSION_RATIO in the Galileo files (it's INST_CMPRS_RATIO in the Cassini PDS files).

An ancillary table or text file would be great - it wouldn't make any difference to me whether the compression ratio was in a PDS formatted LBL file or in a separate text file.
Go to the top of the page
 
+Quote Post
Brian Swift
post Sep 29 2017, 08:13 PM
Post #41


Newbie
*

Group: Members
Posts: 6
Joined: 18-September 17
Member No.: 8250



The Mathematica apps Iíve developed for processing JunoCam raw images with the Hugin panorama application are available at https://github.com/BrianSwift/JunoCam

Juno25 converts MissionJuno website -raw.png files to full CCD frame images which can be processed as a panorama in Hugin.

Juno24e extracts control points from PDS cruise phase star fields to drive Huginís lens parameter generation.

The produced lens parameters v=44.96 b=-0.01045 d=12.99 e=13.89 yield Average control point distance = .252, Standard deviation = .319, Maximum = 3.13. Description of parameters is at http://wiki.panotools.org/Lens_correction_model

First image is available at https://flic.kr/p/XXpGUx
Go to the top of the page
 
+Quote Post
Gerald
post Oct 28 2017, 11:42 PM
Post #42


Senior Member
****

Group: Members
Posts: 1904
Joined: 7-December 12
Member No.: 6780



QUOTE (mcaplinger @ Sep 19 2017, 04:34 AM) *
Gerald has said that he is getting residuals much smaller than 0.1 pixels. I haven't been able to get anything close to that good, so it would be very useful for him to document his processing in a way that could be incorporated into the I kernel.

I'm aligning the RGB centroids of a marble movie image according to some convention by adjusting camera parameters. This problem can be statet as an underdetermined system. Therefore it isn't too difficult to find a solution with an error on the order of a few millipixels, much better than it's possible with star streaks.
This doesn't mean, that such a local solution needs to apply globally. But it provides a means of obtaining rather accurate data points required for global calibration.
Here an intermediate and very technical report, including some analysis of several scenarios:
Attached File  junocam10_geometry_by_single_mm_pj08.pdf ( 1.5MB ) Number of downloads: 41

It's about what I've been able to write up, before I needed to switch tasks. I hope, that I'll find time to continue with global calibration after a first run of PJ09 processing is completed, with an RMS minimization method I've hinted to in the above article.
Accurate registering isn't limited to centroids, but determining centroids is rather straightforward to implement.

Go to the top of the page
 
+Quote Post

3 Pages V  < 1 2 3
Reply to this topicStart new topic

 



RSS Lo-Fi Version Time is now: 20th November 2017 - 03:33 PM
RULES AND GUIDELINES
Please read the Forum Rules and Guidelines before posting.

IMAGE COPYRIGHT
Images posted on UnmannedSpaceflight.com may be copyrighted. Do not reproduce without permission. Read here for further information on space images and copyright.

OPINIONS AND MODERATION
Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators.
SUPPORT THE FORUM
Unmannedspaceflight.com is a project of the Planetary Society and is funded by donations from visitors and members. Help keep this forum up and running by contributing here.