Hey, Jim. Here are some quick answers. I am concentrating on working up a guide on how to use the spreadsheet. The steps in the worksheet "Workflowmenu" are labeled 1, 2a, 2b, 3, etc. and can be hacked through by a computer savy user. That will not cover everyone. A further new demo is needed. > You are getting some amazing results from this shape from shading > (SfS) stuff! I am but the humble student. Wohler and GLR Group people are the masters of this. I'm not sure, but they are probably using Mathlab or Mathematica to crunch the pixel values into a 3-D model. What I am trying to accomplish is to have a simple no cost tool from commonly available existing desktop resources that amateurs can use. The GLR Group people use a more complicated algorithm than the easily coded Carlotto's algorithm used in my spreadsheet and Evans' spreadsheets discussed in the 2006 issue no. 1 of _Selenology Today_. Free back issues of _Selenology Today_ can be obtained at: http://digilander.libero.it/glrgroup/ > If I am not mistaken, a similar technique was suggested, and used, by > Marcel Minnaert (of /Light and Colour in the Open Air/ fame) for > estimating the heights of wrinkle ridges in the lunar mare many, many > years ago. Part of the literature on Shape-from-Shading (SFS) does refer to early work by Minnaert. I have seen but have not tracked down the specific literature references. > It seems a very good technique for visualizing the > three-dimensional structure implied by the variations > in brightness seen on the lunar surface. With some limitations - 1) generally within +- 30 lat and long. 2) using surfaces made of a uniform material with a uniform reflectance. An SFS digital elevation map of Reiner Gamma would falsely record elevation changes where none are present. 3) in ultra-low illumination angles, e.g. 4 to 10 degrees solar altitude, so the entire FOV is illuminated by grey tonal variations but without saturated bright spots or uniformly dark-black shadows. SFS will work in illuminations up to 20 or 30 degrees. In solar altitudes greater than 30 degrees, SFS will no longer properly estimates feature elevations. To those traditional limits, I would add my personal empirical rule that: 4) The feature sticks up from or down into a surrounding plain of nearly the same lunar radius. With SFS, you are looking at 3-D rendering very small parts of a typical amateur lunar astrophoto. Typical feature grids are at most 100 x 100 pixels in size and cover at most a 20 or 30 kilometer square of the Moon's surface. You will not be able to feed in a 100km - 3 or 4 square degree crater image into the spreadsheet and get an accurate 3-D rendering. > First, by way of background, without reading all the details, I > believe the basic idea of SfS is that, all else being equal, the > brightness of a patch of lunar surface is an indication of its > inclination (tilt) relative to the light source (and perhaps towards> us as well). . . . . > By studying each row separately, and placing the > profiles side by side we could build up a three-dimensional > picture of the surface. . . . . > The main problem I see is that the method described above > produces a shape, but it does not produce a scale. I.e., > you can guess where the surface is going up and down, but > you don't know by how much. Your description has all the basic concepts down. You easily can generate a contour map from brightness values in a 2-D image using many software packages like AIP4WIN or PhotoShop. But a simple brightness contour map provides no way to scale the elevations represented in the image to a physical size in meters. Physically, how far apart in the z-plane are the contour lines? SFS provides an analytical means relate the horizontal resolution of the image in meters per pixel - something that amateurs traditionally compute all the time and list on their astrophotos - and to apply that scale to pixel brightness to yield a physical z-plane measurement or height elevation. The simple lighting-to-slope relationship applies in a narrow set of circumstance. That is when the solar illumination of a scene is at an apparent right angles to image, flowing from the left to the right, i.e. from 270 degrees. The Carlotto SFS algorithm simplifies computation by first preprocessing thesource image by rotating and cropping the image so that the apparent azimuth of the Sun is to the left, flowing at right angles to image from the left to the right. In the Carlotto algorithm, the image is preprocessed by rotation so the apparent solar azimuth is at 270 degrees. Typically, I use AIP4WIN to preprocess the image where rotation is needed. AIP4WIN can be relied upon to not modify the original photometry in the image. Other image processing packages, like PhotoShop or Meade AutoStar Image Processing, may force a behind-the-scenes stretch of the image's pixels and not tell the user about the change. IMHO, the best SFS images can be made where the solar azimuth already naturally flows across the image at a right angle from the west (270 degrees) or the east (90 degrees). The amount of image rotation should be minimized by taking the image at favorable libration as close to these angles as possible. In this regard, your and Bondo's LTVT is tool provides a unique compliment to SfS because of its planning feature. The LTVT planning feature allows the user to find the next date and time that a favorable low solar angle illumination will cross a feature. Another way in which Earth-based telescopic images deviate from the assumption of right-angle lighting is foreshortening. Evans' 2006 article suggests, and my spreadsheet implements, a means to make a final adjustment of digital elevation heights for the basic foreshortening scalar, familiar to most lunar students: Tilt (or foreshortening) Factor = 1/[cos(b – b’)*cos(L-L’)] where (b,L) are the selenographic coordinates of the feature and (b',L') is the observer's subEarth lunar longitude and latitude. Although I implemented an option in my spreadsheet to apply the foreshortening adjustment as described by Evans, in practice I do not use it. Here again, your and Bondo's LTVT makes SfS processing much easier. What I do is rectify the source image in LTVT. This removes the need to make any foreshortening adjustment to the SfS DEM. If the UTC date and time and observer location are known, LTVT also reports the solar altitude and azimuth for use in generating an SfS digital elevation model (DEM). Traditionally, Jamieson's 1997 Lunar Observer Tools have been used to obtain this information. > Question 2 : Do you in practice get a result any different from > simply adding the intensities along the row in the manner just > described (i.e., although the formulas may involve sines and cosines, > the surface slopes are very small so the results may very well be > equivalent to what you obtain with the much simpler assumption of > brightness proportional to slope)? That's right and is what Carlotto's alogrithm does. Pixel brightness is an abstract variable indicating terrain slope. The slopes of each individual pixel in the image is computed. Slopes are a scalar with a horizontal x-y size of unity or "1". Then you walk down a row of pixels, adding up the slopes to get an abstract map of elevations where all the horizontal x-y sizes are "1". Since the image's horizontal pixel scale in meters per pixel is easily found through traditional astrophotographic techniques, you simply multiple all the elevations by the horizontal pixel scale and end up with an estimated elevation contour map in meters. Another simplifying assumption - which to me seemed counterintitutive - allows one to correlate the relative average height of each row to the average height of the previous and next row in the image. The simplfying assumption is that all of the pixels in any one row will average to the same value. It sounds wrong to me, but it does actually seem to work. A dark-well shadow creeping into the side of an image from an off FOV feature violates this constraint and generates a depth artifact for the entire row. This is described in Carlotto's paper as "bounding the solution range" to the average pixel value, either in the row to the average of all pixels in the image. This is also why a good SFS source image is taken at very low 4 to 10 degrees solar altitudes and why the technique works only on features with a relatively low maximum height. In such low altitude illumination, the terrain reflects light in measureable shades of grey on both faces of the feature. Under such illumination, the assumption that all pixel values in a row will nearly average to amount is true. > Question 3 : Is your spreadsheet fundamentally different from the > one described by Rich Evans in /Selenogy Today/? or is it the > same machinery with a slightly different front end? Both Rick's spreadsheet and my spreadsheet implement the same Carlotto alogrithm. In Rick's spreadsheet you had to cut and paste perhaps 80 to 100 parts of an image between worksheets and repetitively apply macros to reach the final result. In Rick's article, he invited someone to write some VBA code to automate the process. My implementation took up Rick's suggestion and does the same thing as Rick's spreadsheet. But instead doing a hundred or so manual cut and pastes, several hundred lines of code crunches the numbers and in a couple of minutes you can be looking at a 3-D VRML SFS rendering of your image in a VRML browser. The mathematics involved are pretty trival. There are two equations that apply simple trig. The first is the optional foreshortening adjustment described above. The second equation estimates the slope of pixel from its brightness: Eg = (Pv – AvgPv)/(AvgPv*tan(s)) Carlotto-Evan's Eq. 5 Note this is just a variation of the basic equation for the slope of a line for junior high school algebra: slope = (y2-y1)/(x2-x1) In Eq. 5, Pv is an individual pixel value. AvgPv is the average of the pixels in a row. s is the solar zenith angle (z = 90 - solar altitude). Other than that, the only other math involved is multiplying an NxM matrix times a scalar or summation of the rows in an NxM matrix. Again, tedious programming in VBA, but nothing really mathematically complex. Martix algebra is easily done in symbolic mathematic software. Using my implementation, you just have to run through an image matrix several times applying different transforms on each pass to get the final elevation numbers. The digital elevation model can be regenerated in a couple of minutes, so it is a quick matter to render successive versions till you have something that you feel best brings out available detail in the feature. If your programming partner wants to take a look at it, in my spreadsheet, all the "business end" code is in the VBA code behind the worksheet labeled "Workflowmenu". The code is extensively commented and not terribly complex. It is just lengthy and tedious and could benefit from code refractoring by a real programmer. A key pseudo-code summary is at the top of the procedure labelled "cmdGenerateDEM". The comments also track and cite back to key equations nos. 3 through 6 in Rick Evans' 2006 _Selenography Today_ article. You can read Evans' paper and follow the corresponding equations in the VBA code. To the extent that the coding is of any use to you or Bondo in developing a better mousetrap, a SfS DEM addition to LTVT - please free feel to copy, port and use it. (I do not assert any kind of copyright against the code or the spreadsheet, copyright normally cannot be asserted for math algorithms and code, and to the extent copyright is assertable, I release both to the public domain.) > Question 4 : How does your spreadsheet turn the seemingly arbitrary > vertical scale into one calibrated in meters? See above. SFS provides a means to relate the horizontal scale of the image in meters/pixel to scale the vertical elevations in arbitrary units. The unitary digital incidence matrix is just multipled by the horizontal/pixel scale of the image. The psuedo-code that I used to implement Carlotto's algorithm is: 1) Get the raw reflectance pixel-value data Begin DEM computation-build 2) Build the working array of average pixel values for each row 3) Compute the constant for tangent of the zenith angle of the sun - tan(s) - used in Carlotto Eq. 5 4) Compute and report cos(s) value from Carlotto's Eq.s 2 and 3 5) Build an array of elevation gradient values for each cell using Carlotto Eq. 5 6) Sum the array of individual elevation gradient cell values into an elevation gradient map. Makes the matrix of summed gradient elevation. 7) Compute the foreshortening tilt factor 8) Build the final DEM by applying the image scale to the summed gradient elevation map. Makes the final DEM. 8A) Apply the image foreshortening tilt factor and base terrain values to the summed gradient elevation matrix, creating the final DEM matrix. 9) Report the results This pseudo-code uses four matrix objects: a) an NxM matrix of pixel brightness values; b) an NxM matrix finding each pixel's slope through Eq. 5 - the gradient matrix; c) an NxM matrix that progressively sums the individual slopes - the summed gradient matrix; and, d) the final 3D digital elevation model, an NxM matrix of summed gradients multiplied by the horizontal meters/pixel image scale. > Question 5 : How does your spreadsheet separate the effects of > albedo variations from the effects that are due to variations in > inclination? It does not. That is an inherent limitation of the SfS technique. You have to carefully select your cropped FOV to exclude such variations. Typically, you might also check the Clementine false color images to confirm whether the surface materials in the image are made of same minerals - corroborating the assumption that the surface relfects light (somewhat) uniformly. As a practical matter, such idealized surfaces do not exist and some sub-features will be included in your image that violate the basic limitiations of SFS. Even in most professional astronomer SFS renderings that I have looked at, for example, Mars is the current hot area for this technology, there are always one or two small craters or maybe a steep hill that have artifact heights. Typically, the artifacts are crater rims that just catch the Sun at the right angle to reflect a bright light that is disproportionate to the rim's elevation. The main point is that the central feature of interest is properly rendered without artifacts. When distributing a 3-D rendering, you just need to be aware of the artifact problem and declare to the reader what subfeatures and not properly rendered. > Question 6 : Even if the photometric function of the surface is well > understood, how do you correct for the unknown response of detector? I understand that complicated professional software like ISIS, which I have not actually used, allows for such corrections. It also allows adjustment of the image for the reflectance of varying lunar surface materials. However, for many lunar features accessible by amateurs, a reasonable approximation of height can be obtained using the simple Carlotto algorithm. If scientific accuracy is a concern - as opposed to just doing a 3-D rendering to get a better 3-D feel for a small lunar feature - you can do supplemental traditional shadow analysis and corroborate the SFS digital elevation model heights. If two techniques give a similar height, non-linear detector response can be ruled out as an artifact in the digital elevation model. The GLR Group people - particularly in Wohler's journal literature papers - have shown that by using a less complicated alogrithm than the Kirk-ISIS model on lunar features without all such adjustements - you can get a similar accuracy in estimated elevations of a feature. The Carlotto algorithm used in Evans' spreadsheet is computationally even simplier than Wohler's method. Using software packages like AIP4WIN, you can characterize the response of your CCD camera to determine if the chip responds in a linear manner. Exposures should then be made so the pixel levels are in the linear response range. Most modern CCD detectors have a linear response below a certain saturation value. Again, validation of SfS techniques by the GLR Group, as shown in various issues of _Selenography Today_, seem to indicate that this is not a problem in practice. A slighty related problem is saturation of pixel values in the lunar image. If any of the pixel values involve saturated bright spots - think Mons Piton on a mare - or deep uniformly black shadows in a crater - there is no slope information in those parts of the image and the SFS DEM will not accurately render elevation. > Question 7 : Does the spreadsheet correct for photometric > non-linearity in the detector? No, see the answer to the previous question. > Question 8 : Does one really need to work on a complete > two-dimensional matrix of intensity values, or, if one only wants > one profile through a feature of interest, is it equally valid to work > on a single row, as described in the hypothetical example given > above? Yes, one can only work with one row and generate an elevation line-of-sight profile through the feature. If you look at any of the many SfS articles in issues no. 1 and 3 of _Selenology Today_, you will see that in additional to 3-D wire-frame mesh renderings of features, authors typically include vertical line-of-sight profile charts (a.k.a. vertical slice charts) through the feature's maximum elevation. My spreadsheet implementation supports this function with a scratch-pad working sheet labeled "VerticalDEMSlices-ScratchSht". Note on the main workflow page (worksheet "WorkflowMenu"), once an SfS DEM is generated, the spreadsheet displays the minimum and maximum elevation in the DEM as a statistic. Then you can go to the worksheet labeled "DEM" and use Excel's find function to find that value in your DEM. From there one can determine the best vertical slice row or column that best represents the line-of-sight elevation profile of the feature. A static copy of that row or column is then copied to worksheet "VerticalDEMSlices-ScratchSht" and a line-of-sight elevation profile chart is generated using the normal Excel chart menu option. However, being able to visually scan the data in the DEM table greatly helps to select the correct row or column to turn into the line-of-sight elevation profile. It's easy to pick a wrong row or column that does not contain the feature's maximum elevation. Although you can work only with elevation profiles, line-of-sight vertical slice charts are pretty boring from an asthetic lunar imaging perspective. Personally, I get much more out of being able to use the 3-D VRML rendering of the DEM in study mode. With the 3-D VRML rendering, you sort of get your own personal, albeit virtual, spaceship to fly around 20km of the Moon's topographical surface. 3-D rendering is a good supplement - and I stress the word supplement as opposed to a substitute - for the more pleasing view seen at the eyepiece. The 3-D rendering gives one a good feel for physical 3-D relationships within a small feature or between two or three small features seen in the eyepiece. > Question 9 : If one needs to enter only the intensity values along > a single row, could not the row of data go down the > spreadsheet (filling a single column) instead of across it, > so that there would be no limitation on length? Yes, whether you use a row or column to generate the line-of-sight profile depends on the topography of the scene - particularly where there are multiple features in a scene. In some scenes, a row line-of-sight elevation profile gives the best sense of the feature. In others, a row column line-of-sight profile best tells the story of the feature. You have to look at the DEM data and make a selection based on judgment. In Wohler's article in issue no. 3 of _Selenology Today_ on Rupes Burg, he plots five or six vertical slices in one chart to give the reader a feel for how the terrain changes with distance. > Question 10 : Is there some simple mechanism for extract pixel > intensities along a single row of a JPEG (or other) image for > entry into the spreadsheet? Yes, I have been discussing that problem in a thread in the AIP4WIN group under the thread "Make an NxM matrix from a FITS image". The results of that thread and best software solution search are listed on my SfS Excel development page at: http://members.csolutions.net/fisherka/astronote/Photometry/SFS/SFS.html The best no-cost software solution as of the winter 2006-2007 appears to be a governmental astronomical freeware package, distributed by NASA's High Energy Astrophysics Science Archive Research Center (HEASARC), called "FV" - short for "FITS Viewer." FV is a FITS file viewer and editor that runs under Windows, Unix and MacOS. Conversion of a FITS file to text data is self-explanatory and requires no special user tips. Once a FITS file is open, there is a menu option to view the image and a second option to view the image as a table of pixel values. Once in table viewing mode, there is an option to save the file as a csv text data file. http://heasarc.gsfc.nasa.gov/docs/software/ftools/fv/ http://heasarc.gsfc.nasa.gov/docs/software/ftools/fv/fv_download The resulting csv data file can be directly opened by Excel and the result pasted into my DEMCarlottoMethod.xls's DEM analysis spreadsheet at worksheet "ImagePixelValueMap". My implementation of the Evans-Carlotto spreadsheet works directly on this data. Once the csv file is in Excel, you can pick and choose an individual row or column of image pixel values as needed. The user manual for the FV Tool states that you can select and individual row or column or a small rectangle within an image, and just output the csv for the selected sub-region. I haven't tried it yet, since must of the images I worked with are pre-cropped using an astronomical image processing software into about 100 rows x 100 columns or less. Another limitation that you should be aware of is Excel's 256 column limit. If you have an 1000 x 1000 pixel image, Excel can only import a strip of 256 pixel-columns. > you may wish to more thoroughly test it on a variety of > photos of lunar features with known slopes and > check that it reproduces those slopes correctly. I have run it against several of the raw Excel data files and images distributed by Rick Evans as part of his article in issue no. 1 of _Selenography Today_. My implementation replicates Evans' summed incidence maps. At this point, I have convinced myself that the spreadsheet is computationally correct, sufficient for pre-alpha release to the advanced "lunie" community. If it wasn't, I would not have issued an announcement. I was kinda of hoping that you and others in this newsgroup would do that part - testing on other lunar features. -:) For example, on 2/27/2007 at an early morning North American 8 UTC hour, LTVT is showing the Hortensius dome field catalogue illuminated by ideal low altitude (5 degrees) and azimuth (90.46 degrees). Using the LTVT Moon Event Predictor feature in Sun-Altitude mode, for my W111.8 observing point, the next favorable time that the Hortensius domes favorably will be illuminated from az 270 degrees is 7/9/2007 UTC 13:02:29, solar alt 3.4496, solar az 270.6285, Moon LH alt 54.230. At 3/1/2007 at 6 UTC, several domes near Marius R will be favorably illuminated at in 6.5 deg solar altitude light from my W111.8 op. 3/1/2007 04:59:59 UTC, solar alt 6.4151, solar long 91.7598, Moon LH alt 65.006. Again using the LTVT Predictor in Sun-Altitude mode, the next favorable illumination for this dome field from 270 degrees is 9/7/2007 19:28:53 UTC, solar alt 6.4151, solar az 268.1391, Moon LH alt 54.082. Technically, the Marius dome field is outside the constraint that features should located in a box of +- 30 degrees lunar latitude and longitude. But, for practice purposes, this field is probably a good target for properly shaded dome features, as long as you understand that the final DEM results may be off. If scientific elevation accuracy is a concern, one corroboration techinque is to make two SfS DEM models: one from an imaged illuminated from near a east solar azimuth 90 degree illumination and a second near west solar azimuth 270 degree illumination. In theory, the two DEMs should match or be very similar. > I think that in addition to providing a more thorough explanation of how people are actually supposed to use the spreadsheet, . . . A user guide is in the works. As noted at the top of this post, there are just three steps labeled 1, 2 and 3 on the worksheet "WorkflowMenu". What the spreadsheet does is compute a DEM and create a series of text files containing "triples" - x, y and z points - that can be used in other software to view your DEM. Two VRML files are created - an elevation grid and a 3-D floating point grid. A file of real x, y and z 3-D DEM points are generated in csv format for importation into the spreadsheet or math analysis program of your choice. I am also in the process of adding the image data for five or six examples used by Evans in his 2006 article into the distributed version. That will give people some inage data to play with. Now you've gone and made me write a draft chunk of the user guide in a usenet post! -:) > Keep up the good work! Thanks for the encouragement. Best wishes - Kurt