What to do after the closure of Midnight Mars Browser? Options

[nogal]

I think MAHLI follows the file naming convention for mastcam, which is described in this paper.

Thank you very much!
Fernando

[phase4]

Small update to Marslife.org.

The sun, earth and both moons of Mars were already present in the Marslife simulated sky. Yesterday I added the Mars2020 spice data to the mix.
Sure, it's only a few fake pixels but to me it's a very exciting view to see Perseverance slowly approaching.



Now only hope that its position is correct
There's not much else to report, except that a fullscreen view option has been added to the menu.

Enjoy!

[djellison]

Just a thought - Are you using just the left-eye images?

You will find that when we take an 'upper tier' ( extra images to capture Mt Sharp and other topography above the horizon ) more often than not it is right-eye only....so you might be missing out on some images.

Great work though!!

[phase4]

Thank you Doug!

You are right, the website uses left-eye images only. Checking just these has proven to be a convenient and somewhat reliable indication whether the rover has travelled to a new location.
In fact, the whole update mechanism is based on a very complex left-eye algorithm ( if NumberOfNewLeftNavCamImagesPerDrive > 7: ) that triggers the website and twitter updates.
So yeah, while this approach has been adequate enough for its purpose, I see now that it's failing to include the pretty right-eye pictures.

I'll accept the challenge to come up with a solution. In the mean time I hope your team will be able produce a few extra 'upper tier' left-eye images as well so that we can have some juicy anaglyphs!

Rob

[djellison]

So - here's the trick. We will never take a left eye without a right eye. The right eye is the one being monitored for temperature - so if we do mono imaging ( like upper tiers ) it'll either be right eye mono - or - rarely - stereo ( you don't really get much range data on upper tiers so stereo is definitely an indulgence )

tldr You might find some mono-left-eye stuff when we were operating on RCE-A or before about Sol 1600. But since we discovered an idiosyncrasy about how the rover monitors camera temperatures - it's either stereo, or right eye mono. Never left eye mono. Our deck monitoring 3 frame mosaics and our upper tiers will usually be right eye mono

[fredk]

There's another good reason to use the right navcams - they are less noisy than the left. Compare these two frames, eg:
https://mars.nasa.gov/msl-raw-images/proj/m...NCAM00266M_.JPG
https://mars.nasa.gov/msl-raw-images/proj/m...NCAM00266M_.JPG
The extra noise in the lefts is most obvious in smooth areas such as the sky or the hazy distant rim of Gale.

[phase4]

A new option has been added to the Marslife website that allows for viewing the Right Navcam panorama's.
Currently this option has to be selected in the menu but it might become the default setting in the future.
Thank you Doug for the suggestion!

[phase4]

Not sure where this will lead to but I've had some succes adding unbayered Mastcam images to Marslife. (not yet available for public use)





The official JSON files come without extra information for Mastcam images so I use the camera pointing data from Spice. Most Mastcam images match pretty well with the Navcam environment but there are others (especially earlier on in the mission) where the positioning is way off.

To improve the positioning and scaling of Mastcam images, the subframerect information is also needed. Since this information is not available in the JSON files maybe someone here can help and tell me if and/or how the Mastcam subframe information can be extracted from Spice data?

Thanks!
Rob

[mcaplinger]

To improve the positioning and scaling of Mastcam images, the subframerect information is also needed. Since this information is not available in the JSON files maybe someone here can help and tell me if and/or how the Mastcam subframe information can be extracted from Spice data?

AFAIK it can't be -- the SPICE only describes the RSM pointing, not what subframes are being acquired.

As a general rule, a subframe is going to be roughly centered on the boresight, exceptions being images of the cal target, sun, moons, etc.

You could perhaps back it out on an image basis if the subframe contained recognizable pieces of crud on the sensor, but that's pretty gross.

[fredk]

You could perhaps back it out on an image basis if the subframe contained recognizable pieces of crud on the sensor, but that's pretty gross.

This is more or less what I did when I implemented a hot column remover for my deBayering algorithm. The ML sensor column 1070 is hot starting from row 33, but on subframes it will usually be different columns and rows of course. I simply looked at the hot columns on several resolutions of ML images and made a list. Eg, on 1328x1184 ML frames the hot column starts at 910,17, which implies the subframe is (161,17,1328,1184).

You don't need to look at defects/crud to do this though - just go through old images that do have json subframeRect values and make a lookup table of resolutions vs subframeRect values. This won't always work though: eg, resolution 1536x1152 is associated with subframeRect (17,17,1536,1152) and (65,33,1536,1152), although the latter seem to be limited to rover deck images.

Anyway, this approach was sufficient for me to remove the hot columns from almost all ML frames.

[phase4]

AFAIK it can't be -- the SPICE only describes the RSM pointing, not what subframes are being acquired.

Thank you mcaplinger for your answer. I was afraid it wouldn't work like that. The Midnight Planets app displays Mastcam images in different sizes so I assumed Spice would somehow contain that info.
It makes me wonder how the subframe info for Navcam images end up in the JSON.

As a general rule, a subframe is going to be roughly centered on the boresight, exceptions being images of the cal target, sun, moons, etc.

In the end I visually matched one Mastcam image to the Navcam scenery and used this pixelwidth as a scaling reference for all other images (less pixels, smaller image) which seems to give good results.

[phase4]

Hey all,

I've build a first preview of the Marslife website that shows bayered Mastcam images on top of the Navcam panorama's.
It contains the left Mastcam images up to sol 3018, grouped in line with the original Marslife post-drive-imaging index.
I didn't expect the site to perform so well (showing 150+ images) but unfortunately it crashes on my mobile phone.

If you don't mind the long loading times you are welcome to give this preview a try: https://captainvideo.nl/marslife/preview.html
Toggle the M key to hide/show the Mastcam images, doubleclick an image to have the filename printed in the bottom-left text.
Clicking the filename will open a browsertab with the corresponding NASA MSL raw images page.

Enjoy!

[charborob]

It doesn't seem to work in Firefox 78.7.0esr (on Mac). All I get is a screen full of rubbish.
It does work though in Chrome 88.0.4324.96.

[phase4]

It doesn't seem to work in Firefox 78.7.0esr (on Mac). All I get is a screen full of rubbish.
It does work though in Chrome 88.0.4324.96.

Thanks for the report. Firefox 85.0 (64 bit) on a macbookpro (late 2013 - osx 10.13.6) works fine for me.
Maybe upgrading Firefox will help?

Edit: Apologies charobob, i wasn't aware of Firefox version numbering, you are already using the latest version.
Nonetheless I have no issues with both versions.

[charborob]

Fredk, when I click on the sol 3027 link in your MSL image browser, I get the following message: "Forbidden. You don't have permission to access this resource." Is this normal?

Edit: OK, it is working now.