PJ40-11: Not the greatest fit I have ever seen but not that bad, at least on the leading limb. If anything, it looks more like a crosstrack error than a timing error.

That's a beautiful product!

BTW, I find it hard to believe that this amount of topographic variation is going to make a big difference to the helicopter. Much more significant is the seasonal global variation in pressure.

IIRC, every time before when somebody has reported "weird results" it's been because of out-of-date kernels or something like that. Please list your complete kernel set and I'll take a look when I get a chance.

We don't typically do the timing corrections until later but FWIW I don't see anything especially noteworthy in our processing so far.

It's a little hard to tell what you're asking, but if you export the heli location to GeoJSON you get



which seems like the post-flight-19 location?

Presumably they just haven't updated https://planetarynames.wr.usgs.gov/ yet -- the last update was in early December 2021.

IM was saying 1Q 2022 but recently tweeted "Intuitive Machines’ IM-1 mission launch is moving outside of Q1 2022 to later this year. We will provide updates as they become available."

My understanding from our ops folks is that if you see an image that's marked "partial" on missionjuno, then we have exhausted all ways to fill it in and this is the best we are ever going to get. So PJ38 is all done.

I'll ask, but I suspect those will remain partial. The drops are fairly minimal so I'll see if we can post them.

I'm not authorized to discuss problems. You can look at DSN Now or https://twitter.com/dsn_status to see what Juno downlink passes have looked like recently. The Earth-Jupiter range over 5.8 AU right now. As a general rule, we put up the images shortly after we receive them in their entirety.

Certainly we didn't ask for this functionality, no other pushframe imager support in ISIS has it, and we weren't asked for, nor did we provide, any input about how pixels are mapped to CCD lines.

I acknowledge that the I kernel is not very clear about what the CCD layout is; technically it doesn't need to be. I didn't concentrate on this because we were trying to get the framelet parameters all correct, and I believe they are. But how we got to that point is more confusing than one might hope. I did find a correction for the dark/buffer CCD rows buried in the parameter-fitting code that we used to update the I and frames kernel values from cruise star imaging. Unfortunately, near the end of that analysis we realized that the random timestamping errors were going to swamp any effort to get to subpixel precision on this, so what we have now is probably near the limit of what can be done.

I will conclude by observing that camera models don't have to be "right" and often aren't, they just have to yield correct and consistent results.

I don't think this is true, no.

D except there is one set and it's always used by every imaging command.

There are five parameters: how many lines to skip at the top during CCD readout (done in hardware in the camera head), and then how many lines to skip at the top of each 155-line band area to produce the 128 lines that are actually sent to the ground (done in software). 155-line regions for bands that aren't being taken in any given image are also skipped in hardware (at the top -- if you commanded an red/blue image the green would get read out and then thrown away in software because the hardware can't skip lines in the middle of a readout, only at the beginning.)

I'll quote from the Junocam User's Guide, which says the same thing:



In the I kernel, I concentrated on describing how to do the geometric correction for the 128-line framelets we actually get on the ground, and never tried to describe in detail exactly where those pixels were coming from, and none of my processing ever tries to reconstruct the "original" frame like FULLCCD does. I think the ASCII drawing in the I kernel is accurate, but I wouldn't swear to it since none of my processing is doing anything with it. And to reiterate, my interaction with the ISIS team has been pretty minimal and I have not made an effort to understand their design choices, some of which seem odd to me.

I don't have any idea what they are doing with the junoAddendum005.ti file or why they need those values. My code only uses the values from the standard I kernel.

It sounds like the error, if it is an error, is cancelled out by whatever they're doing in the code. I did some tests between my results and ISIS results a couple of years ago, and they matched at the eyeball level (1-2 pixels, perhaps better) so there are no gross discrepancies AFAIK.

Good catch. I suspect the issue is that that file says INS-61500_BORESIGHT_LINE = 600 when I don't think it is, but 600 - INS-61502_FILTER_OFFSET = 3.48, which is INS-61502_DISTORTION_Y in the official I kernel. So it may be that those two confusions/errors cancel out in their processing.

That doesn't sound correct to me, but I'm not sure what subsequent processing they are doing with such an image.

If you could show that the lat/lon mapping for the same image pixel was different between a FULLCCD image and a one-band image, that would be definitive proof of an inconsistency somewhere.

I'm not sure if you can back those start lines out from the info in the I kernel, but maybe.

I don't, and not much can be inferred from the comment files. I expect that the Ganymede ephemeris could be updated from Juno flyby data, but whether that's what this is or not I can't tell.

In my experience, you have to try using two files to see if there is a significant improvement, and obviously any adjustment done with an older file may well break with a newer one.

Mostly by making the exposure time longer, like visible cameras nearly always do. For example, https://atmos.nmsu.edu/PDS/data/hpdisr_0001...71_S_0910_M.PNG had an exposure time of 50 msec, and the DISR SLI had 23x17 micron pixels and a bandpass of 660 to 1100 nm, f/2.5. So it's dim, but not exactly dark.

There are a lot of things that don't seem sensible about ISIS. I think it would depend on your use case as to whether this was a feature or a bug.

At a distance of 1.5e6 km, the Hubble's ACS instrument gets a resolution of 364 meters/pixel, so JWST would be a dimensionless point.

Perhaps counterintuitive, but AFAIK all three-mirror anastigmats ( https://en.wikipedia.org/wiki/Three-mirror_anastigmat ) like JWST, and all Cassegrains for that matter, have convex secondaries. The Gregorian configuration has a concave secondary, though.
https://www.telescope-optics.net/two-mirror.htm

I spent some time looking at the NASA Tech Report Server but didn't really find anything that had a lot of detail about the sunshield (AKA sunshade). It may be that because it's a somewhat separate system designed largely by a subcontractor, the usual publication paths don't apply.

https://ntrs.nasa.gov/api/citations/2020000...20200001556.pdf is a very high-level discussion but has no satisfying details and there are no references to anything about the sunshade, though it mentions a 1/3-scale test model of it.

It's always tough to debug these sorts of things. You might compare what your code produces for a single framelet against what ISIS produces, if you can make the investment in time to install and understand ISIS. I would expect that if you are using reconstructed SPKs and all the correct up-to-date kernel files (spacecraft clock and leapsecond are very important for C kernel use), the residual errors would be maybe 2-3 pixels?

As far as I could tell in a quick skim, you weren't applying the 61.88 msec start time bias described in https://naif.jpl.nasa.gov/pub/naif/JUNO/ker..._junocam_v03.ti but your limb offset should fix that if it's done correctly.

Very nice, the code is very clean and readable.

Seems like you have a lot of blending artifacts in the mosaic, only to be expected. I haven't really examined your blending method in detail, it's working really well to hide gross seams but there's feature doubling, I think, at small scales. This is a tough problem and I'm not sure what the best way to do it is that isn't very labor-intensive.

Those showed black monoliths so we had to hold them back from the public

Seriously, if we haven't posted something, it's usually because it still has residual data drops that we are waiting to be filled in.

He's probably too busy processing Junocam images, when he's not working his day job at JPL on MSL ops. I always get a kick out of seeing his name on MSL project emails when he is on-shift.

The IPP had a stated IFOV (instantaneous field of view, the angular resolution of one pixel) of 0.5 mrad, which is actually a little higher-resolution than Junocam's 0.673 mrad. In reality, I suspect there was a significant loss of resolution from the detector and electronics, blur from spin, imperfect geometric registration, and other sources.

The IFOV of any camera is its detector's pixel pitch divided by the focal length of its optics.