Juno PDS data |
Juno PDS data |
Sep 6 2017, 07:11 PM
Post
#31
|
|
Senior Member Group: Members Posts: 2346 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.
|
|
|
Sep 19 2017, 12:38 AM
Post
#32
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
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? |
|
|
Sep 19 2017, 02:34 AM
Post
#33
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
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.
|
|
|
Sep 25 2017, 05:24 AM
Post
#34
|
|
Member Group: Members Posts: 406 Joined: 18-September 17 Member No.: 8250 |
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 |
|
|
Sep 25 2017, 04:14 PM
Post
#35
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
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.
|
|
|
Sep 26 2017, 05:09 PM
Post
#36
|
|||
Member Group: Members Posts: 406 Joined: 18-September 17 Member No.: 8250 |
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. 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. |
||
|
|||
Sep 27 2017, 01:05 AM
Post
#37
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
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.
|
|
|
Sep 27 2017, 11:00 PM
Post
#38
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 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).
|
|
|
Sep 27 2017, 11:43 PM
Post
#39
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
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.
|
|
|
Sep 28 2017, 01:01 AM
Post
#40
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 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. |
|
|
Sep 29 2017, 08:13 PM
Post
#41
|
|
Member Group: Members Posts: 406 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 |
|
|
Oct 28 2017, 11:42 PM
Post
#42
|
|
Senior Member Group: Members Posts: 2346 Joined: 7-December 12 Member No.: 6780 |
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: junocam10_geometry_by_single_mm_pj08.pdf ( 1.5MB ) Number of downloads: 981 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. |
|
|
Dec 18 2017, 06:57 PM
Post
#43
|
|
Member Group: Members Posts: 406 Joined: 18-September 17 Member No.: 8250 |
Mike, how small of an INTERFRAME_DELAY can be commanded to Junocam?
I’m thinking that if a value like .02 seconds were used when targeting moons, the multiple images gathered could potentially be used for super-resolution imaging. |
|
|
Dec 18 2017, 08:00 PM
Post
#44
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
Mike, how small of an INTERFRAME_DELAY can be commanded to Junocam? I’m thinking that if a value like .02 seconds were used when targeting moons, the multiple images gathered could potentially be used for super-resolution imaging. No way. The minimum interframe time is about 200 msec, 10x longer than what you suggest. The camera has to flush the CCD and then read out the subframe between each frame. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Dec 18 2017, 10:42 PM
Post
#45
|
|
Senior Member Group: Members Posts: 2346 Joined: 7-December 12 Member No.: 6780 |
Any attempts to create SR products would require losslessly compressed images. Otherwise, it is already in improvement to reduce compression artifacts and other image noise. Occasionally, lossless images are made. In these cases, there is at least a theoretical chance to use the three color channels for resolution improvements, and sometimes, you even get an overlap of two framelets of the same color band for the target object, such that four takes of the same target can be assumed. This would allow for a doubling of the resolution in the best case. Further methods would combine several raws of a sequence of images of the same target. This requires, however, very accurate alignment and de-rotation.
But usually, I'm already happy, when overlapping channels can be used to reduce image noise. |
|
|
Lo-Fi Version | Time is now: 26th April 2024 - 03:34 AM |
RULES AND GUIDELINES Please read the Forum Rules and Guidelines before posting. IMAGE 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 funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member. |