The Top of Vera Rubin Ridge Part 2, Site 67-73, sol 1944-2297, 24 Jan 2018-22 Jan 2019 Options

[jvandriel]

The complete Sol 2264 MAST L view.

Jan van Driel

[climber]

I don't want to increase the noise, but, this one Jan, definitively one of your best. Thanks

[Sean]

MSL_2264_ML / debayered / extended sky

[PaulH51]

I realise that MSL has lost chunks of memory from both of its A and B computers, and can only presume that this is connected to the recent swing to nearly all the new full frame colour images from the mast cameras (since the last computer glitch) being placed on the public server as compressed bayer encoded files. I also realise that its more than a little late in the mission to expect JPL to create a pipeline to de-bayer these before compressing them to colour jpeg's prior to placing them on the public server like they have done with the MAHLI images since landing. It's a huge pity as I believe it's an enormous loss in outreach, take the R-MastCam images from sol 2287 as a prime example, I can only imagine how wonderful they are with the artefacts I get during de-bayer.
So I'm hanging up my hat for the time being on MSL and will leave all the processing of mast camera panoramas / mosaics to those with the skills to do justice to these images. Hopefully they will put something in place for the images from the 2020 rover, fingers crossed they will be friendly for those amateur image processors like me or even the public who browse the mission image server only to find the vast majority of the images in 'apparent' B&W, without knowing that most of them are actually in glorious colour, but sadly masked by the bayer filters...

[jccwrt]

I'm not sure the surge in bayer encoded images is related to the computer/memory patches. The drill sample analyses consume a lot of power, so it makes sense to downlink selected old observations at full resolution if there's no reason to use the cameras on a given sol. This also appears to be the end of the VRR campaign, so a nice, full-resolution mosaic is good for both traverse planning and for a nice press release saying 'this is where we're going next'. I think we'll see a return to compressed images once Curiosity hits the road again.

(I think a lot of those black and white images are also multispectral observations to characterize iron oxidation state and mineralogy along the ridge. Going to try to figure out how to play with these soon.)

All that said, I would really love to get the debayered raw images through the pipeline. They're hard enough to get good results from that I don't even bother with them anymore.

[mcaplinger]

I realise that MSL has lost chunks of memory from both of its A and B computers, and can only presume that this is connected to the recent swing to nearly all the new full frame colour images from the mast cameras (since the last computer glitch) being placed on the public server as compressed bayer encoded files.

It's unrelated to the memory problems (whatever they are, I haven't heard the details and "lost chunks of memory" may not be accurate). If the downlink volume allows it, people would rather have the raw data than JPEG.

As I've said before, I've complained myself about the inappropriate use of JPEG on Bayer encoding to everyone who would listen, but it's not up to me obviously. Complaining about it here is not productive and probably a rule 2.6 violation.

[PaulH51]

Re memory loss I refer to Emily Lakdawalla's recent Curiosity Blog (Sol 2163-2256) link

I have highlighted pertinent sections of Emily's post

The B-side Anomaly:
On September 15 (sol 2172), engineers noticed the rover behaving oddly: it was not transmitting any saved science or engineering data, but could transmit engineering data acquired in real time as long as it was communicating with the Deep Space Network or an orbiter. The rover was perfectly healthy, having no issues running any of its vital systems, but had lost access to the part of its memory where it stores data for later retrieval. The data structure of that part of the rover’s memory had become corrupted, and the rover couldn’t access it. This was, clearly, a serious problem for science, but fortunately didn’t threaten the safety of the rover.

Still, the fact that the rover couldn’t store information for later retrieval made it very difficult to troubleshoot the issue. The mission determined that the best course of action was to swap to the backup computer; once they were on the backup, they'd be able to troubleshoot the (formerly) main computer. Curiosity has been operating on its B-side computer for nearly 2000 sols, ever since sol 200, when a serious problem occurred in the A-side computer’s flash memory. It took until sol 772 to recertify the A-side computer for use as a backup to the B-side computer; a software patch now prevents the A-side computer from using half of its flash memory.

Curiosity returned to limited operations by sol 2204, and had resumed science planning with the full team on sol 2216. This is a remarkably fast recovery, given the ridiculous quantity of work the team had to do -- and how carefully they had to do it -- to return the rover to its A-side computer. Meanwhile, unlike with the sol 200 anomaly, the B-side computer is still available as a backup to the A-side one, if anything happens; Curiosity would be safe running on the B-side one, it just wouldn’t be able to do science.

Since Emily's update, further diagnostics on the B-side computer anomaly were planned over the long holiday period at the end of 2018 link. I have not seen any news re those planned diagnostics over the holidays. So the way I understand the current situation is we have only 50% of the original flash memory on the A-side. The B-side computer can not currently be used for science, because we cant read from its memory. Hence my comment of missing 'chunks of memory'.

Re: (jccwrt) The multispectral observations can readily be identified by the associated thumbnails which are stored as colour jpeg's, so I dont count those, but there has been an increase in the numbers of compressed bayer files. We are even seeing compressed bayer encoded R-MastCam frames that that are acquired to provide context for the RMI images of ChemCam targets (eg link)

My post was not an attempt to break rule 2.6, just noting the obvious change in the ratios of images being received since the anomaly which precludes folk like me who have extremely limited skills and very limited software tools to do the processing that can be done with those compressed /encoded images by others members. And the hope that this situation is avoided on future missions for outreach purposes. If my post breaks rule 2.6 by criticizing this mission on the basis of hindsight and/or incomplete information, I'm only using the publicly available information I am aware of from Planetary Society blog posts and JPL mission updates.

[mcaplinger]

Re memory loss I refer to Emily Lakdawalla's recent Curiosity Blog (Sol 2163-2256) link

OK. I don't find that discussion has enough technical detail to understand what the real issue is, but I'm probably being excessively pedantic as someone who wrote the flash software for the cameras. (Recall that the flash problems are on the rover side, the cameras still have as much flash as they always have.)

At any rate, if we were trying to limit memory usage we would use more JPEG, not less.

[elakdawalla]

From section 7.2.1.5 of my book:

Where the compression artifacts make it difficult to interpret the
geology, the team can choose to re-transmit the image with less compression, or even
losslessly – as long as the original image is still stored in the camera’s flash memory.
As of early 2017, not quite half of all of the Mastcam data had been returned a second time
with lossless compression. At that time, the mission switched to returning all non-time-critical
Mastcam science data losslessly, accepting delayed data return in exchange for a
larger proportion of losslessly compressed data and a reduction in the complexity of data
curation.6

6 Michael Malin, personal communication, email dated April 14, 2017

[Sean]

This link is active for 7 days and contains all the 2287_MR files converted to RGB using GIMP & G'Mic...
https://we.tl/t-7uWU3n2Unp

The following is an early process from this sequence...


and a detail...

[charborob]

Thanks a lot, Sean, for your deBayering work. Here is the almost complete panorama:

[xflare]

Beautiful!

Drive Drive Drive

[Sean]

@charobob Nice work there.

I found it extremely tricky to stitch Mount Sharp together due to the lack of features to identify. Once this panorama is complete it will look fantastic, one of my favorites.

[PaulH51]

Today on Mars: Sol 2291 MAHLI. Processed and cropped preview, the final version should be memorable.

[fredk]

Clouds on 2279, showing some banding we don't often see:

And clouds on 2283: