AFM release (sort of) - Page 5

sol 89 3D AFM surface plot:

with a link to an OM animation of the AFM area before and after the AFM scan.

What I find most interesting are the linear "strands" that seem to be "real" ( seen in both the forward and backward scans"

But real what?

And here is another puzzler:

sol 90 3D AFM Surface plot:

with a link to an animation of the OM location before and after the scan.

again, "real"? - but real what?

These images are way, way out of my knowledge space.

Is there anyone able and willing to shed any "light" on these images?

sol 88 AFM scan:

with a link to a possible location.

I have almost no confidence in this location identification.

In particular, I do not know the relationship between the AFM scan location and the OM locations - but making a reasonable guess about the AFM scan size and the distance between the AFM tips and the AFM area makes the guess at least plausible.

Perhaps there is some documentation on this relationship?

I'll do a little search...

Thanks very much for the additional processing of the AFM scans. They are really starting to "come to life."

See page 10 of MECA AFM SIS on page 10 in the Phoenix Analyst's Notebook. The AFM scan is actually diamond-shaped (i.e. a rectangle at 45 degrees) relative to the OM scan.

It would be very interesting if the AFM scans could be compared to the OM context.

Barsoomer, table 4.4 ( page 19 ) of the document MECA Non-imaging Reduced Data Record (RDR) says that the AFM header table has fields:

refOMimage: Filename of the relevant OM image taken at the AFM scan position prior to start of the scan. This provides the context for interpreting the AFM scan data.

refOMimage2: Filename of the relevant OM image taken at the AFM scan position after the scan. This provides the context for interpreting the AFM scan data.

AFM_OM_ref_x: The approximate location of the center of the AFM scan field relative to the context OM image. X-coordinate in pixels.

AFM_OM_ref_y: The approximate location of the center of the AFM scan field relative to the context OM image. Y-coordinate in pixels.

er, weren't you using .tab files for your AFM images?

Where did you find the .tab files???

The Phoenix Analyst says there are currently no RDR products for the sol 88 AFM image

and I presume there are no RDR ( .tab extension ) files for any of the AFM scan files.

Er, right Barsoomer. I was just lazy when I drew the 25x25 micron box on the location image. I will redo it and repost. I rotated the 3D AFM so you could see the side of the grain more clearly.

Re reply 84:

As far as I know, no RDR products have been deposited for the AFM except for the test ones (SDD and SDR) on Sol4. This is in spite of (I think) the provision that all products were to be deposited in the PDS repository within 6 months of the end of the mission. I saw a note in the Analyst's Notebook that said the AFM RDRs would be deposited later, in June. June came and went, but no RDRs. That note seems to be gone now. Maybe they are in the PDS proper but not in the Notebook?

The tab files that I used were from the Sol4 test RDRs. (Then I later did some crude processing of some dat files.)

Your renderings seem to be the only accessible processed versions of the Scans, as far as I know.

On second thoughts, it looks like all the RDR products have been deposited here:

RDR products

but not apparently in the Phoenix Analyst Norebook.

fs088sdd_001_4e011a550000a0.tab header:

cmdTimewhole=904023600,
cmdTimeremainder=3773497344,
readTimewhole=904025730,
readTimeremainder=1798635520,
dataLength=019969,
Cols=256,
Lines=256,
Direction=1,
channelGain=1,

?????=0, er, what?

refOMimage="OS088EFF904023099_1A550MBM1.IMG",
refOMimage2="OS088EFF904025929_1A550MBM1.IMG",
opsToken=1A550000,
SwtsTemperature=251.5,
X-scanrange=16.578,
Y-scanrange=19.818,
Scaling_factor=05,

Smoothing_factor=???? missing???

AFM_OM_ref_x=092,
AFM_OM_ref_y=119,
X-slope=000.00,
Y_slope=-05.00,
ScanSpeed=04.7

The documentation is wrong??? ( again. )

If I am reading the RDR header correctly then the size of the scan is 16.578 x 19.818 microns and the center is at pixel 92,119 in the reference image OS088EFF904023099_1A550MBM1.IMG

Unfortunately, the center of my suspected location is at pixel 36, 128 in the reference image - so the big fat orange mote is not the one in the AFM.

Bummer.

I will try a few more before I draw any firm conclusions.

Any suggested images to check Barsoomer?

Following are quick links to the meca-afm reports for each Sol for which there are such reports. This might be useful for finding interesting images.

sol044
sol046
sol048
sol049
sol050
sol057
sol064
sol068
sol069
sol070
sol071
sol073
sol074
sol081
sol082
sol084
sol085
sol088
sol089
sol091
sol093
sol099
sol100
sol103
sol105
sol110
sol117
sol118
sol126
sol130
sol132
sol137

Well, the sol91 ones look interesting. The meca-afm report says this:

Sol: 091
Scan for that sol: 1 of 2
Sample: dustfall
Substrate ID: OM24
Substrate type: silicone

Intent of scan: to image particles
Target type: dustfall sample on silicone

OM context image before scan: OS091EFF904287409_1AB00MBM1.IMG
OM context image after scan: NONE

Sol: 091
Scan for that sol: 2 of 2
Sample: dustfall
Substrate ID: OM24
Substrate type: silicone

Intent of scan: to image particles
Target type: dustfall sample on silicone

OM context image before scan: NONE
OM context image after scan: NONE

I posted quick links for all the AFM reports for sols that have them, but the post is being held for approval by the moderator.

Regarding reply 88:

> The documentation is wrong??? ( again. )

I don't think so. In Table 4-4,

Direction
Scan direction mask 1=forward 2=backward
Channel represented 1=error 2=height

This is two items not one. So I think

Scan direction mask = 1
Channel represented = 1

and then ???? is the gain, which is 0.

Also,

> Scaling_factor=05,

> Smoothing_factor=???? missing???

According to Table 4.4,

"Scaling_factor The scaling factor that was used to calibrate the height data (i.e. converts DNs to micrometers) to produce this RDR (for SDR only) N/A"

"Smoothing_factor Number of points used in the Savitzky-Golay filter function. (for SDD only)"

The file fs088sdd_001_4e011a550000a0.tab is an SDD, not an SDR, so the 05 is the smoothing factor, not the scaling factor.

Barsoon, thanks for sorting out the header fields in the RDR header.

Here is the "Topograph by Hortotopography" sol 91 scan 1 as a 3D surface plot:

I don't believe it shows anything "real".

I am much depressed by the fact that this scan header, as all the others I have looked at, give the relative OM coordinates as 092, 119.

Again, I can't locate anything in the context OM near these coordinates that looks remotely like a particle 10 microns or greater in size...

Have you tried your Lisp program on these .tab files???

> Have you tried your Lisp program on these .tab files???

Yes, but it's clearly not working properly. It gives the identical output for tab files from different sols, an L-shaped region of smoothly varying darkness. It is a long time since I looked at this, so it will take me a while to analyze the program to see what is going wrong.

I think your images are very close to being accurate. The mission-processed ones, if we eventually see them, may have calibration and artifact removal as additional processing, but that is a lower-order change.

Could you do a plugin for the tab files? They may have the calibration, etc. and would be interesting to compare to the dat-derived images.

I did a Google image search for "dust particles" and the images look like a heterogeneous bunch not terribly dissimilar to what we are seeing for AFMs.

Information about MECA-AFM release of October 28 and other links.

http://uanews.org/system/files/images/15624.preview.png

The Sol68 tab file also gives the OM context as 092,119. The above image shows the actual Sol68 context. Could this be 092,119 in some unusual coordinate system? If so, then the AFM is always in the above location within the OM image.

http://pds-geosciences.wustl.edu/geo/phx-m-meca-4-nirdr-v1/phxmec_1xxx/document/meca_rdr_sis.pdf

Figure 4 on page 22 shows the location of the AFM scan diamond relative to the OM pixel coordinates for a 091,376 location. It looks like 092,119 would be above that maybe about 1/3 way up.

Not sure if this is consistent with the Sol68 indicated location.

If you rotate the AFM image -45 degrees so the AFM X axis is parallel to the OM X axis, then the AFM Y axis is pointing in the same direction as the OM Y image axis.

Image Y axis always point down from the top - not up ( Don't ask! )

The OM coordinates for the center of the AFM scan are pixel values in the context image.

ALL the actual context OM images were half frame images so both X and Y can only be between 0 and 255.

The reply 94 reference OM image is in fact a panorama of three full OM images, so the location of the AFM scan in that image must be based on the pixel coordinates associated 256x256 context OM.

The sample wheel position number is good to about 5 microns ( a little larger than an OM pixel ) , so if the position of the sample wheel before scanning is being used to determine the AFM center in the context OM images -- then it is probably reasonable that as long as the same AFM tip was being used then the OM pixel coordinates would be the same.

I will look at modifying the OpenFAMAR plugin in the next few days use .tab files.

The forward and backward height tables in fs082sdd_001_4e01197f0000a0.tab have a constant z (height) value of +3.5527E-015. Only the backward and forward error tables have varying values. Not sure what that means. Perhaps the documentation is wrong and the error and height tables are reversed? However, the error data does not give me a recognisable image either. Maybe just this particular tab file is incorrectly transcribed?

Ok, the 002 file fs082sdd_002_4e01197f0000a0.tab has meaningful height values and does give something that looks "real" and resembles one of Horton's 082 images.