Could be a glint off the solar panels or something on the panel structure. The spacecraft was more or less spinning around the sun line at this time since it was so close to conjunction, so the illumination on the panels wouldn't have changed very much during the spin.

Semifinalists of naming contest announced: https://www.futureengineers.org/nametherover

G = ( R + B ) /2 for starters.

The first three images from the somewhat but not very close flyby of Ganymede (it's about 78 pixels across) are up now.

PJ24 happened back on 12/26 but the spacecraft was in solar conjunction until around the end of the year and we are just starting to get the data back. With the holidays it may be next week before images start showing up on missionjuno, so stay tuned.

Mastcam frames are always somewhat greenish, no? I don't think it has much to do with the debayering process, JPEG or otherwise. It's a manifestation of the 420-nm cut-on of the clear filter.

If we had ever seen anything that would make the interframe delay different than the header value plus 1 msec, we would have said that, but we haven't.

AFAIK nobody has ever said anything about jitter on the interframe delay, only on the start time.

I don't have any measurements for the specific image you posted, but for PJ1-6160 the time offset was about 1 pixel different from the reported values. But again, that's a start time offset, not an interframe delay change.

Could use Webgeocalc. https://wgc.jpl.nasa.gov:8443/webgeocalc/#StateVector target bennu, observer osiris-rex.

I don't see it in the XML file, you may have to compute it from the SPICE files.

I looked in the documentation https://sbnarchive.psi.edu/pds4/orex/orex.o...t/ocams_sis.pdf and I see no evidence of position information apart from a sun vector. Seems like an odd omission given the plethora of orientation information in the label.

Well, I wrote that, and I don't know how to make it any clearer than that.

"Natural color" requires you to model the human eye response. The Junocam RGB filters are not much like the human eye response (unlike the Bayer pattern used for MSL) so one would have to do something, but I'm not sure what.

In case you care, the EDR-RDR scaling code (after decompanding) is

One thing I've found is that if possible you should wait for the reconstructed SPK files before trying to process, it has made a big difference for some orbits.

limbpt is supposed to using the spheroid, so this doesn't seem like a good explanation, but I use edlimb, not limbpt (warning, speed of light not properly handled.)

BTW, this isn't the right way to do this. The right way is to use pxfrm2, which takes two different epochs. See the example in the comments for pxfrm2. That may be the source of your error.

I have to confess that my processing chain uses pxform and doesn't correct for the speed of light at all. When it was originally written for low Mars orbiters, this made very little difference. For Juno it makes a little more difference near perijove, and progressively more and more towards apojove.

In theory (I've never tried it) it would be possible to remove the camera distortions and stitch the framelets together accounting for spacecraft spin without calling sincpt at all or doing any intercept calculations.

Most cartographic pipelines map lat/lon on the target into pixel coordinates on the detector, and the mapping in the other direction is typically only used to determine the lat/lon range of the output map. Of course when doing the lat/lon->x,y mapping you have to account for points that are hidden from the camera by the planet itself.

As for the height of the actual limb relative to the 1-bar spheroid -- this is possibly a factor, but the limb is pretty far away even near perijove so it doesn't make a huge difference. For our timing corrections we ignore this.

Keep in mind that SPICE is computing the distance to the center of Jupiter, not to the visible surface, so if you're using the former when you mean the latter, there's an error there, which if you're close to the planet is a pretty big error.

Try not doing any light time correction at all. See the cautionary note in the comments for the sincpt function, etc.

Don't use the nom C kernels, use the rec C kernels.

Our measurements show that the timing for that image was off by 3 pixels or 3*3.2 milliseconds.

Not important, but still not following the invisible sphere stuff.

I'm not sure what you're trying to do (not following the "invisible sphere" stuff) and I have the suspicion that you're counting the light time twice, but all that said there are known timing errors of roughly six pixels 1 sigma in the Junocam start time that you need to correct for. We're working on pushing updates to the PDS but it'll probably be a while before that happens. In the meantime, which images are you working with?

Also, make sure you are using the reconstructed SPK files.

Penetrators were all the rage in the mid-70s to mid-90s (and flew on the Mars-96 mission), but the devil is in the details and it's not as easy to get anything useful out of them as might be supposed at first glance. https://ntrs.nasa.gov/archive/nasa/casi.ntr...19750004806.pdf

Maybe there's another thread where this could be discussed. InSight doesn't have a penetrator so it's off-topic here.

Just because it's spherical now on account of an accident of formation doesn't mean that it meets the definition of a dwarf planet ("has sufficient mass for its self-gravity to overcome rigid body forces so that it assumes a hydrostatic equilibrium (nearly round) shape")

I think ESO is reaching on this one.

Are you sure you know how the mole works? See http://esmats.eu/amspapers/pastpapers/pdfs...grygorczuk2.pdf and https://www.geomechanics.caltech.edu/public...shall-2017a.pdf for details.

One assumes that if they could have gotten a more robust solution into the mass/volume/power box they were in, they would have done so.

It's worth remembering that no one would have proposed doing the heat flow experiment this way if there had been a more straightforward drilling technique that would fit within the mission constraints.

As was pointed out earlier, even with many fewer constraints, the Apollo heat flow experiments didn't work well the first two times and Apollo 17's only got down about 2.5 meters. https://www.hq.nasa.gov/alsj/a15/a15carrier.html

Huh. I wonder who built this camera? I haven't seen anything public about it anywhere.

It would be an interesting exercise to find LROC coverage of this area and do a quality comparison. I tried looking but but wasn't able to find overlapping images in the few minutes I had to spend.

This thread is getting out of control with Chandrayaan-1 MIP discussion. IMHO most of the recent posts should be moved to http://www.unmannedspaceflight.com/index.php?showtopic=2686