IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
Juno PDS data
elakdawalla
post Jan 8 2016, 10:15 PM
Post #1


Administrator
****

Group: Admin
Posts: 5020
Joined: 4-August 05
From: Pasadena, CA, USA, Earth
Member No.: 454



There is now PDS-format JunoCam cruise and Earth flyby data available; it's been submitted to the PDS, but MSSS has gone ahead and posted it on their website. I've created an index page to it here. Unlike my usual index pages, there aren't any thumbnails because of the odd nature of JunoCam images, with their long skinny shapes and interleaved framelets. I haven't played much with these data because it's a bit beyond my skill -- I look forward to seeing what any of you can do with it.


--------------------
My blog - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
Go to the top of the page
 
+Quote Post
Gerald
post Jan 14 2016, 02:08 AM
Post #2


Senior Member
****

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



In the meanwhile I've looked at all the 2x121 IMG files, only at few in more detail.

Filename convention with JNCE_2013282_00M103_V01 as an example:
- 3 letters "JNC" for JunoCam,
- 1 letter, "E" for EDR, "R" for RDR,
- "_" always,
- 4 digit year,
- 3 digit day of year,
- "_" always,
- "00" common in all files thus far,
- 1 letter for applied filters, "A": all, "C": colors red, green, blue, "R" red, "G" green, "B" blue, "M" methane,
- 3 digits image counter,
- "_V" version prefix always,
- 2 digits version number.

The IMG files are raw data without header. The header is instead in a separate LBL file.
EDRs are 8-bit unsigned char, RDRs 16-bit unsigned short, big endian encoded, hence need to be swapped for processors of Intel type.
Some of the "methane" test images use sampling factor 2, and are 816 pixels wide - that's a little less than 1648/2, starting with 2013107_00M053.

The RDR LBL files say
QUOTE
SAMPLE_BIT_MODE_ID = "SQROOT"

like the for the EDRs, but they look linearized to me at first glance.

Here a comparison of an 8-fold enlarged crop of EFB13 with the according files JNCE_2013282_00M103_V01, and JNCR_2013282_00M103_V01, the EDR converted in a straightforward way, the 16-bit RDR grey values divided by 20.25 to use the whole grey scale range:
Attached Image


There are at least two kinds of differences between EFB13 and the EDR:
- EFB13 - at least the version one I worked with - shows JPG artifacts,
- the EDR image shows 16x16-pixels macroblocks, possibly to account for HDR.
The macroblocks are present in the RDR, as well.

I didn't find information, how the raw data numbers can be restored.
So some questions about alternative approaches arose:
- Do there exist additional tables of grey value offsets for each macroblock?
- Does there exist a convention how to calculate the relative offset between two neighboring macroblocks?
- Is a subsequent application of a H.264-compliant or some similar deblocking post-process assumed?

After solving the macroblock question, some of the EFB images might eventually return better results than the initial EFB images.

Several images appear well-suited to study
- image geometry, effects of TDI, possible probe nutation, using stars,
- stray light of the Sun as a well-defined source of light.

Go to the top of the page
 
+Quote Post
mcaplinger
post Jan 14 2016, 04:03 AM
Post #3


Senior Member
****

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



QUOTE (Gerald @ Jan 13 2016, 06:08 PM) *
I didn't find information, how the raw data numbers can be restored.
So some questions about alternative approaches arose:
- Do there exist additional tables of grey value offsets for each macroblock?
- Does there exist a convention how to calculate the relative offset between two neighboring macroblocks?
- Is a subsequent application of a H.264-compliant or some similar deblocking post-process assumed?

I'm not sure exactly what you mean by this. The 16x16 block artifacts are from the onboard data compression (same as was used for the MOC way back when -- JPEG-like but with 16x16 transform blocks.) There is no way in general to restore anything as the raw image was never transmitted.

The only difference between the EDR and the RDR is that the RDR has been linearized and a radiometric scale factor applied.

If this had been a real PDS release you would also have access to the documentation. That release is coming but I don't know when; unlike previous missions we don't deliver directly to the PDS. For now I'll see if I can post the documentation on the web site.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Gerald
post Jan 15 2016, 02:41 AM
Post #4


Senior Member
****

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



I've implemented a quick&dirty de-blocking algorithm, which just estimates a constant grey value offset for each 16x16-pixels block in the EDR image.
It seems, that adding such an appropriate constant for each block might be able to remove the block edges:
Attached Image

I thought, that the constant should have been stored somewhere, since it's only one byte per 16x16-block, at most.
The easiest explanation would be considering a glitch in the DCT decompression script causing omission or some truncation of the lowest-frequency term.

... A SIS-like documentation would certainly be useful and answer several questions before they occur.
Go to the top of the page
 
+Quote Post
elakdawalla
post Jan 15 2016, 02:53 AM
Post #5


Administrator
****

Group: Admin
Posts: 5020
Joined: 4-August 05
From: Pasadena, CA, USA, Earth
Member No.: 454



When I ran IMG2PNG on these images I thought the blockiness was because of a bug in IMG2PNG but I've already emailed Bjorn so many feature requests recently, I didn't bug him about this one. Now I'm glad I didn't smile.gif


--------------------
My blog - @elakdawalla on Twitter - Please support unmannedspaceflight.com by donating here.
Go to the top of the page
 
+Quote Post
mcaplinger
post Jan 15 2016, 03:51 AM
Post #6


Senior Member
****

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



QUOTE (Gerald @ Jan 14 2016, 06:41 PM) *
I've implemented a quick&dirty de-blocking algorithm, which just estimates a constant grey value offset for each 16x16-pixels block in the EDR image.

Is what you're calling the "raw" image stretched or something? The raw data don't/shouldn't have anything like the level of visible blockiness that this image has. Either there is something wrong with whatever you're using to convert formats or something messed up in the EDR files themselves.

[Indeed, on further checking my original decompressed version of EFB13 doesn't show these block artifacts. Something is screwed up in our processing chain that produced the EDRs. Thanks for noticing this!]


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Gerald
post Jan 22 2016, 05:56 PM
Post #7


Senior Member
****

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



This week I worked on a better understanding of the hot pixels, mainly in order to infer a specific point noise filter which protects stars.
The stars will help geometric calibration of the camera, which is an ingredient for accurate RGB registering.

Here an excerpt of the observed behavior of the hot pixels:
TDI causes hot pixels to show up as "hot streaks" with the number of TDI steps as length in pixels.
"Hot streaks" grow downward with increasing TDI, if the CH4 filter is defined as "up" and the red filter as "down".
Hot pixels vary over months, mostly in number, but intensity can vary, too.

Here an example comparing hot streaks of 2012, doy (day of year) 294, with 2014, doy 038:
Attached Image

The 2012294 image has been obtained by stacking all framelets of the six TDI 60 images JNCE_2012294_00R036_V01 to JNCE_2012294_00R041_V01, followed by kind of a horizontal hipass filter.
The 2014038 image is the according processing result of the four TDI 80 images JNCE_2014038_00R114_V01 to JNCE_2014038_00R117_V01.

I've then defined a heuristics which reduces the images further to estimated hot pixel positions with respect to the considered framelet, lower left corner defined as coordinates (0;0). Hot pixels may be outside the - in this case - red filter readout zone, even in the green filter readout zone, but the streaks reach the red filter readout zone. So, hot pixel positions beyond framelet y-coordinate 127 occur.
Attached File  file_list_red_01.txt_hot_pixels.csv.txt ( 2.02K ) Number of downloads: 75
Attached File  file_list_red_03.txt_hot_pixels.csv.txt ( 3.19K ) Number of downloads: 80

When combining hot pixels of the red and the green filter, streaks starting in green and ending in red can actually be observed. These inter-filter hot streaks confirm the relative y-offset of 155 pixels between the red and the green readout zone.

I didn't see good data for the blue filter; thus far, those show strong compression artifacts. Nevertheless, you may see some matches with the green filter.

Here an example of stacked and hipass-filtered framelets as insets in a simulation of TDI 80 hot streaks from reduced data:
Attached Image

CH4 input data were TDI 64 (of 2011238), therefore the streak length in the simulation is different from the inset image. The CH4 data are early in the cruise. Therefore matchings with the blue data are less likely.
Go to the top of the page
 
+Quote Post
Gerald
post Jan 30 2016, 03:27 PM
Post #8


Senior Member
****

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



This one is mostly about finding blips used as star candidates.

After some correlation analysis, it turned out, that hot streaks in the EDRs behave sub-additionally, as expected for square-root encoded data. But squaring didn't result in perfect additivity. The inferred contribution of the hot streak still showed dependence of the background brightness:
Attached Image

Nevertheless I've subtracted repetitive patterns on dark background in a linear way, by subtracting the squares of values obtained from the EDRs, in order to obtain a 0th degree approximation for cleaned images. Blink gif before/after cleaning:
Attached Image

This imperfection is to some degree intentional to encourage at least some resilence of the consecutive processing.

The next processing step tries to find blips which are good star candidates. The centroid of the blips (using pixels above some threshold) is determined after subtracting the mean background level in a ring around the blip.
Then a best-fitting line ("principle component") through the centroid is determined. With TDI 80, stars form small streaks.
After calculating the vertical and horizontal mean distance of the pixels of the blip, weighted by brightness, blips similar to hot streaks are filtered out (some resilence with respect to hot streaks). The remaining star candidates are marked by a respective circle.

I've then roughly compared the marked blips with star maps by eye, to get a preliminary assessment of how many stars can be identified for a good geometric calibration.
For image JNCE_2014038_00R117_V01, a 180 degrees panorama, I could find about 80 good star candidates. Here an according annotated intermediate processing step:
Attached Image

Some similar images are available. This should be sufficient to calibrate at least the red filter area geometrically.

Next, I'll probably simulate BSC stars with two families of geometric camera models, a purely radially Brown-Conrady-distorted pinhole model, and a purely radially Brown-Conrady and hyperbolically distorted pinhole model. I'm expecting the hyperbolic model to be better suited, since a Brown distortion allone cannot model a hyperbolic distortion, if my draft calculations are correct. But I currently think, an idealized rotating pushframe camera should distort hyperbolically. A full radial Taylor series, not skipping any second summand as in the radial Conrady model, might be a third option. The latter approach is sufficiently powerful to describe hyperbolic distortions, as well.

Btw.: JNCE_2014038_00R116_V01 probably shows a gcr hit:
Attached Image
Go to the top of the page
 
+Quote Post
Gerald
post Feb 15 2016, 02:46 PM
Post #9


Senior Member
****

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



This is about a first crude simulation of image JNCE_2014038_00R117_V01 using BSC stars.

Starting from a version of the star catalog BSC5p
Attached File  bsc5p_equatorial.zip ( 155.14K ) Number of downloads: 80

I've calculated and added the according 3d unit vectors
Attached File  bsc5p_equatorial_vectors.zip ( 383.81K ) Number of downloads: 76
.

Then crudely assuming
- a camera rotation of 79 frames per 360° (guess from EFB images, neglecting effect of spacecraft motion),
- a pinhole horizontal scale of 29° for 800 pixels from an assumed optical center at (822;600) towards one side, (simplified, and somewhat inaccurate interpretation of the Junocam paper, 1.)
- a consecutive Brown distortion with K1 = -3.839251e-8, (JunoCam paper, 6.7, added sign)
- red, green, blue, CH4 filters assumed as starting at y values 306, 461, 616, 781, with lower left as (0;0), (recalculated from a post of M.Caplinger)
and negelecting TDI, I've calculated the 3d unit vectors corresponding to the centroids of the blips, and annotated several of them with star candidates,
Attached File  Stars_JNCE_2014038_00R117_V01_Star_candidates_vec_pinhole_brown2_man_annot.txt ( 20.35K ) Number of downloads: 88

then reduced the list considerably
Attached File  Stars_JNCE_2014038_00R117_V01_Star_candidates_vec_pinhole_brown2_man_annot_smallExcerpt.txt ( 942bytes ) Number of downloads: 91

and fused it with the corresponding BSC data to
Attached File  bsc5p_equatorial_vectors_small_excerpt_assoc_junocam_img117.txt ( 1.57K ) Number of downloads: 78


Further restriction to three stars - chosen in a way to avoid almost-singularities - results in two 3x3 matrices
Attached File  bsc5p_equatorial_vectors_small_excerpt_assoc_junocam_img117_matOnly.txt ( 345bytes ) Number of downloads: 100


Inverting the (transposed) of the matrix for the BSC vectors, and multiplying the (transposed) matrix for the blip vectors from the left results in an estimated transformation matrix from BSC to JNCE_2014038_00R117_V01 vectors.
This matrix, however, isn't quite orthonormal. Applying the vector product twice to replace two of the colums of the transformation matrix, and normalization of the columns, adjusts the transformation matrix to orthonormal.
Attached File  Stars_JNCE_2014038_00R117_V01_TransformationMatrix01.txt ( 174bytes ) Number of downloads: 91


A first attempt to simulate star positions for JNCE_2014038_00R117_V01 by using BSC stars and the obtained transformation resulted in this annoteted image:
Attached Image

Adjusting
- the camera rotation to 81.0 frames per 360°,
- the pinhole scale to 28.3° for 800 pixels,
and treating multiple occurences of the same star, resulted in a somewhat better simulation.
Attached Image

The blip vectors used for the transformation matrix are still to be adjusted accordingly.

Despite the errors in some cases globally adding up to about 40 pixels at this crude state, the simulation helps identifying stars more reliably, which is needed for RMS minimization methods.
Among the next intended steps are
- merging the above individual calculations to a more automated pipeline,
- considering the displacement due to TDI, and
- developing and applying optimization methods to pin down the geometric camera parameters (at least for red and green bands).
Go to the top of the page
 
+Quote Post
Gerald
post Feb 22 2016, 06:23 PM
Post #10


Senior Member
****

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



The following tentative BSC star identifications of blips in image 117 look sufficiently good, that I'll be going to work on RMS minimization of the geometric parameters now.
Attached Image

Using the HR numbers simplified comparing the simulations
Attached Image

with the cleaned JunoCam image, here annotated according to the above survey of the blip identifications.
Attached Image

There is still a small number of flaws in the survey, but it should be easy for the RMS optimization to flag them as invalid.
Go to the top of the page
 
+Quote Post
Gerald
post Mar 24 2016, 07:29 PM
Post #11


Senior Member
****

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



This article is about a geometric calibration method using stars of a single swath and first results for image JNCE_2014038_00R117_V01:
Attached File  junocam06_geometry_by_stars.pdf ( 254.45K ) Number of downloads: 190


Here a graphics of two of the inferred Brown distortions compared to the MSSS laboratory result, y-value for optical axis chosen by optimization algorithm:
Attached Image


The four simulated images corresponding to the distortions considered in appendix A of the above article:
With constant optical axis at y=600, for Brownian K1, and for Brownian K1+K2:
Attached Image
Attached Image


Y-value for optical axis chosen by optimization algorithm, again for Brownian K1, and for Brownian K1+K2:

Attached Image
Attached Image


========

I'll probably work on RGB registering for spheroids (with fuzzy surface), before refining the geometric in-flight calibration.
Go to the top of the page
 
+Quote Post
wildespace
post Jun 27 2016, 07:59 AM
Post #12


Member
***

Group: Members
Posts: 174
Joined: 15-January 13
Member No.: 6842



I don't know how to work with IMG files (they won't even mount on a virtual drive on my laptop), so could someone please post JunoCam's RGB images of stars and the zodaical light? Information about the exposure for those images would be appreciated too.

Thanks smile.gif


--------------------
Go to the top of the page
 
+Quote Post
Gerald
post Jun 27 2016, 05:36 PM
Post #13


Senior Member
****

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



I'll try to convert the square root encoded EDR IMGs to PNGs, if you like, within about a day, and provide a link to a list of the files. But be aware, that some of the images currently show the blocky decompression glitch.
Go to the top of the page
 
+Quote Post
mcaplinger
post Jun 27 2016, 05:49 PM
Post #14


Senior Member
****

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



We didn't take any RGB images of stars and the zodiacal light. We took some red and some green with spectral crosstalk because the amount of TDI was longer than the frame height would support.

As for processing the IMG files, there's a saying about giving a man a fish, I don't quite recall how it goes. smile.gif


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Gerald
post Jun 27 2016, 09:59 PM
Post #15


Senior Member
****

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



Well, applying the saying would mean, read my post #2, above, in order to understand the structure of the IMGs, then try Björn's IMG2PNG, some other image processing software able to read raw data, or write your own converter software.
If all these options fail, ask for help.
Go to the top of the page
 
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic

 



RSS Lo-Fi Version Time is now: 25th April 2017 - 06:47 AM
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.