Juno perijoves 2 and 3, October 19 and December 11, 2016 Options

[Candy Hansen]

A lot has happened and it seemed like a good time to start a new post. We will be staying in 53 day orbits until the project has a full understanding of the risks that may or may not be associated with reducing the orbit period to 14 days per our previous plan.

[Candy Hansen]

At the press conference last week I showed many beautifully processed images from amateurs, including many from this community. Thank you all very much! They were well-received, and in particular one reporter from space.com would like to follow up with a story on some of the individuals doing this great work. Please contact me if you would like to be interviewed, and I will get you connected.

[Candy Hansen]

At this moment we are trying to find the best time to get JunoCam powered back on to go back to collecting marble movie images. In any case we expect to be on for full image collection through Perijove 3 on December 11.

[Roman Tkachenko]

At the press conference last week I showed many beautifully processed images from amateurs, including many from this community. Thank you all very much! They were well-received, and in particular one reporter from space.com would like to follow up with a story on some of the individuals doing this great work. Please contact me if you would like to be interviewed, and I will get you connected.

Thank you so much for using my images at the press conference. It was a great honor for me and a big pleasure to know that these images were shown there.

[Glenn Orton]

Until and unless we figure out how to fix or find a way to work around the engine sticky-valve issue, the new orbit perijoves will be on 2016 Dec 11 (PJ3), 2017 Feb 2 (PJ4), Mar 27 (PJ5), May 18 (PJ6), Jul 10 (PJ7), Sep 2 (PJ8), Oct 25 (PJ9). It's like that a solution/workaround will not be figured out until the time frame of PJ7.

This will affect not only the mission, but nearly all of the Earth-based support campaign.

[JRehling]

I'm curious, should the engine problem be unresolved, if the mission will run the same number of perijoves over a longer span of time or a lesser number of perijoves over a mission of the planned duration, or something between the two.

Given a solar panel power supply, it would seem that absolute mission duration would not be the bottleneck, although a longer mission would surely have more costly ground support needs.

[elakdawalla]

Here's a good article from Spaceflight Now that answers some of your questions.

[JRehling]

Thanks for the link, Emily. That's pretty reassuring that Juno should still meet all of its goals.

[elakdawalla]

I was going to make a new thread for PJ3, but I realized how short this "post-PJ1" thread was, so I just changed its title to cover both perijoves.

[Gerald]

Voting for PJ3 targets started. It will last another 5 days. This perijove allows only for a small number of targets to be imaged beyond images of the poles and test imaging. Recently we had an outbreak near the northern tropical belt, one of the regions which might be of interest.
The locations of the features open to be voted on have been extrapolated. They are expected to be within reach for JunoCam during PJ-3.

[MichaelJWP]

Normally an 'interested lurker' here, but just noticed that PJ3 was yesterday but no updates on the forum or the Juno website? Anyone know if the data-gathering was successful?

(On a side note has public interest already dropped off on this mission, hope not!)

- Michael

[Gerald]

New images have been scheduled to be published on Wednesday this week, I guess late in the night UTC.
As far as I can say from a distance, everyone involved is very busy with analysing the PJ1 data, and eagerly awaiting the PJ3 data, and/or performing accompanying ground-based observations.
There is also an AGU conference this week, in parallel.

[Holder of the Tw...]

Here are the plans for P3: LINK

Last update on Twitter was 22 hours ago. Nothing since, either good or bad.

[Gerald]

Goldstone is downlinking data with 119.57 kb/sec:

I'd interpret this as Juno being healthy and having collected lots of data.

[mcaplinger]

Anyone know if the data-gathering was successful?

... has public interest already dropped off on this mission...

We've been steadily getting Junocam data and as of now have maybe 2/3rds of it. I think everyone will be pleased with the more favorable lighting on this pass, and it looks like the tweaks we made to the compression commanding have worked. I'm not sure when this will get pushed out to missionjuno. Normally we would wait for the whole dataset to show up and the DSN schedule has been spotty, for example, we were on the 34m net at Madrid last night and the data rate is low.

On the topic of public interest, obviously nothing new has happened since PJ1 apart from the problems with the propulsion system. All of the media reports I've seen have been supportive and enthusiastic about the mission. This was the first pass for public target voting, which had fairly good participation.

[MichaelJWP]

We've been steadily getting Junocam data and as of now have maybe 2/3rds of it. I think everyone will be pleased with the more favorable lighting on this pass, and it looks like the tweaks we made to the compression commanding have worked. I'm not sure when this will get pushed out to missionjuno. Normally we would wait for the whole dataset to show up and the DSN schedule has been spotty, for example, we were on the 34m net at Madrid last night and the data rate is low.

On the topic of public interest, obviously nothing new has happened since PJ1 apart from the problems with the propulsion system. All of the media reports I've seen have been supportive and enthusiastic about the mission. This was the first pass for public target voting, which had fairly good participation.

Thanks - good news anyway, I certainly don't mind waiting. Looking forward to seeing the new lighting.

[mcaplinger]

PJ3 data posted -- https://www.missionjuno.swri.edu/junocam/processing

[Gerald]

A very first idea of #03C00107:

(image: NASA / JPL / SwRI / MSSS / Gerald Eichstädt)

[Gerald]

Other selected and enhanced Perijove-3 images as a first impression:

[Gerald]

Preliminary PJ3 close-up RGBs, decompanded, color-corrected, square-root encoded.

Those are rendered without trajectory or (non-trivial) shape model. Spacecraft angular velocity just roughly estimated from PJ1 and Marble Movie.

Synopsis:


I'll try to refine this, and see whether I'll be able to create enhanced map products during the next days.

[Gerald]

... this is an ad-hoc attempt of post-processing with consumer image processing software:

(NASA / JPL / SwRI / MSSS / Gerald Eichstädt)

Similar to a few posts above, but trying to enhance color.

[mcaplinger]

The Junocam ring image in processed form is buried on missionjuno in the submissions section: https://www.missionjuno.swri.edu/junocam/processing?id=368 and the raw data is equally buried in https://www.missionjuno.swri.edu/junocam/processing?id=369 Note that the thumbnails are black so you have to click through to the full image.

Doubt if it's worth the anticipation, I was surprised we could see it at all.

[Explorer1]

It's still an impressive first, seeing them from this perspective! Could any of the four inner satellites be resolved if they were in the image at the time, or would they just be points?

[mcaplinger]

Could any of the four inner satellites be resolved if they were in the image at the time, or would they just be points?

I think they'd be resolved, Callisto would be about 4 pixels across if I did the math right. Turns out resolving the moons is not a big deal, we do that on every approach. Seeing useful detail on the moons is another thing.

[Explorer1]

Oops, I should've been more specific, I meant the four irregulars (Amalthea, etc). I know their orbits are a lot closer to Juno's perijove (~100-200 thousand km) but I'm not sure what that means considering their small size! I wouldn't expect anything like the Galileo images, but seeing their Jupiter-facing side (and constraining their orbits a bit) might be useful.

[mcaplinger]

Oops, I should've been more specific...

No, I should have read your post more carefully. I guess Amalthea might be barely resolved at minimum range, but I doubt that such an image would be of any real use.

[JRehling]

Gerald, your work is very nice! Are you sure you didn't take it from a Van Gogh painting?

[Gerald]

Thanks! I felt like diving through the Mandelbrot set.
Beauty without tinitus.

I'm working on resolving some of the glitches in my software, and am confident to be able to provide a lot more of hopefully even better products over the weekend and next week.

[Gerald]

That's an enhanced crop of an intermediate map product derived from PJ3 image #092:

I'm experimenting with raw image #092 to find sw glitches. I had a bug in the calculations of the rotation matrix needed to transform between Jupiter and JunoCam frame for a given instant, which distorted the map away from a proper lon/lat frame. A small error in a fairly complex calculation. But it's sufficient, that you don't get what you intend.
I'm now presuming, that the residual non-flat brightness of my de-lamberted map products can partly be attributed to some mixing of planetocentric and planetographic code. The surface normal for de-Lamberting needs to be calculated planetographically while the map projection is planetocentric.
Of course one could work with the NAIF or ISIS3 libraries, but you learn more by going through all the technical challenges, and at some point you can't go beyond "the standard" without taking the risk to understand and do it yourself.

[Gerald]

This may serve as a small status update.
I'm working on PJ3 map products:

In the meanwhile, I've found and resolved two glitches, but there are still several more issues to be resolved. In this version, longitudes have not yet been aligned.
I'm currently trying to determine Juno's rotation period from the images. My initial estimate of 30.242 seconds didn't fit well. Therefore I've determined the pointing for each images separately for the above animation, which led to a shift of longitudes as a side effect in this approach.
A better preliminary estimate of Juno's rotation period seems to be 30.330 seconds, on the basis of PJ3 images 103 and 104. I'll narrow this further down, before rendering the first set of maps in higher resolution, which will not yet be de-Lamberted. An other issue I've to resolve is a glitch in the rotation matrix for the de-Lamberting model, and a better approximation of the surface normal.

[Gerald]

This gif shows an attempt to fit the images into a mask which simulates a Jupiter spheroid, assuming a constant rotation period of 30.33740 seconds for Juno, and neglecting light travel time:

The rotation period is inferred from PJ3 images 103 and 126. You'll see a black margin at the top or bottom of Jupiter of variable thickness with respect to the ugly turqoise background mask. The most distant images of this sequence are taken from a distance of a little more than 100,000 km. Light takes about 0.3 seconds for this distance. So we get a shift of very roughly 100 pixels in the raw images due to light travel time. This appears to be similar to the observed error. So this will be one of the things which I'll include into my model. If you're using NAIF/SPICE libraries and kernels, this effect should already be considered.

Edit: ...hmm, I'm a bit hesitant, whether General Relativity (equivalence principle) allows for this simplification. May be I'd better adjust the angles manually, and then look which physical model fits.

[fredk]

I'm a bit hesitant whether General Relativity (equivalence principle) allows for this simplification.

Which simplification?

[mcaplinger]

AFAIK, GR effects have never been part of the NAIF toolkit, but stellar aberration is: https://naif.jpl.nasa.gov/pub/naif/toolkit_...ice_spkezr.html
Although I doubt it makes much difference in this case.

Mods: IMHO this technical discussion belongs in some other thread.

[Gerald]

I was just looking for a simple solution to adjust for possible relativistic effects regarding spacecraft rotation. Since Juno's trajectory isn't an inertial system, but accelerated in a Newtonian understanding, we get into GR. I'd think, that this is implicite in SPICE by Ephemeris time (ET) - UT transformations.
I've been considering, that Juno's time-dilated rotation by GR might be equivalent to an offset by light travel time. But discussing this -- as M.Caplinger says -- would be an extra thread.
Since I can't be sure yet, to which degree relativistic effects play a role, and how complicated those considerations might become, I decided to adjust rotational offsets manually in a first step.

Edit: After these adjustments, the fitting looks better:

Maybe worth to create an animation (video) with black background and interpolated frames.

[mcaplinger]

I'd think, that this is [implicit] in SPICE by Ephemeris time (ET) - UT transformations.

I don't think so. If this was the case then all time conversions would require knowledge of position. I think the full extent of SPICE's treatment of GR is in the mapping from ET=TDB to TDT, which applies only to the Earth and is not something I've ever used. See https://naif.jpl.nasa.gov/pub/naif/toolkit_...ound%20Material

I'd guess, without having worked it out, that in the total error budget of spacecraft pointing, GR effects are several orders of magnitude down in the list, at least for spacecraft and targets like the ones we deal with now. In the future, if mission planners are flying relativistic spacecraft to black holes, the SPICE toolkit will have to be enhanced.

[fredk]

Since Juno's trajectory isn't an inertial system, but accelerated in a Newtonian understanding, we get into GR.

Newtonian mechanics can handle acceleration - that's the "a" in F = ma! GR effects are only noticible in rare circumstances, when either the velocities are large (relative to c), the gravitational potential is large (black holes etc), or when the precision is extremely high (Mercury perihelion measurements, GPS, gravity probe B.). I can't imagine that GR will be anywhere close to detectible in junocam. And being in a rotating frame does not imply time dilation.

[Gerald]

Well, in order to solve the question about whether relativistic effects might be relevant or not, I did a short SR calculation assuming velocities up to 1e-4 the speed of light, and got a relative effect of about 6.8e-9, which can't explain the offset, which I resolved only up to about 1e-7.
The effects I'm considering are often assumed to belong to SR, but they are better described by GR, like the twin paradox.

Eventually, the presumed fluctuations of the angular velocity seem to be of a different cause, either some spacecraft operation, which I've considered as less likely during flyby, interaction with Jupiter's environment, which looked also less likely at that height, unconsidered image processing effects, or some inaccuracies in the data, which I also assumed to be considerably smaller.

[fredk]

Taking this thread even farther from Jupiter, the twin paradox is special relativistic. It occurs on flat (Minkowsky) spacetime, which is what defines SR. It would also occur on curved spacetime, but curvature (ie gravity) is not needed.

[Gerald]

By the equivalence principle "acceleration = gravity", for a non-inertial observer a Minkowski space looks curved, and we are in GR, at least in my understanding.
Investigating Jupiter's gravity field extremely accurately is part of the Juno mission. Otherwise I wouldn't have replied once more.
That said, essentially, GR doesn't solve or simplify the labor in my JunoCam processing in the way I had hoped for.

[mcaplinger]

Investigating Jupiter's gravity field extremely accurately is part of the Juno mission.

Some reading on this topic:

https://www.lpl.arizona.edu/~showman/public...i-etal-2010.pdf

No mention of GR. Here's a paper on gravitational lensing by Jupiter:
http://iopscience.iop.org/article/10.1086/378785/meta
or https://arxiv.org/abs/astro-ph/0302294

The radial deflection was 1190 microarcsec = 0.0058 microradians. Lost in the noise for imaging systems.

[Gerald]

For those, who like to use the MSSS version of the PJ3 RGB images, but color-corrected, i.e. with much less color striping artifacts, and adjusted color weights.

====
Re Juno and GR:
There are even people, who think, that measuring the very subtle Lense-Thirring effect, aka frama dragging, might be feasible during the Juno mission:
https://arxiv.org/pdf/1302.6920v5.pdf
https://arxiv.org/pdf/0812.1485v3.pdf

But the effect I've been thinking about, is much more crude: It's the relative effect of velocity to clocks. And I'm keen enough to use Juno's rotation as a clock. Seen from Jupiter (barycenter), we get velocity changes of about +/- 1e-4 c. For a constant angular velocity, even small to tiny time-dilation sums up to a a small angle, which might be detectable by JunoCam. But as I've calcuated above, we are below 1 pixel per perijove. However displacements well below 1 pixel, in some cases down to less than 1e-2 pixels, are feasible for measurements. We are then in the same order of magnitude as relativistic effects. I've attributed these effects to GR, since we aren't in two inertial systems in a flat spacetime regarding Juno and Earth. But reasonable calculations should be possible with means of Special Relativity.
My very first crude presumption without calculations has been, that a velocity of 1e-4 c might result in relativistic effects near 1e-6, but as mentioned above, it's only near 0.5e-8. I was two orders of magnitude off, since the 1e-4 c need to be squared in the calculation for the relativistic effects.
The idea came during pondering about the root cause of an angular offset observed during PJ3 image processing.

Btw.: Regarding SPICE: Probes close to the Sun may experience considerably stronger relativistic effects.

[Gerald]

Crescent Jupiter:
For the PJ3 Approach sequence, I'm currently running a calibration process. This required some software adjustment, since the background seems to be a little brighter than for Marble Movie. Previously this has been hard-coded. Now it's a program parameter. This calibration batch will run a few hours. So I found some time to enhance one of the intermediate images, image #2 of the PJ3 series:

[Ant103]

All I want to tell you Gerald : you are doing an AMAZING work ! I don't understand clearly the process behind (because you know, mathematics and me are not in very good terms…) but I admire you for this, and thanks for being so generous about it

[scalbers]

Regarding GR, in my numerical integration software used for solar system planet orbit calculations, I employ a GR correction. It can be thought of as an "anomalous" acceleration to be applied to the otherwise Newtonian formulation of determining the acceleration of a planet. I suppose this correction can be checked in the Jupiter setting to see if it appears to be significant.

[Gerald]

All I want to tell you Gerald : you are doing an AMAZING work ! I don't understand clearly the process behind (because you know, mathematics and me are not in very good terms…) but I admire you for this, and thanks for being so generous about it

Thanks a lot Damia! That's particularly precious, when those words come from one of the world's leading image processing experts.

@scalbers: Fully nailing this down for Juno's extremely elliptical orbit would be really great! Might be, you could even determine the accurate relativistic effects on clocks travelling with Juno. I guess, that only +/- a few hours around perijoves need to be considered, where we get high velocities, and a tiny gravitational red shift.

[scalbers]

Gerald - here is the correction term for the orbital acceleration as it appears in my vintage (1970s) software. I'm unsure how easy it would be to retool this to run for Jupiter, though we could at least do some type of scale analysis on this, or augment another simulation program accordingly. The RDRD or r dot rdot term is sensitive to how elliptical the orbit is as one might expect.

! ADD PERTURBATIVE ACCELERATION DUE TO GENERAL RELATIVITY
RDRD=X(I)*XD(I)+Y(I)*YD(I)+Z(I)*ZD(I)
VSQ=XD(I)*XD(I)+YD(I)*YD(I)+ZD(I)*ZD(I)
A=FOURM*RLCM1-VSQ*CM2
B=FOURM*RDRD*RLCM3
XDD(I)=XDD(I)*(1.D0-A)+B*XD(I)
YDD(I)=YDD(I)*(1.D0-A)+B*YD(I)
ZDD(I)=ZDD(I)*(1.D0-A)+B*ZD(I)

The terms are defined as follows:

RDRD - r dot rdot - dot product of position and velocity
XYZ - position vector in AU
XD,YD,ZD - velocity vector
XDD,YDD,ZDD - acceleration vector
FOURM - 4 times the mass of the central object
RLCM1 - inverse distance between the two bodies
CM2 - 1 / c squared (c = speed of light)

I should try and look up the Cowell Astronomical Papers reference where I obtained this. The above just applies to calculating the GR perturbed positions. The clock changes are a different calculation.

[Gerald]

This is an animated gif of preliminarily processed PJ3 approach images:

The last 10 or so frames have been too large to be properly aligned by centering.

Here the stills, and a respective version showing more context.

---

S.C.Albers:
I guess, 'I' is an index in a loop (iteration?). Not quite sure about the meaning of '1.D0', I guess simply 1.0 in some progamming language. Besides this, it looks fairly easy to implement. Thanks!
Transforming SPICE trajectories to this algorithm should be well-feasible, too, with position vectors relative to Jupiter.

[mcaplinger]

Not quite sure about the meaning of '1.D0'

Double-precision floating-point constant.
Once upon a time there was a language called FORTRAN and all serious scientific programming was done in it...
similar syntax is used in languages like IDL.

[Gerald]

I see. Then the 'I' is likely used as an array index to overcome the lack of function scopes for (local) variables.
Not needed anymore in modern computer languages.

[eliBonora]

Here a couple of PJ3 processing and a test anaglyph

[Gerald]

Here a synopis of the PJ03 Approach Movie images:

This version is reduced in size, brightness-stretched in a linear way, and saturation-enhanced.
I've submitted a less processed, larger version, to the missionjuno site to allow others post-processing according to their own requirements.

[mcaplinger]

BTW, if people don't know about the work of John Rogers of the British Astronomical Association's Jupiter section, you can find it at https://www.britastro.org/node/7982 (some also posted on missionjuno but I prefer to go straight to the source.)

Refreshing change from all this processing discussion!

[fredk]

Once upon a time there was a language called FORTRAN and all serious scientific programming was done in it...

That's one dinosaur that still walks this earth, at least in cosmology and GR work. Gained a few lovely feathers over the years...

[scalbers]

Also still used quite a bit in numerical weather prediction. It's more modernized now in various respects - though even if it changes it's still called FORTRAN. So it carries on beyond the age of the dinosaurs, kind of like birds...

For Gerald - indeed FORTRAN can be pretty readily translated into IDL. The "I" index is representing one time step as part of a time series. We'd also have to check that the physical units of mass are consistent with however distance and time units are being specified. Maybe pure SI units would work OK.

[Gerald]

BTW, if people don't know about the work of John Rogers of the British Astronomical Association's Jupiter section, ...

John Rogers just published the PDF version of the (first) PJ03 report.
The PJ03 images will undergo further analysis over the next weeks.

---

S.C.Albers: Thanks for resolving the remaining question.
Yes, since FORTRAN-77, there have been further extensions in FORTRAN-90. There exists such a large number of programming languages, that at some point I discontinued attempts to track all those trends and paradigm changes. Eventually it's hard to infer the language from a small excerpt of source code. The same sequence of characters can be interpreted entirely different in the context of different languages, sometimes even within the same language. This includes own "proprietary" languages or language extensions... That's endless... Even "IDL" is overloaded (Interactive Data Language vs. Interface Definition Language). But I know, which IDL is meant in this context.

[Gerald]

PJ03 departure movie, RGB images, decompanded, linearly brightess-stretched by factor 2, square-root encoded, reduced to 15 pixels per (cylindrical) camera degree:

[Gerald]

PJ03 Departure and Marble Movie, browsable RGB images #131 to #588, 30 pixels per camera degree (images in overview are 5x reduced, and hyperlinks to 30 pixels version).

[Gerald]

Methane band PJ03 Departure Movie images (reduced, jpg):


The browsable 30 pixels/cylindrical camera degree versions of the methane images of the PJ03 Departure and Marble Movie sequence.

[Gerald]

... And an example of a false-color image using the CH4 channel for brightness, and RGB for hue / saturation:

Saturation is enhanced.

[Gerald]

One of four slightly different preliminary PJ03 animations I've provided on youtube.
They cover approach, close-up, departure and marble movie phase.

[Roman Tkachenko]

Crescent Jupiter with Great Red Spot

[Gerald]

Jupiter's vortices at and near the south pole, animated from reprojected and heavily enhanced PJ03 close-ups and departure images:

(NASA/JPL/SwRI/MSSS/Gerald Eichstädt)
800-pixel version submitted to missionjuno.

I'd presume, that this should be the first such animation of Jupiter's south polar region.

The animation shows haze features in the south polar region, too, mostly close to the terminator.

[PhilipTerryGraha...]

Another lucky person has made it into the NASA Photojournal, I've noticed!

[Roman Tkachenko]

Jupiter's South Pole (PJ-3)

[wildespace]

PIA21378 - http://photojournal.jpl.nasa.gov/catalog/PIA21378 - with some additional image processing from me, to realign colour channels and clean up the image artifacts.



Full-sized version: http://imgur.com/3LVItz7

In one word - swirly!

[Gerald]

Despite Juno's safe mode around PJ02, JunoCam was able to add some information regarding the 2016 NTB outbreak. The according paper is online now. Solar conjunction made observations from Earth difficult. So, even the small "Marble Movie" images taken several days before PJ02 have been able to add value, especially regarding the configuration of the plumes early after the outbreak.

[Gerald]

Synopsis of Perijove-03 subset:


Larger subset of larger versions.

For illumniation adjustment, I've divided the decompanded colors by a polynomial of degree 5 of the cosines of the solar incidence and emission angle, resulting in a sum of 21 items. The polynomial is a manually slightly modified relative best-fit within a range of cosines of the two mentioned angles that avoids proximity to limb and terminator. The best-fit is based on a set of about one million Monte-Carlo samples taken from all TDI-2 Perijove-06 images without moon shadows. For this sequence, I've used the polyomial of the green filter for all three color bands, hence didn't apply illumination-dependent white-balancing. I modified the best fit in order to get some shading instead of a flat appearence, and in order to avoid a non-intuitive bright terminator.
The PJ-03 images have been a test, whether the same polynomial can be applied globally for any perijove and image.
The ad-hoc heuristics I've used before for PJ-06 and PJ-07 is less suitable for PJ-03 due to the proximity of the terminator for the very close-ups.

These images aren't yet submitted to missionjuno. I may submit the fully resolved version of the synopsis, but I'll wait with the individual images, until a decision is made of whether a separate section will be defined on the site, for this kind of products.

I'll try to revise PJ-04 and PJ-05 in a similar way, before raw PJ-08 images will be available via missionjuno.

[Gerald]

Last night, I've rendered three more versions of PJ-03 reprojections with slightly varying shading:
- Almost flat,
- shading with gamma = 0.5 applied to illumination model, and
- shading with illumniation model.

The underlying illumination model is refined a bit in order to get more uniform results near the limb and terminator.

Selected images are submitted to missionjuno.

During upload, I encountered error messages that behaved a bit like conflicting hash keys in an almost full hash table. The same upload failed reproducibly, but changing file names or titles somtimes avoided the error:

Uh oh, we ran into some errors.
ERROR (clam2) : Sorry - something went wrong with the upload process.

I hope, that I'll be able to upload PJ-09 renditions this week. If not, I'm intending to post them here in the PJ-09 thread any case.

[Gerald]

The upload issue appears to be fixed. Great job! Thanks to the professionals in the JunoCam team, and to RadicalMedia!

[Gerald]

Perijove-03 flyby movie is on Youtube, and on junocam.pictures webspace, including stills.

[Sean]

Wow...the south pole is looking really good.

[Sean]

PJ03_114 [G.Eichstadt]

Details

[Sean]

PJ03_107 [G.Eichstadt]


Details

[Sean]

PJ03_117 [G.Eichstadt]





Details

[Sean]

PJ03_118 [G.Eichstadt]




Details






More comps over on the Perijove 03 Flickr album

[Gerald]

The anticyclone in PJ-03, #107, is called NN-LRS-1, North-North-Little Red Spot-1, see post #73. It was imaged again during Perijove-07, the perijove with the close-up images of the Great Red Spot.

[Sean]

PJ03_117 update + detail [G.Eichstadt]

[Sean]

New detail pass on PJ03_114 [G.Eichstadt]

[Sean]

PJ03_120 updated + details [G.Eichstadt]

[Sean]

PJ03_120_v3 Yet another pass + details...

[Sean]

Yet another pass at PJ03_120...

[Floyd]

Seem hard to imagine you improving on your previous versions---but you have. I like the subtle change in the color palette. Blues and oranges nicely saturated, but white terminator and other whites have more punch. Thanks for all the creativity you share.

[Sean]

Thanks Floyd... the truth is for a couple of perijoves I was making images on a laptop with a terrible screen and a very messed up color profile - what I made on screen is not what people saw on their browser. I always wanted to revisit these older shots with a calibrated color space in tow.

[Bjorn Jonsson]

I recently decided to take a look at data from the early perijoves when my JunoCam processing pipeline didn't work as well as it does now (or not at all ;-). In fact it's striking to see the big improvement in image quality from everyone here processing JunoCam images when early images from e.g. PJ3 are compared to the recent ones. For example I processed a few PJ4 and PJ5 images when they were released but now I want to reprocess them. But first I decided to process something I haven't processed earlier: PJ3 images.

This is image PJ3_114 which shows the SEB west of the Great Red Spot.

Approximately true color/contrast:



Enhanced versions:




Lots of cloud shadows and vertical relief are visible, especially in the 'central' image (the one where the limb isn't visible). The solar elevation angle is low in these images - in the early perijoves, closest approach occurred much closer to the terminator than later in the mission (at the time of this writing perijove 20 is the most recent perijove). The color coded image below shows the solar elevation angle in one of the above images. In contrast, the subsolar point is visible in some of the PJ20 images.



Below are details from the first true color/contrast image above enlarged by a factor of 3. The image shows Jupiter's horizon near the evening terminator. Jupiter's bright and blue evening sky is clearly visible at the limb. In the right half of the image there are also possible hints of a slightly more reddish color at lower altitudes than the blue color. This is probably a real feature although a processing artifact cannot be completely ruled out. I have processed a number of JunoCam images where Jupiter's sky is visible at the limb. Of these images, this is probably the one that best shows the Jovian sky.

[adamg]

Contents of pds-imaging.jpl.nasa.gov/data/juno/JNOJNC_0002

Attached thumbnail(s)

 

[adamg]

first elements in pds-imaging.jpl.nasa.gov/data/juno/JNOJNC_0003 ... ORBIT_03 distances (*1e6)

Distance
JNCR_2016345_03C00002_V01 1.4749159628193276
JNCR_2016345_03C00004_V01 1.4542690337823034
JNCR_2016345_03C00006_V01 1.433096928709612
JNCR_2016345_03C00008_V01 1.4120987115862533
JNCR_2016345_03C00010_V01 1.3909172905039227
JNCR_2016345_03C00012_V01 1.3691855981815069
JNCR_2016345_03C00014_V01 1.347621178250636
JNCR_2016345_03C00016_V01 1.3258587513481361
JNCR_2016345_03C00018_V01 1.3035162684580093
JNCR_2016345_03C00020_V01 1.281332622460322
JNCR_2016345_03C00022_V01 1.258932568679058
JNCR_2016345_03C00024_V01 1.2359197889265243
JNCR_2016345_03C00026_V01 1.213055075385369
JNCR_2016345_03C00028_V01 1.1899475527741066
JNCR_2016345_03M00003_V01 1.474567901189406
JNCR_2016345_03M00005_V01 1.4539189089308011
JNCR_2016345_03M00007_V01 1.4327428910711637
JNCR_2016345_03M00009_V01 1.411741356989429
JNCR_2016345_03M00011_V01 1.3905564343494536
JNCR_2016345_03M00013_V01 1.3688215557054952
JNCR_2016345_03M00015_V01 1.3472543814410143
JNCR_2016345_03M00017_V01 1.3254885364143894
JNCR_2016345_03M00019_V01 1.303143190126758
JNCR_2016345_03M00021_V01 1.2809550341508031
JNCR_2016345_03M00023_V01 1.2585506280431125
JNCR_2016345_03M00025_V01 1.2355339342131775
JNCR_2016345_03M00027_V01 1.2126652365486847
JNCR_2016345_03M00029_V01 1.189553484512732
JNCR_2016346_03C00030_V01 1.1661912642390564
JNCR_2016346_03C00032_V01 1.142569958698268
JNCR_2016346_03C00034_V01 1.1186770336070144
JNCR_2016346_03C00036_V01 1.0940900489924803
JNCR_2016346_03C00038_V01 1.0696176680119247
JNCR_2016346_03C00040_V01 1.0448411858717241
JNCR_2016346_03C00042_V01 1.0193164498691287
JNCR_2016346_03C00044_V01 0.9938807940272427
JNCR_2016346_03C00046_V01 0.9680960300454893
JNCR_2016346_03C00048_V01 0.9414980153906513
JNCR_2016346_03C00050_V01 0.914954042991846
JNCR_2016346_03C00052_V01 0.8880069755317854
JNCR_2016346_03C00054_V01 0.8601663083791415
JNCR_2016346_03C00056_V01 0.8323272173692047
JNCR_2016346_03C00058_V01 0.8040060556871191
JNCR_2016346_03C00060_V01 0.7746816622971828
JNCR_2016346_03C00062_V01 0.7452942366063703
JNCR_2016346_03C00064_V01 0.7153205627158753
JNCR_2016346_03C00066_V01 0.6841949702467771
JNCR_2016346_03C00068_V01 0.6529050339205971
JNCR_2016346_03C00070_V01 0.6208765966200915
JNCR_2016346_03C00072_V01 0.5874879058629068
JNCR_2016346_03C00074_V01 0.5537655188369682
JNCR_2016346_03C00076_V01 0.5184797286441235
JNCR_2016346_03C00078_V01 0.4826962078365891
JNCR_2016346_03C00080_V01 0.44571389822537527
JNCR_2016346_03C00082_V01 0.4066968543196093
JNCR_2016346_03C00084_V01 0.36676121751055313
JNCR_2016346_03C00086_V01 0.32502963200448337
JNCR_2016346_03C00088_V01 0.28046415051659923
JNCR_2016346_03C00090_V01 0.23421622415802842
JNCR_2016346_03C00092_V01 0.18534662412401262
JNCR_2016346_03C00094_V01 0.16306171187805069
JNCR_2016346_03C00099_V01 0.13625314711450223
JNCR_2016346_03C00101_V01 0.11756522363165459
JNCR_2016346_03C00103_V01 0.1126320048233185
JNCR_2016346_03C00104_V01 0.1078072608199902
JNCR_2016346_03C00105_V01 0.10159556219787719
JNCR_2016346_03C00107_V01 0.08554410309594325
JNCR_2016346_03C00109_V01 0.07728393319740363
JNCR_2016346_03C00110_V01 0.07611334234562364
JNCR_2016346_03C00111_V01 0.07562709329795922
JNCR_2016346_03C00113_V01 0.07677904939741823
JNCR_2016346_03C00114_V01 0.07977995034288528
JNCR_2016346_03C00116_V01 0.08775202559754502
JNCR_2016346_03C00117_V01 0.09353508642276395
JNCR_2016346_03C00118_V01 0.10532699656020048
JNCR_2016346_03C00120_V01 0.11333557087096598
JNCR_2016346_03C00121_V01 0.11996486070527151
JNCR_2016346_03C00122_V01 0.13701459737163593
JNCR_2016346_03C00124_V01 0.15433758744021367
JNCR_2016346_03C00126_V01 0.16557303244056495
JNCR_2016346_03C00131_V01 0.19796182500155401
JNCR_2016346_03C00133_V01 0.24697405149025134
JNCR_2016346_03C00135_V01 0.2547492157259101
JNCR_2016346_03C00136_V01 0.2925490269964357
JNCR_2016346_03C00138_V01 0.33580497605848353
JNCR_2016346_03C00140_V01 0.37773203892274115
JNCR_2016346_03C00142_V01 0.4172199339771325
JNCR_2016346_03C00144_V01 0.4552089060272889
JNCR_2016346_03C00146_V01 0.4924935369415306
JNCR_2016346_03C00148_V01 0.5279726846401707
JNCR_2016346_03C00150_V01 0.56240278244829
JNCR_2016346_03M00031_V01 1.165794069594665
JNCR_2016346_03M00033_V01 1.1421667216261628
JNCR_2016346_03M00035_V01 1.1182692205285651
JNCR_2016346_03M00037_V01 1.0936774416414148
JNCR_2016346_03M00039_V01 1.0692007386974487
JNCR_2016346_03M00041_V01 1.044418319134217
JNCR_2016346_03M00043_V01 1.0188886196330889
JNCR_2016346_03M00045_V01 0.9934465113259777
JNCR_2016346_03M00047_V01 0.9676556780735772
JNCR_2016346_03M00049_V01 0.9410517549823207
JNCR_2016346_03M00051_V01 0.9145027155910714
JNCR_2016346_03M00053_V01 0.8875444582811646
JNCR_2016346_03M00055_V01 0.8596980850406111
JNCR_2016346_03M00057_V01 0.8318513144736257
JNCR_2016346_03M00059_V01 0.8035229258727051
JNCR_2016346_03M00061_V01 0.7741886760422414
JNCR_2016346_03M00063_V01 0.7447903792979518
JNCR_2016346_03M00065_V01 0.7148085930618021
JNCR_2016346_03M00067_V01 0.6836718404508733
JNCR_2016346_03M00069_V01 0.6523666453799356
JNCR_2016346_03M00071_V01 0.6203286938241885
JNCR_2016346_03M00073_V01 0.5869229741636646
JNCR_2016346_03M00075_V01 0.5531871673635312
JNCR_2016346_03M00077_V01 0.5178840441364595
JNCR_2016346_03M00079_V01 0.48207959175043824
JNCR_2016346_03M00081_V01 0.4450741692733699
JNCR_2016346_03M00083_V01 0.4060335919027028
JNCR_2016346_03M00085_V01 0.3660687365228705
JNCR_2016346_03M00087_V01 0.3243076858206185
JNCR_2016346_03M00089_V01 0.27893943183466036
JNCR_2016346_03M00091_V01 0.23260218791056403
JNCR_2016346_03M00093_V01 0.18364601984059728
JNCR_2016346_03M00095_V01 0.16133280775431164
JNCR_2016346_03M00100_V01 0.13453254658555008
JNCR_2016346_03M00102_V01 0.11590680065317674
JNCR_2016346_03M00106_V01 0.09934668091407667
JNCR_2016346_03M00108_V01 0.08393500196766686
JNCR_2016346_03M00115_V01 0.08100107411841447
JNCR_2016346_03M00119_V01 0.10768535645858862
JNCR_2016346_03M00123_V01 0.13873822972177044
JNCR_2016346_03M00125_V01 0.15606896605801074
JNCR_2016346_03M00127_V01 0.16729564335748212
JNCR_2016346_03M00132_V01 0.19964066999198055
JNCR_2016346_03M00134_V01 0.2485585937247511
JNCR_2016346_03M00137_V01 0.29405202377776174
JNCR_2016346_03M00139_V01 0.33652083987186676
JNCR_2016346_03M00141_V01 0.378414848080696
JNCR_2016346_03M00143_V01 0.4178767405847803
JNCR_2016346_03M00145_V01 0.4558409140118276
JNCR_2016346_03M00147_V01 0.4931068685535241
JNCR_2016346_03M00149_V01 0.5285654844800145
JNCR_2016346_03M00151_V01 0.5629791194301715
JNCR_2016346_03R00096_V01 0.14748613797475552
JNCR_2016346_03R00097_V01 0.1440213925262166
JNCR_2016346_03R00098_V01 0.14056038511346425
JNCR_2016346_03R00112_V01 0.07578346112862916
JNCR_2016346_03R00128_V01 0.16902926300647367
JNCR_2016346_03R00129_V01 0.1724656342471787
JNCR_2016346_03R00130_V01 0.1758954209927151
JNCR_2016347_03C00152_V01 0.7824134559147339
JNCR_2016347_03C00154_V01 0.8112195631929505
JNCR_2016347_03C00156_V01 0.8395178236038593
JNCR_2016347_03C00158_V01 0.8673390402986039
JNCR_2016347_03C00160_V01 0.8947094872451112
JNCR_2016347_03C00162_V01 0.9216551000589288
JNCR_2016347_03C00164_V01 0.9486419853843271
JNCR_2016347_03C00166_V01 0.9747931491747635
JNCR_2016347_03C00168_V01 1.0005793398456964
JNCR_2016347_03C00170_V01 1.026018510050173
JNCR_2016347_03C00172_V01 1.051124551096523
JNCR_2016347_03C00174_V01 1.0759141472704186
JNCR_2016347_03C00176_V01 1.1003973985817903
JNCR_2016347_03C00178_V01 1.1245910718049865
JNCR_2016347_03C00180_V01 1.1485020228105907
JNCR_2016347_03C00182_V01 1.1725436487611736
JNCR_2016347_03C00184_V01 1.1959205608674668
JNCR_2016347_03C00186_V01 1.219047583471167
JNCR_2016347_03C00188_V01 1.2419344515592095
JNCR_2016347_03C00190_V01 1.2645863578144523
JNCR_2016347_03C00192_V01 1.2870143376319843
JNCR_2016347_03C00194_V01 1.3092217379324087
JNCR_2016347_03C00196_V01 1.3312199262013584
JNCR_2016347_03C00198_V01 1.353010762400183
JNCR_2016347_03C00200_V01 1.3749692819343315
JNCR_2016347_03C00202_V01 1.3963669459657848
JNCR_2016347_03C00204_V01 1.417575972784607
JNCR_2016347_03C00206_V01 1.4386028647847846
JNCR_2016347_03C00208_V01 1.459453462158997
JNCR_2016347_03C00210_V01 1.4801315455961337
JNCR_2016347_03C00212_V01 1.5006421242940555
JNCR_2016347_03C00214_V01 1.5209890132147317
JNCR_2016347_03C00216_V01 1.5411761095253764
JNCR_2016347_03C00218_V01 1.5615450962412931
JNCR_2016347_03C00220_V01 1.5814223988183262

Attached thumbnail(s)

 

[adamg]

JNCE_2016287_02C10029_V01 and JNCE_2016346_03C00111_V01

Feel like I should be cross correlating the framelets to line them up better.

Attached thumbnail(s)

 

[Brian Swift]

Feel like I should be cross correlating the framelets to line them up better.

They look pretty good to me. Shouldn't need to cross correlate within a single single image.

[adamg]

The top edge of the second image looks a little bit off, it makes me think there's some close in phase noise. I feel like just a bit of offset makes the image less clear.

[Bjorn Jonsson]

There is also clearly some misalignment far from the limb that can be seen by 'blinking' the red/green/blue channels rapidly in high contrast areas. The misalignment should be smaller. One important issue is that the x (sample) of the optical axis is *not* at the center (i.e. x=824) in the framelets. Depending on how you are creating these images this may be of importance but I'm not sure it's enough to cause all of the misalignment (in particular not the misalignment near the center of your images).

[Brian Swift]

... 'blinking' the red/green/blue channels rapidly in high contrast areas.

Doh. I should have already been doing this. I've just been looking at bue/red fringing in high contrast areas.

Björn, are you using the standard camera model, or have you developed your own?

[Bjorn Jonsson]

Björn, are you using the standard camera model, or have you developed your own?

This depends on how you define "...using the standard camera model" . I'm using software written by myself for the geometric processing (reprojecting the framelets to a simple cylindrical and/or polar map etc.). However, some of the code is directly based on information/code from the IK kernel, in particular the distort/undistort code, the location of R/G/B on the CCD, the FOV etc.. I'm also using the SPICE toolkit. Works wonderfully now, especially after lots of improvements I did in November and December 2019 (what was supposed to be a minor improvement in early November triggered a flood of new ideas for improving the software, resulting in faster processing, improved/proper flatfielding, a new (?) function for removing limb darkening, better photometric parameters, an empirical model of the skylight illumination near the terminator, easier limb fits etc.).

The only issue I'm working on now is the value I need to add to START_TIME. Using a fairly large sample of images it has become absolutely clear that in my case the average value I need to use is lower than the correct value (0.068). The average value I use is close to 0.040 but it varies and is sometimes close to 0.068. This means that something is wrong. This has no visual effect though and is in that sense not a serious problem (in particular there is negligible misalignment between the R/G/B channels or adjacent framelets from the same color channel). I can think of at least three plausible reasons for this (in fact all of them might contribute to the error) and now that I'm almost finished with the PJ24 images (at least for the time being) I plan on taking a detailed look at this issue.

[Brian Swift]

... some of the code is directly based on information/code from the IK kernel, in particular the distort/undistort code,

That is what I was I was referring to. I and (I believe) Gerrald have our own distort/undistort code, Kevin (I believe) is using the standard code via ISIS,
but I didn't know if you had your own or used the standard code.

... in faster processing, improved/proper flatfielding, a new (?) function for removing limb darkening, better photometric parameters, an empirical model of the skylight illumination near the terminator, easier limb fits etc.).

Awesome. Wish I had time to do a proper illumination removal model. When you combine multiple images, is there residual brightness variation that needs to be adjusted to eliminate
boundaries between images?

The only issue I'm working on now is the value I need to add to START_TIME. Using a fairly large sample of images it has become absolutely clear that in my case the average value I need to use is lower than the correct value (0.068). The average value I use is close to 0.040 but it varies and is sometimes close to 0.068.

Note, the START_TIME_BIAS in juno_junocam_v03.ti is 0.06188 not .0688.
My start times (based on limb fit) range from .03 to .08

[Gerald]

That is what I was I was referring to. I and (I believe) Gerrald have our own distort/undistort code...

Yes, so it is. I've implemented almost everything from scratch down to pixel operations in RAM or basic 3D libraries. The only essential thing I didn't implement for JunoCam images is the determination of the s/c trajectory from images. Instead, I'm using the NAIF/SPICE spy.exe utility to save trajectory data to text files. And for movie productions or image file conversions I'm usually making use of ffmpeg. (I've worked on reading some of the image file formats professionally on a binary level for long enough, so that stuff is less interesting from my point of view.)

[Spoiler alert: Don't follow the links below, if you are ambitious to find your own solutions independently.]
During EPCS2018, I explained one of several possible approaches of in-flight geometrical camera calibration on the basis of Marbe Movie images:
PDF version
PPT version (with animations)
In contrast to some of the JunoCam IK documentation, I'm working with the CCD pixel layout. One advantage is the easy adjustment to the changing position of the readout region for the methane band images by 90 pixels. But otherwise, the more recent IKs (instrument kernels) are looking good.

My assumptions about camera pointing are imperfect, and I'm doing some manual limb fitting of each image. But any significant reduction of manual work would only be achieved, if automated pointing data would be better than manual adjustment is able to do. So, further refinement of automated pointing currently isn't my top priority.

And here links to an EPSC2017 talk about polynomial illumination adjustment over the cosines of the incidence and the emission angle:
PDF version
PPT version
There is still some space for further improvements. I might prepare such a solution for EPSC2020, if time allows. Note also, that Jupiter's appearance is changing, and so are best-fit illumination models. But my current focus is on understanding the dynamics of the atmosphere. I presume, that this will also be required for an accurate understanding of light scattering and according models. So, there is significant effort in software development and test runs, and less time for discussions. Some of the results may be worth to be released in formal journal papers, the preparation of which is taking time, too. As usual, I'm interested in in-depth understanding of all theoretical, methodological and technical detail as seamlessly as possible. And learning means inventing, or re-inventing, if partial solutions do already exist.

Regarding the limb fit: Note, that the opacity of the hazes, and so the apparent limb, is varying with latitude. This applies to Jupiter's equipotential wrt to a spheroid, too. (AFAIK, full detail of the latter isn't publicly accessible, yet.)

[Bjorn Jonsson]

... in faster processing, improved/proper flatfielding, a new (?) function for removing limb darkening, better photometric parameters, an empirical model of the skylight illumination near the terminator, easier limb fits etc.).

Awesome. Wish I had time to do a proper illumination removal model. When you combine multiple images, is there residual brightness variation that needs to be adjusted to eliminate boundaries between images?

Yes, there are always some differences and I don't think they can ever be eliminated. The reason is that the photometric parameters differ a bit for different parts of Jupiter (in particular I'm pretty sure that the parameters for the polar areas differ from the parameters closer to the equator) and they also vary as a function of time (changes in color/brightness/haze etc.), in other words: There's no such thing as a 'perfect' photometric model for Jupiter. For simplification purposes I'm using the same parameters everywhere.

That said, the differences at the boundaries between images are much smaller now than they used to be when mosaicking images. Of course the intensity differences are smaller but what's maybe even more important is that there are now no significant color differences at the seams (unless there are significant differences in the emission angle).

These smaller differences are not only because of more accurate photometric parameters when removing the illumination effects. I recently discovered that proper and accurate flat fielding is much more important when processing JunoCam images than I used to think. There is some vignetting in the raw images. The effects of flat fielding are not very noticeable in images with lots of high frequency, high contrast features but they are more noticeable in low contrast areas. Here is an image where the effects of flat fielding are particularly noticeable, an animated GIF example from image PJ14_26 (here the illumination has not been changed):



Needless to say the flat fielded images with illumination removed are easier to deal with when making mosaics. The flat fielding also greatly reduces the horizontal banding seen in some images, especially in the blue channel in hi-res images of low contrast areas. This is an example from the blue channel in image PJ10_28 without flat fielding. The contrast has been increased a lot:



The individual framelets are too dark at the top and too bright at the bottom. Flat fielding greatly reduces this banding but does not completely eliminate it.

The absence of an 'official' JunoCam flat field turned out to be a smaller problem than I was initially expecting. As a starting point I found a flat field image in this post from Mike. Using this image directly didn't work well (I tried all decompanded and not decompanded combinations to be sure). I had to make significant modifications to it in order for it to work well. This was largely a trial and error process involving mosaics where the difference in emission angle is small in the overlap area, checking images where I knew that the brightness near the right edge shouldn't be lower than near the center and also by checking for the horizontal banding mentioned above. I ended up with a flat field that seems to work very well but I'll probably make further modifications to it later - importantly I really have no idea exactly how close it is to a 'perfect' flat field. This is the flat field I'm currrently using:



Apart from other changes, high frequency artifacts, blemishes etc. have been removed since I prefer to fix these in a separate processing step and not as part of the flat fielding.

Has anyone else been flat fielding the JunoCam images and if so, how?

Note, the START_TIME_BIAS in juno_junocam_v03.ti is 0.06188 not .0688.
My start times (based on limb fit) range from .03 to .08

Oops, I didn't look up the correct value before writing the incorrect value 0.068 but it doesn't change the fact that the ~0.040 value I mentioned is suspiciously low. The range I have seen (also from limb fits) is slightly bigger, ~0.005 to ~0.085.

My assumptions about camera pointing are imperfect, and I'm doing some manual limb fitting of each image.
...
Regarding the limb fit: Note, that the opacity of the hazes, and so the apparent limb, is varying with latitude. This applies to Jupiter's equipotential wrt to a spheroid, too. (AFAIK, full detail of the latter isn't publicly accessible, yet.)

I'm also measuring the limb position in every image I process - I've sometimes had the impression that this was rare. I then feed the measured limb positions into software that gives me the START_TIME and interframe delay that are consistent with the measured limb positions. Hazes, variable cloud altitudes etc. greatly complicate this though. Also the appearance of the limb in the blue images is significantly different from the red (and also green) images and this affects the limb position measurements. Maybe I should measure the limb positions from red images only.

[Brian Swift]

Has anyone else been flat fielding the JunoCam images and if so, how?

My flat fields (gains) were derived from average of 150 bright framelets (30 from each of PJ12 to PJ16)
which are smoothed by fitting with a 10th order polynomial. Dark spots in average are merged into
the polynomial based flat.

I've uploaded to GitHub depot the gain, flat (not used), and debias images as 32-bit tiff. https://github.com/BrianSwift/JunoCam/tree/master/Juno3D

An animated gif showing effect of flat field on PJ10_28 blue channel

... I then feed the measured limb positions into software that gives me the START_TIME and interframe delay that are consistent with the measured limb positions.

I only use limb fits to adjust START_TIME. Centering the SPICE limb within the visible limb using average of time offset computed independently for R,G,B.
I assume variance in altitude of visible limb is due to real atmospheric variation relative to the SPICE ellipsoid.
I'm unaware of any physical justification for varying interframe delay.

[Brian Swift]

And here links to an EPSC2017 talk about polynomial illumination adjustment over the cosines of the incidence and the emission angle:

What you discuss in the slides is what I've though about implementing. Though I want the BRDF to extend into the night side past the SPICE terminator,
and to also use data from multiple perijoves.
I also have a concern about the effects of the internal camera light scattering (which I know you've investigated) on the illumination model.

Regarding the limb fit: Note, that the opacity of the hazes, and so the apparent limb, is varying with latitude. This applies to Jupiter's equipotential wrt to a spheroid, too. (AFAIK, full detail of the latter isn't publicly accessible, yet.)

I wonder if there will be any public update to gravity field parameters before the mission concludes.
https://ssd.jpl.nasa.gov/?gravity_fields_op shows 2013 being the last update.

[Gerald]

I wonder if there will be any public update to gravity field parameters before the mission concludes.
https://ssd.jpl.nasa.gov/?gravity_fields_op shows 2013 being the last update.

Considerably improved data have already been published, e.g. 2018 in Nature, "Measurement of Jupiter’s asymmetric gravity field", by Iess & al (paywalled).
Measurements are ongoing. So, I'd presume, that there will be updates released publicly in due time.

Regarding the illumination model: I've also run versions with other PJs than PJ06, or over more than one PJ. PJ06 worked pretty well for several PJs, but for the more recent PJs with very different observational conditions, I've determined some new models. I'm also intending to derive a model suitable for all PJs. But there will be limitations, since Jupiter itself is changing, and its atmospheric properties vary with the location you are looking at. Behind the terminator, it's even worse, since there may or may not be light scattering high-altitude hazes. Hence a perfect illumination model may not exist.
Note also, that higher-order polynomials tend to oscillate and won't improve the results. So, it might be worth to investigate several more families of functions. I've done so to some degree, but didn't make each investigation public. I hope that I'll be able to resume a deeper analysis later this year. I share your concerns about flat fields and various kinds of camera artifacts. All those effects need to be considered and discussed in a paper with a certain science value, especially since we then go beyond the camera design requirements.

[Bjorn Jonsson]

I only use limb fits to adjust START_TIME. Centering the SPICE limb within the visible limb using average of time offset computed independently for R,G,B.
I assume variance in altitude of visible limb is due to real atmospheric variation relative to the SPICE ellipsoid.
I'm unaware of any physical justification for varying interframe delay.

The problem with only adjusting the START_TIME is that then you need to either adjust the Jovian ellipsoid dimensions or the interframe delay. Otherwise you'll probably end up with a small error at the 'lower' limb - therefore I use limb fits at both the 'upper' and 'lower' limb. There probably really isn't any physical justification for adjusting the interframe delay using a significantly lower or higher value than 1 ms. Using e.g. 1.1 ms is probably OK but to me e.g. 0.7 or 1.3 ms is suspicious. I nevertheless often use values as low as ~0.7 or as high as ~1.3 ms (occasionally even lower/higher), mainly as a quick and dirty way to make the position of the 'lower' limb consistent with the position of the 'upper' limb without adjusting the ellipsoid dimensions which is more complicated and might also be incorrect because different cloud deck (or haze) altitudes might be a part of the problem. That said, I suspect the deviations are too big to be caused entirely by cloud/haze variability.

I've uploaded to GitHub depot the gain, flat (not used), and debias images as 32-bit tiff.

Thanks - really interesting. For comparison I'll upload a bias file constructed from PJ8 images in a day or two. It's similar but some of the vertical lines are fainter (or missing) in my bias file.

Exactly how are you using the gainSmooth12to16.tiff file?

[Brian Swift]

Exactly how are you using the gainSmooth12to16.tiff file?

Schematically,
corrected segment = gain * (raw segment - debias)
which I got from https://en.wikipedia.org/wiki/Flat-field_correction

gainSmooth12to16.tiff contains the gain values used for the Blue, Green, and then Red filters ordered from top to bottom.
Values are 32-bit float and can be greater than 1.

Technically, gainSmooth12to16.tiff isn't used by my pipeline.
The gains are embedded in the Mathematica notebook that implements the pipeline.
They are an Association with filter names as the keys and the individual gain images as the values.
I exported them to gainSmooth12to16.tiff to make them more accessible to other developers.

This is the Mathematica code that implements the entire flat-field operation:

CODE

flatFieldCorrect[rawFramlet_Image, chanKey_] := ImageMultiply[
  ImageSubtract[rawFramlet, debias[[chanKey]]], gain[[chanKey]]]

flatFieldCorrectSegments[segments_Association] := MapIndexed[
  Function[{framelets, filter},
   Map[flatFieldCorrect[#, filter[[1]]] &, framelets, {2}]
   ]
  , segments]