Help - Search - Members - Calendar
Full Version: shape from shade
Unmanned Spaceflight.com > EVA > Image Processing Techniques
Pages: 1, 2
JohnVV
So that i do not take over his nice thread i figured i would start a new one
I am just figuring it out so bear with me
Rhea
This is a example - very early example
http://www.shatters.net/forum/viewtopic.php?f=5&t=15847

one that i am going to redo .
the program i am using "Cyclops" has a few bugs

Enceladus
this is a good example a bit better than the above



the close ups are a 8k level 3 VT with and without a texture over it
then a 4k level2 vt

unfortunately i still have to figure out a bug .I need to run a highpass on it ( the 32 bit isis dem )
Cyclops exports to a 3d *.ply this is easy to export to a isis cub
and i get this ( this happens when i combine 16 smaller images into one big one )
and this example is at 1/2 size


Just a bit of a bug !!!

JohnVV
making progress
started with N1500060254_2.img

remapped to simpcyl.

the Bump also remapped

and some screenshots

it is starting to look like it is going to work
4th rock from the sun
Nice bump maps !

I have already suggested something similar for radar images and I understand the problems involved (echo delay). Nevertheless, could you use the software on a radar image let's say of Venus or Titan just to see what comes out ? Perhaps a Titan lake so that we have a level surface for reference. Would the result be completely unusable? Will the terrain be so shifted from reality that it's complete nonsense? I think it's worth exploring.
JohnVV
right now i am working on Dione i have a list of files used to make the map on PDS and using that as a starting point
this dose take a long time to process but an example
( the bump map is converted to a 8 bit RGB form the 16 bit .gray image )
N1481767211_2.img

and the bump


about Venus ????? I do not know
i did do a 32768x16384 normal map for celestia ,but...
there are a few errors in it that i DO know about
a screen shot of it
http://celestiamotherlode.net/catalog/imag...n_van_Vliet.jpg
i used an auto inpainting tool ( from the same person who inpainted the Russian venera images, just updated code. )
and then a lot of hand editing
JohnVV
just an update
this is a TESTING only 100% auto tools in isis . this is what i have so far
There is still a lot to do
a 1 k resize of the 8k image
Click to view attachment
Bjorn Jonsson
This looks very impressive, there is some loss of resolution but not much and in contrast to most of the SFS algorithms I have experimented with you get good and recognizable results. As a matter of curiosity, which one of Cyclops' SFS algorithms are you using? One of Haines' algorithms?

It would be interesting to see what your Cassini ISSNAC Cyclops 'camera file' looks like even though creating one myself shouldn't be difficult.
JohnVV
hi Bjorn
at this point i am just using a default "cam"file
CODE
<?xml version="1.0"?>
<function><poly power="1" mult="1"/></function>

and Haines &Wilson 2

i am tossing out too much data right now, for this to matter much .I am not great in words ,so some photos
a crop of N1507742440.img


i run hw2

get this ( a type of normalmap)
Click to view attachment
do to reasons of the way cyclops ( and normal maps work) there is a bit of a bug ( for this anyway - i am doing something the program was not designed for )
i need to do a HighPass in gimp ( i use G'mic)
Click to view attachment
cyclops outputs a Stanford.ply file this i convert to a obj ( it is a text based 3d format) and can be edited in Open-Office/Calc
and exported as a ascii raw image
the NOT hipassed needlemap
Click to view attachment
the 3d mesh is on an angle ( see the next post for the blender SS's )
and the highpassed and exported/then imported into isis
Click to view attachment
this one is flat in blender
also as you can see there is still an error
the top and bottom of the creator rinr is not seen
and the left and right side of the floor ( near the ring) is to deep
that i have been fixing in CinePaint

there is still an error the chevron stripes in the first post above
http://www.imagebam.com/image/efe40b75325671
not too well seen in this one
Click to view attachment hi-pass Click to view attachment
JohnVV

only 3 show so a link to the photo album
http://www.imagebam.com/gallery/4b4122b9b7...991f649094aac3/
the first
1) is in blender with z *3 exaggerated x3 of the highpassed needle map
2) same but diff angle
3) same 3d mesh but a "front view"
4) a "top view" of the same
-- the next 3 are the NOT high passed needle map --
5) front view ( the mesh is on an angle and would need "hand" "flattening" for every image - none would match up for a mosaic ) and some meshes ( not shown ) have a VERY,and i do mean a VERY big curve in them do to the lighting on the moon - a highpass is also needed to remove that
6)top view
7) and angled view


at this point i am not too worried about the scientific accuracy as to being able to get something that dose look nice
THEN i will see about getting it accurate
Bjorn Jonsson
I have now tested Cyclops a bit. The first test run resulted in a crash (no surprise there) but I'm now getting something that makes at least some sense. The next step is to write a small utility that uses the viewing geometry information in the IMG/index.tab files to output accurate values to use for "To Light" (the values I have used do not make a lot of sense).

This may be a stupid question but how did you export to a .ply file? The only output I was able to get was a BMP file.

Actually I'm getting the impression that the Windows version I'm using has somewhat less features than the Linux version, this is a screenshot:

Click to view attachment

A bit fewer buttons etc. than in the Linux Cyclops screenshot earlier in the thread.

QUOTE (JohnVV @ Apr 7 2010, 04:03 AM) *
unfortunately i still have to figure out a bug .I need to run a highpass on it ( the 32 bit isis dem )
Cyclops exports to a 3d *.ply this is easy to export to a isis cub
and i get this ( this happens when i combine 16 smaller images into one big one )
and this example is at 1/2 size


Just a bit of a bug !!!

Actually I'm not sure this is a bug - the surface is 'curved' if the source image(s) is not a very hi-res res. It might be possible to 'convert' the output to altitude relative to the target body's radius instead of the 'depth' that Cyclops outputs if I understand everything correctly (or have you already done this?). However, I suspect this wouldn't work very well because low frequency features are usually inaccurate in SFS. So I suspect I'll end up doing the same thing you did (high pass filter) and/or combining the SFS output with a DEM derived from stereo pairs. Another contributing factor might be inaccurate values for "To Light" - that's something I'll be testing once I have accurate values to use for "To Light". I'm curious to see how sensitive the SFS algorithms are to errors in the light source direction.
JohnVV
i am calling it a "bug" because i am doing something with the program it was not fully intended to do
and i am still learning it

The stripping is do to the G'mig highpass in gimp
if i do a highpas in isis ( 3 of them R,G,and B )
or use the nip2 fft Gaussian highpass ( must be a power of 2 image - 1024,512,256,square image)

it dose not show up but the results are worse

calculating the "direction to light source" from the isis kernel and IMG data is a good idea
I was going to look into doing that on the next map .For know i am "taking a guess" .Seeing as some of the dione images have a radial lighting to them ( do to how the light falls on the sphere )
Click to view attachment
then there is the changing "height of the light source
in the sfs window there is the x.y.z for the light source i have been finding that i get better results when the light is coming from ~ aprox. 1.0 0.5, 1.0
but some images ( do the the shape of the sphere ) have a big change in lighting
" change in z " -- these are Approx. --
Click to view attachment

-- as to --
QUOTE
This may be a stupid question but how did you export to a .ply file? The only output I was able to get was a BMP file.

the sfs dose output bmp
A second program is needed to convert that normal map to a .ply
integration
Click to view attachment
i can not run cyclops on Arch linux ( only on CentOS 5.4 ) so i can not use a shot of mine

then the fun part converting the .ply to a isis.cub
i use blender set the z location to 0.5 the z exaggeration to 3.0( but this is after i highpass the normalmap ) and export to a .obj
an .obj is a text format
CODE
# Blender3D v249 OBJ File:
# www.blender3d.org
v -0.639823 0.519523 0.632565
v -0.629778 0.519021 0.632603
v -0.619747 0.518432 0.632637
v -0.609672 0.518119 0.632681

the 3'd colom 0.519523,0.519021,0.518432 is z
import it into calc ( excel )and export the colum only
ascii2isis gives a 32 bit float image then isis fx to convert it to a normalised unsinged 16bit
fx eq
(( f1-"min value" )/ "max - min values") * 65538

QUOTE
Actually I'm getting the impression that the Windows version I'm using has somewhat less features than the Linux version

yes and NO
i built the google cvs code ( updated in feb 2010) the prebuilt was updated in 2008
http://code.google.com/p/hyperion-cv/source/checkout
JohnVV
while i am starting to put together an ISIS control net for dione
i was thinking of posting the isis bump map cub files
reimported back into isis from the sfs program
like this one ( but this is an rgb.png and not a isis.cub )
N1507742440.img
Click to view attachment

if any wants them i can post rapidshare or p2p( i like oneswarm )
Bjorn Jonsson
QUOTE (JohnVV @ May 3 2010, 04:33 AM) *
if any wants them i can post rapidshare or p2p( i like oneswarm )

I would certainly be interested in this.

I'm now getting very promising results from Cyclops. The goal now is an 8K (or maybe 16K) global DEM of Rhea by combining SFS and stereo.
JohnVV
at the end will be a link to the folder
newbump.tar.bz2
all isis 3 cub's are re-imported back into isis after spiceinit
a file list of pds images
CODE
│   ├── N1481738274.cub
│   ├── N1481738371.cub
│   ├── N1481738450.cub
│   ├── N1481738546.cub
│   ├── N1481766854.cub
│   ├── N1481766978.cub
│   ├── N1481767088.cub
│   ├── N1481767211.cub
│   ├── N1496883311.cub
│   ├── N1496883812.cub
│   ├── N1496883920_1.cub
│   ├── N1501604957_1.cub
│   ├── N1507733604_2.cub
│   ├── N1507733748_2.cub
│   ├── N1507733914_2.cub
│   ├── N1507734092_2.cub
│   ├── N1507734234_2.cub
│   ├── N1507738278_2.cub
│   ├── N1507739154_2.cub
│   ├── N1507739313_2.cub
│   ├── N1507739473_2.cub
│   ├── N1507740382_2.cub
│   ├── N1507740542_2.cub
│   ├── N1507740839_2.cub
│   ├── N1507740982_2.cub
│   ├── N1507741140_2.cub
│   ├── N1507741300_2.cub
│   ├── N1507741460_2.cub
│   ├── N1507741620_2.cub
│   ├── N1507741809_2.cub
│   ├── N1507742295_2.cub
│   ├── N1507742440_2.cub
│   ├── N1507742601_2.cub
│   ├── N1507742761_2.cub
│   ├── N1507742919_2.cub
│   ├── N1507743058_2.cub
│   ├── N1569814652_1.cub
│   ├── N1569814805_1.cub
│   ├── N1569814968_1.cub
│   ├── N1569815121_1.cub
│   ├── N1569815285_1.cub
│   ├── N1569815436_1.cub
│   ├── N1569815593_1.cub
│   ├── N1569826692_3.cub
│   ├── N1569827462_1.cub
│   ├── N1569827571_1.cub
│   ├── N1569827692_1.cub
│   └── N1569827799_1.cub


all images are 16 bit unsigned 1024x1024 px.
http://www.zshare.net/download/75772595b578fbe9/
JohnVV
five more and most likely the last until i find what is missing
DioneBump2.tar.bz2
http://www.zshare.net/download/75849188ad61eae2/
CODE
N1569826794.cub
N1569828025.cub
N1569828482.cub
N1569827906.cub
N1569828360.cub

same as above 16 bit unsigned 1024x1024 -with spiceinit
Bjorn Jonsson
Thanks - I'll take a look at these files soon.

I've been doing some experiments, including testing all of the SFS algorithms in Cyclops. Haines & Wilson 2 is by far the best one, at least for this type of scene. Some of the other algorithms result in something totally unrecognizable.

Rather unexpectedly, I usually get worse results using the correct light direction than I get by simply guessing it by looking at the image. This is probably because the DEM gets more 'tilted' in this case if the image footprint isn't near the center of the disk. Image N1507742440_2.img of Dione is a nice example, the correct direction to the sun is (0.303693, -0.205793, 0.930279) but I get a better DEM using (1.0, 0.5, 1.2) as in the screenshot earlier in the thread ( http://www.imagebam.com/image/6a107e78124092 ). If getting the correct direction to the sun for more images is of interest I can post it here.

BTW exactly how do you high pass filter the needle maps in Gimp/G'mic? I tried Photoshop's high pass filter with bad results - it somehow seems to 'destroy' the needle map. I get recognizable results but still bad (for one thing, too shallow craters relative to everything else regardless of the filter radius I use). High pass filtering the DEM I get when converting the obj files works well in some cases though if I didn't high pass filter the needle map. I took a very quick look at G'mic but didn't find anything that worked well.

The next step is to install ISIS and try SFS (pc2d) there now that I have a working Windows/Linux dual boot.
JohnVV
first the gimp Gmic filter( was called Graystration ) and is also in the CImg.h
this filter is a bit on the "odd "side .It dose things a bit differently than other filters .
It uses a PDE for heat flow ( diffy-Q's are fun)

http://cimg.sourceforge.net/

http://gmic.sourceforge.net/gimp.shtml

and it is a frequency splitting plugin
the top layer in the image becomes the LOW ferq. and the bottom layer is the HI freq.
Click to view attachment
Click to view attachment
Click to view attachment
i use a setting of 20 for the split
but this filter is also causing the chevron strips , so... at the end i need to remove them .

then i import that "hipass" into cyclops

as to the direction of the light i was doing this ( a bit wrong)
Click to view attachment
now this is working better
Click to view attachment

i really should go and send off a mail to ' Tom SF Haines '
JohnVV
a bit of a change - the below will create a "good looking" bump image BUT NOT one that is scientifically accurate

someone i look up to - who dose very good work is having a bit of a problem
{ this reminds me - i still need to mail the creator of the program - for some advice}
cyclops is a bit of some "odd" software and i am doing something with it that it was not 100% meant to do
and to solve one problem i am adding another problem .
-- a bit of my background --
10+ years in the photo darkroom doing pro and fine art photofinishing ( i see things a bit differently than others )
then add to it about 10 years on the computer learning "image restoration " and "inpainting" software
- do not get me started on "csi and ncis" shows

--------------------
a tutorial over the next few posts
-------------------
i will start with a dem i posted last night
i am using a crop of N1514126616_1.img ( pds - dione )
Click to view attachment
something familiar

1)
there is a bug in using and building cyclops using very new OS
i think it is in glib or libIl( now DevIl ) . But i have not tract it down
it DOSE build on RHEL 5 just fine ( well i use CentOS 5.4 )
for some reason it tosses a "can not open image " on very new os's ( arch and fedora,and i am told Ubuntu also)

i have ran into problems like this before so that is why i have Cent installed along with Arch ( stereo pipline ( isis3) also dose not run in Arch ,but dose work fine in CentOS 5.4
-- so i will go and boot into cent and finish this part

as you can see in the crop above there is some lighting caused by the moons spherical shape ( low res image / wide angle )
the sun is to the left about centered
Click to view attachment

i am using h&w2 ( seams to work the best for this )
the settings i am using are in the screenshot
-- run it --
Click to view attachment

this is a normal map ( most will see that )
now there is a LOT of curvature in this image
-- for show in blender --
top
Click to view attachment
side
Click to view attachment

JohnVV
2)
removing the curvature
yes one or two meshes can be done in blender
but not for 80+ images
i have tried a few different "hipass " filters
removing the low frequency part of the normal map will "flatten" a mesh

and the one i found that works the best ( so far ) is G'Mic on Gimp
(see the above posts )
Click to view attachment
setting of 10 ( out of 1 to 20 )
Click to view attachment

UNFORTUNATELY the gimp filter CAUSES a bit of repeating noise
The chevron strips

and this will need to be fixed later
( i am still looking for a better solution than this ,it is not a solution but a "work around " )
Sajid
Interesting work you are doing.

Where did you find this cyclops software? The only place I saw was an old and empty website with basically a download link and some cryptic documentation listing function calls.
JohnVV
3)

convert the hipassed normal to a mesh then to a dem
Click to view attachment
this is how cyclops sees the hi-normalmap image from above
and it saves to a *.ply
import into blender
Click to view attachment
side view
Click to view attachment

export to a obj format mesh
the obj format is a ascii text format
.ply is a binary hex format
i use gedit to open it
( i need to wright a script that will do this and automate it , for a few it is not a problem but for 80+ so far it is becoming one )
Click to view attachment
and remove all the data i do not need
then in OO calc ( excel ) i extract the z access
-- be back i have a cat that wants on my lap--
back

the output of OO is a ascii text "raw" FILE
isis,openev, or your fav can import it

i use ascii2isis
Click to view attachment
the next step
cleaning this
JohnVV
4)
-- optional --
i like to normalize and convert this to a 16 bit unsigned image
fx
CODE
fx f1=d.hi.cub to=d1.cub equation=((f1-0.440323)/0.119344)*65536

for this image
then there are a few ways to take a highpass of this
in isis it makes a singed image
so i take a few steps

run lowpass on it (boxcar 101,101 )
Click to view attachment

and subtract it from the other in Nip and openev
isis.cub to a 32bit tif from openev
then use nip to convert the 32 bit tif to a 16 bit tiff
you can use whatever programs you are comfortable with
but highpass the image or subtract a lowpass


in nip
invert the low pass and "use nip's "blend"
Click to view attachment
Click to view attachment

there is still some cosmetic editing yet
but it is in very predictable spots
the crater rims are a bit low on the top and bottom
and the crater is a bit deep on the inside left and right
and it has a slight emboss look to it
JohnVV
an update
just a "testing " shot


with only a few of the images in it .
Bjorn Jonsson
Looks very promising despite the 'terraced' appearance in much of the image (a consequence of an 8 bit DEM?)

And big thanks for the information above. Thanks to it I identified an error late in my processing chain. After fixing it I'm getting very promising results but it is obvious that the best results are going to come from combining several approaches: Stereo, Cyclops and my primitive SFS software. I still haven't tried ISIS' pc2d. I may have to install CentOS to do so although I'm hoping to get ISIS to work under the version of Linux I'm running (Ubuntu).

Some interesting finds:

(1) I get *much* better results from Cyclops by visually estimating the light source direction instead of using the true direction. As an example, for image N1507742440_2.IMG of Dione the correct direction is (0.303693, -0.205793, 0.930279) but I get much better results using (0.5,0.2,0.6).

(2) Cyclops apparently doesn't like images with high solar elevation angles. This is not unexpected. The results are useful though but the quality is significantly worse than at lower solar elevation angles.

(3) Big craters are often too shallow in the resulting DEMs, requiring postprocessing in Photoshop (or combining the Cyclops DEM with a stereo DEM).

Two test renders:

The first one is a Cyclops DEM, the big craters are too shallow so it requires additional postprocessing but the really nice thing is that there are no visible artifacts like striping for example:
Click to view attachment

The second one is from my primitive SFS software after extensive postprocessing (mainly destriping). Small scale details are probably better than in the Cyclops DEM but the bad thing is that some striping is still visible:

Click to view attachment
JohnVV
QUOTE
Looks very promising despite the 'terraced' appearance in much of the image (a consequence of an 8 bit DEM?)

no, that is an artifact from a fast and not so good contrast bump on the low contrast map . At this stage i am not worried after all the screen shot is a 4096x2048 resize of the 16384x8192 map i am making .

QUOTE
As an example, for image N1507742440_2.IMG of Dione the correct direction is (0.303693, -0.205793, 0.930279) but I get much better results using (0.5,0.2,0.6).

for this image i am using this ( measurementsare on the image )
-- oops i miss typed --
Click to view attachment
from the center 0.2 up and 1.0 over( right ) and 0.5 out from the screen is the height
-- correction --
on the photo should be ( 1.0 ,0.2,0.5)
QUOTE
Big craters are often too shallow in the resulting DEMs, requiring postprocessing in Photoshop (or combining the Cyclops DEM with a stereo DEM).

i have seen that too , that is why i posted above ( a few posts) that i have been editing , by hand, the craters
there are very predictable spots that need help
Click to view attachment
also the second hi-pass is removing some of the depth in the hole but at the same time it is getting ride of the left to right slope
as seen in Nirgal's post
http://www.thethirdplanet.de/mars_gallery/...okrates_sfs.jpg
the one on the right is like the ply / normal map from cyclops , and that second hi-pass filter flattens the image .
-- i or we or all of us need to find a better solution --

but considering there is not much of a choice
the pc2d ( from 2004 )
-gimp-
shapefs-1.2.0.0-20051020.tar.gz ( this dos not work well and needs a very old version of gimp )
i have collected a few OLD things and they do build
linear.cpp
-- excerpt --
CODE
/****************************************************************************
NAME:   linear.cpp  --   Performs shape from shading using
                         linear FFT based algorithm

SYNOPSIS:  linear inImage inFmt sunElevAngle sunAzimAngle d -f fltFrq outFmt outDem

Example:  linear spot128.dat 2 19.3 287.2 2.5 -f 0 2 ts_dem.dat  

DESCRIPTION:   This program performs linear shape-from-shading

ALGORITHM REFERENCES:
   Liu, H. "Derivation of surface topography and terrain parameters
from single satellite image using shape-from-shading technique"
in Computers & Geosciences

BUGS:

Compiling on SGI:
CC -Ddebug=0 -g -o linear linear.cpp linear_sfs.cpp fft2d.cpp imageio.cpp stopwatch.cpp -LANG:std  -lm
Compiling on SUN:
CC -Ddebug=0 -g -o linear linear.cpp linear_sfs.cpp fft2d.cpp imageio.cpp stopwatch.cpp   -lm

or mini.cpp
CODE
/****************************************************************************
NAME:   mini.c  -   Performs shape from shading using minimization algorithm

SYNOPSIS:  mini inName inFmt sunElevAngle sunAzimAngle lamda iterNum -d initDemName outFmt outName

Example 1:mini spot128.dat 2 19.3 287.2 1.5 50  2 ts_dem.dat  

ALGORITHM REFERENCES:
  Liu, H. "Derivation of surface topography and terrain parameters
from single satellite image using shape-from-shading technique"
in Computers & Geosciences

Compiling on SGI:
CC -Ddebug=0 -g -o mini mini.cpp mini_sfs.cpp fft2d.cpp imageio.cpp stopwatch.cpp -LANG:std  -lm

Compiling on SUN:
CC -Ddebug=0 -g -o mini mini.cpp mini_sfs.cpp fft2d.cpp imageio.cpp stopwatch.cpp -lm

************************************************************/

the two above are from a zip called
v29-10-03.zip this was from a paper - google found the zip but not the paper
(h??p://207.176.140.93/documents/oldftp/VOL29/)

and then cyclops . So not to much of a choice here
in a few( or many,many) years there will be Nirgal's . If all the patent an IP issues can be solved
4th rock from the sun
I've programed a simple SFS implementation in Actionscript (Adobe Flash) and I'm surprised by the results.
The algorithm is as simple as evaluating brightness difference over two adjacent pixels and the making the terrain go up or down accordingly.
If I stick to non saturated original data and avoid completely shadowed areas, the resulting terrain is consistent.

Here's what I'm getting (left - original, right - elevation, both images contrast enhanced for posting):

Click to view attachment
AndyG
Very nice!

ActionScript, huh? Smarty-pants! rolleyes.gif

Is this adjacent pixels as in the nine around (or the four adjacent to) the target pixel, or are you processing the image in a raster-like manner?

Andy
4th rock from the sun
Thanks!

I'm reading the image as a raster and calculating pixel value differences along each row.
It's something like this:

difference= (pixelb-pixela)/60;
level=sin(difference)*2+level;

Of course, I'm assuming that the light comes from the left and the each row starts at the same level.

Given these limitations I'm surprised that it works at all!

JohnVV
the main problem has been with non optimal images
the crater and it's rebound cone is one of the best examples of a very GOOD image for sfs

JohnVV
just a bit of an update
stereo is by far better but

sometimes there are no useful stereo pairs
( and not much in single with shadows )

the Jupiter crowd will recognize this area of Io
Click to view attachment

just a test for right now
volcanopele
QUOTE (JohnVV @ Jan 31 2012, 10:04 PM) *
the Jupiter crowd will recognize this area of Io

What type of map is that? Bump, elevation? I am a little concerned about the material on the east side of Shamshu Mons appearing too high and some volcanic flows showing up southwest of Hi'iaka Patera.

Click to view attachment
JohnVV
a height map but that spot IS an artifact from Shamshu Patera
Click to view attachment
that test image is a merg of a full map and and a close up
there are still some problems it getting something that is in-between scientifically close to accurate ( io is not a good candidate ) and something that also looks nice

otherwise a height map for the full moon would be gray with a few spots of lighter gray
Click to view attachment
JohnVV
for now i have dropped the hyperionCV sfs in favor of the old "mini.cpp" from a few pages back
examples using the LRO-WAC stereo DEM
-- 16 bit gray data was normalized and converted to jpg
the topo crop

the ISIS3 "shade" tool set at 270Deg and 45 deg height

and the sfs from it with some pre processing in G'mic
JohnVV
just a update on a rather old thread
i was asked about using SFS
starting image of Ceres PIA21750
Click to view attachment

a 8 bit copy of the 32 bit float image
Click to view attachment

and a hillshade using GDAL
Click to view attachment

yes i am using the same old mini.cpp
-- link
https://drive.google.com/file/d/1v_y_rmCC6p...iew?usp=sharing

contains the original readme and the paper in pdf format along with the PIA21750 image
REQUIRES g++3.3 to build !!!

i also use a bash script to automate the multi resolution i use
a 1024x1024 , a 512x512,a 256x256 and a 128x128 images
this script uses
GDAL and G'Mic ( the TERMINAL VERSION of gmic)
CODE
#!/bin/bash

gmic PIA21750.pgm -resize 128,128 -split_freq 10% -n[1] 0,1 -o[1] 128.tif
gmic PIA21750.pgm -resize 256,256 -split_freq 10% -n[1] 0,1 -o[1] 256.tif
gmic PIA21750.pgm -resize 512,512 -split_freq 10% -n[1] 0,1 -o[1] 512.tif
gmic PIA21750.pgm  -split_freq 10% -n[1] 0,1 -o[1] 1k.tif

gdal_translate -of EHdr -ot Float32 128.tif 128.raw
gdal_translate -of EHdr -ot Float32 256.tif 256.raw
gdal_translate -of EHdr -ot Float32 512.tif 512.raw
gdal_translate -of EHdr -ot Float32 1k.tif 1k.raw

mini_sfs 1k.raw 2 35 95 2 66 2 c_dem
gmic c_dem1.raw,1024,1024 -split_freq 3% -n[1] 0.1,0.9 -o[1] 1kc.tiff

mini_sfs 512.raw 2 35 95 10 125 2 512_dem
gmic 512_dem1.raw,512,512 -resize 1024,1024 -blur 3 -split_freq 4% -n[1] 0.05,0.95 -o[1] 1k_512.tiff

mini_sfs 256.raw 2 35 95 10 200 2 256_dem
gmic 256_dem1.raw,256,256 -resize 1024,1024 -blur 4 -split_freq 5% -n[1] 0.05,0.95 -o[1] 1k_256.tiff

mini_sfs 128.raw 2 35 95 25 600 2 128_dem
gmic 128_dem1.raw,128,128 -resize 1024,1024 -blur 5 -split_freq 6% -n[1] 0,1 -o[1] 1k_128.tiff

gmic 1kc.tiff 1kc.tiff 1k_512.tiff 1k_256.tiff 1k_128.tiff -blend add -div 5 -n 0.1,0.9 -o HeightMap.tiff

gdaldem hillshade -z 40 -az 95 -alt 35 -compute_edges HeightMap.tiff hillshade.tiff

# this line below can be undocumented after a good test
# rm 128.tif 128.hdr 256.tif 256.hdr 512.tif 512.hdr 1k.tif 1k.hdr 128.raw 128_dem.hdr 128_dem1.raw 256.raw 256_dem.hdr 256_dem.hdr 256_dem1.raw 512.raw 512_dem.hdr 512_dem1.raw 1k.raw  1kc.tiff 1k_512.tiff 1k_256.tiff 1k_128.tiff c_dem.hdr c_dem1.raw 128.raw.aux.xml 256.raw.aux.xml 512.raw.aux.xml 1k.raw.aux.xml


now this is important !!!
the way i make the height map looses ALL real height information
only the RELATIVE data is there . If it looks twice as high and something in the image it is likely about twice as high but there is NO height in meters information
TrappistPlanets
QUOTE (JohnVV @ Apr 17 2012, 10:03 AM) *
for now i have dropped the hyperionCV sfs in favor of the old "mini.cpp" from a few pages back
examples using the LRO-WAC stereo DEM
-- 16 bit gray data was normalized and converted to jpg
the topo crop

the ISIS3 "shade" tool set at 270Deg and 45 deg height

and the sfs from it with some pre processing in G'mic

why does the 2 sides of the crater rim SFS dem look higher then everything else but in the real offishal dem everything on the rim is about the same height?
TrappistPlanets
i have a SFS dem of umbriel
TrappistPlanets
sorry that the attachemt was spammed, my computer or unmanned was glitching
and i was fighting my computer and it kept saying i didn't choose a file to upload and for some reason my attachment spammed when i posted when it finally said it was successful with uploading the attachment
JohnVV
QUOTE
why does the 2 sides of the crater rim SFS dem look higher then everything else

this is how the program works
the areas that are tangent do not pick up the height data very well

this causes the " valley" effect in the direction of the lighting

this is one of the drawbacks of using SFS

now using gmic to remove most of the low frequency data this is somewhat improved ,but not eliminated

there is still no really GREAT solution to this issue


SFS is still a problem to be solved
TrappistPlanets
QUOTE (JohnVV @ May 12 2021, 06:47 PM) *
this is how the program works
the areas that are tangent do not pick up the height data very well

this causes the " valley" effect in the direction of the lighting

this is one of the drawbacks of using SFS

now using gmic to remove most of the low frequency data this is somewhat improved ,but not eliminated

there is still no really GREAT solution to this issue


SFS is still a problem to be solved


i tried installing gmic before and it didn't work (like none of the plugin's options were appearing)
and i did install it correctly

is there a way to process height map from a diffuse texture 100% in gimp?
JRehling
QUOTE (JohnVV @ May 12 2021, 11:47 AM) *
there is still no really GREAT solution to this issue

SFS is still a problem to be solved


Indeed. And for a surface with unknown reflectance properties (e.g., an outer solar system body with very few images) not to mention albedo variation that is not due to illumination conditions, it's in principle an unsolvable problem.

A 2006 work, for reference:

https://ieeexplore.ieee.org/document/1640974
TrappistPlanets
a friend of mine processed this fantastic dem from one of the juno ganymede images

it captured all the little cracks and stuff very well

here is a map verson i made from that dem (fixed inaccurate elevation, and issues in some craters)
TrappistPlanets
QUOTE (Bjorn Jonsson @ Apr 29 2010, 10:26 PM) *
I have now tested Cyclops a bit. The first test run resulted in a crash (no surprise there) but I'm now getting something that makes at least some sense. The next step is to write a small utility that uses the viewing geometry information in the IMG/index.tab files to output accurate values to use for "To Light" (the values I have used do not make a lot of sense).

This may be a stupid question but how did you export to a .ply file? The only output I was able to get was a BMP file.

Actually I'm getting the impression that the Windows version I'm using has somewhat less features than the Linux version, this is a screenshot:

Click to view attachment

A bit fewer buttons etc. than in the Linux Cyclops screenshot earlier in the thread.


Actually I'm not sure this is a bug - the surface is 'curved' if the source image(s) is not a very hi-res res. It might be possible to 'convert' the output to altitude relative to the target body's radius instead of the 'depth' that Cyclops outputs if I understand everything correctly (or have you already done this?). However, I suspect this wouldn't work very well because low frequency features are usually inaccurate in SFS. So I suspect I'll end up doing the same thing you did (high pass filter) and/or combining the SFS output with a DEM derived from stereo pairs. Another contributing factor might be inaccurate values for "To Light" - that's something I'll be testing once I have accurate values to use for "To Light". I'm curious to see how sensitive the SFS algorithms are to errors in the light source direction.


sorry if this is nacroposting
Bjorn, were can i go to get/try this "Cyclops" shape from shading program?

JohnVV
QUOTE (TrappistPlanets @ Oct 18 2021, 04:48 PM) *
sorry if this is nacroposting
Bjorn, were can i go to get/try this "Cyclops" shape from shading program?

i first started using it
However it was a phd thesis program and not really ready for " prime time"
it worked for what the person needed but that was about all

and it is NOT in development

i think it was on github, i am looking right now and i can not find it

added later

found it
https://github.com/thaines/hyperion

but you will have to build the code yourself
TrappistPlanets
QUOTE (JohnVV @ Oct 19 2021, 02:22 AM) *
i first started using it
However it was a phd thesis program and not really ready for " prime time"
it worked for what the person needed but that was about all

and it is NOT in development

i think it was on github, i am looking right now and i can not find it

added later

found it
https://github.com/thaines/hyperion

but you will have to build the code yourself


i don't know how to compile programs vea code, as i never done that before
so how do i do it, and will i even work on windows (32 bit)?
JohnVV
QUOTE
i don't know how to compile programs vea code, as i never done that before
so how do i do it, and will i even work on windows (32 bit)?

TrappistPlanets i would first start by building Celestia , but this is not the forum for that discussion

once that works then there is a "build_all.bat" in the source
that you might need to edit ?? maybe

that MS Windows bat file is a batch file to build the program
however i stopped using MS Windows back when XP was still the flag ship OS and i am very rusty on things Microsoft

pm me here and on the celestia forum and we should be able to get this up and running for you

JRehling
QUOTE (TrappistPlanets @ Jun 10 2021, 04:37 AM) *
a friend of mine processed this fantastic dem from one of the juno ganymede images
[...]
it captured all the little cracks and stuff very well


This isn't a DEM, and didn't capture Ganymede very well. Ganymede has tremendous variation in albedo and creating a bump map from that (which is a one-minute project in Photoshop) produces something which is largely fiction. Crater rays aren't cracks nor are they elevations, nor do the transitions from darker terrain to grooved terrain translate to regional depressions or elevation.

Moreover, the sun angle obviously varies profoundly across the image, with shadows nearly perpendicular at the terminator and almost overhead at the center of the limb. This effort would only be meaningful if the sun angle were approximately constant when it's about as different from constant as imaginable. Projecting this onto a cylindrical map makes it look like Ganymede has one rough area and another smooth area and that is total fiction.

There is plenty of data from previous missions that would enable a more complex process that would produce what this aspired to produce, but this isn't it.

There are multiple skilled image processing experts who post here and produce amazing, publishable work, but it's not easy, and there's a lot to learn from the care they put into their work.
TrappistPlanets
QUOTE (JRehling @ Oct 21 2021, 05:32 PM) *
This isn't a DEM, and didn't capture Ganymede very well. Ganymede has tremendous variation in albedo and creating a bump map from that (which is a one-minute project in Photoshop) produces something which is largely fiction. Crater rays aren't cracks nor are they elevations, nor do the transitions from darker terrain to grooved terrain translate to regional depressions or elevation.

Moreover, the sun angle obviously varies profoundly across the image, with shadows nearly perpendicular at the terminator and almost overhead at the center of the limb. This effort would only be meaningful if the sun angle were approximately constant when it's about as different from constant as imaginable. Projecting this onto a cylindrical map makes it look like Ganymede has one rough area and another smooth area and that is total fiction.

There is plenty of data from previous missions that would enable a more complex process that would produce what this aspired to produce, but this isn't it.

There are multiple skilled image processing experts who post here and produce amazing, publishable work, but it's not easy, and there's a lot to learn from the care they put into their work.

but than why haven't we seen bigger DEM chunks than really tiny hunks for Ganymede (and Callisto( even fewer for Callisto)) in papers, but for Triton we have most of the cantaloupe terrain (for the approach hemisphere) height mapped, and we have a good chunk of the southern regions height mapped to (all though unreliable), according to this paper, there is plenty of usable PC DEM coverage and stereo DEM coverage (although its not going to be in the best resolution)

for callisto there is this blurry DEM from MexLab geoportal
(someone turned it into a 3d model and i processed it back into a DEM)
Click to view attachment

but it could be better though

does anyone know of any papers with significant stereo or PC DEM coverage that i haven't seen/found yet, because i am clearly missing something.
JRehling
QUOTE (TrappistPlanets @ Oct 21 2021, 04:10 PM) *
but than why haven't we seen bigger DEM chunks than really tiny hunks for Ganymede


Possibly nobody finds DEM chunks a really valuable thing to produce. Someone interested in the science of Ganymede's geology can do work like this without trying to publish a map.

https://www.sciencedirect.com/science/artic...019103510003945

QUOTE (TrappistPlanets @ Oct 21 2021, 04:10 PM) *
for callisto there is this blurry DEM from MexLab geoportal


Again, this is not a DEM. You seem to think that every bump map generated from albedo is a map of elevation. The bright spots on Callisto are craters with bright subsurface material revealed. Using that brightness to produce a map of elevation is pure fiction.

A bump map might happen to be very close to a DEM if a lot of conditions were being met which are not being met in the cases you're playing around with. Eg, fixed albedo, constant illumination geometry, a Lambertian surface or one with minimal specular properties under the given illumination conditions. When those conditions aren't being met, you get a work of fiction.
TrappistPlanets
QUOTE (JRehling @ Oct 22 2021, 12:24 AM) *
Possibly nobody finds DEM chunks a really valuable thing to produce. Someone interested in the science of Ganymede's geology can do work like this without trying to publish a map.

https://www.sciencedirect.com/science/artic...019103510003945



Again, this is not a DEM. You seem to think that every bump map generated from albedo is a map of elevation. The bright spots on Callisto are craters with bright subsurface material revealed. Using that brightness to produce a map of elevation is pure fiction.

A bump map might happen to be very close to a DEM if a lot of conditions were being met which are not being met in the cases you're playing around with. Eg, fixed albedo, constant illumination geometry, a Lambertian surface or one with minimal specular properties under the given illumination conditions. When those conditions aren't being met, you get a work of fiction.


http://cartsrv.mexlab.ru/geoportal/

thats where the original callisto "dem" came from (you haft to do some playing around to get to it, there is also a blurry europa, and Io "dem") before someone turned it into this model https://www.thingiverse.com/thing:3686246 witch i processed a "dem" from

how is DEM data not a viable thing, we need to know topography elevation, like if we wanted to land a probe on an object, we need to know its terrain and as much of its climate as possible?
JRehling
First of all, the standard of citing research is to provide an author name of a paper, not that there is a blurry image on a website for people to go looking for with no information about who created it (not "someone"), how their results may be duplicated, what data and method was used to derive it.

QUOTE (TrappistPlanets @ Oct 22 2021, 04:08 AM) *
how is DEM data not a viable thing, we need to know topography elevation, like if we wanted to land a probe on an object, we need to know its terrain and as much of its climate as possible?


And does a blurry image on a website that has none of the above information, hasn't been reviewed, and doesn't indicate what grayscale corresponds to what elevation help mission planners? Not a bit.

As far as I know, there are two different consumers of such products:

People who provide space art can use a DEM to generate a view of the world in viewing situations that have never actually occurred. We can easily do this with global DEMs of Mars, the Moon, etc. This is fun stuff… not particularly essential… but also depends on a pretty complete global map. With little fragments that cover a few percent, this doesn't work, unless you only want to show a little fraction of the world, which is also fun stuff, but not really a burning need.

People who do real science and want to know, as in the paper I linked to, how the geology of a world is evidenced in its topography, and those people want to know how tall a crater rim is vs. the floor. Not a blurry DEM that someone posted without any of the specific information that I listed above.

What you posted is a fiction. It shows that Ganymede is smooth in an area where it isn't smooth… it just had different illumination, in one image, on the limb than on the terminator. Who benefits from that fiction? It also shows changes in vertical elevation where bright crater rays exist. Who needs that fiction? Can someone planning a mission look at your image determine what grayscale corresponds to what elevation? Will they bet a billion dollar mission on that? No.

People aren't generating those because they're not valuable for any purpose. They aren't even real DEMs. You could just as easily apply the same Photoshop filter to the Mona Lisa and that won't generate a 3D version of a person's face, either.

Now an actual DEM where you began to take into account variation in albedo and the variation in illumination across a curved surface might be of some use. That's going to be vastly harder work to come up with than applying a Photoshop filter to an image. For starters, you have to understand that "shape from shade" only works when in the real world, shade is from shape; e.g., that variations in albedo and illumination geometry do not exist. Ganymede and Callisto are utterly disqualified from that category.

There's a lot of paying attention to detail that has to occur before products of value emerge. Then a lot of hard work. Those aren't steps to skip.
stevesliva
Just FYI... There was this other discussion: http://www.unmannedspaceflight.com/index.p...mp;#entry254805
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2024 Invision Power Services, Inc.