Help - Search - Members - Calendar
Full Version: shape from shade
Unmanned > EVA > Image Processing Techniques
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
This is a example - very early example

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

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 !!!

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.
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 )

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
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
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.
hi Bjorn
at this point i am just using a default "cam"file
<?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
not too well seen in this one
Click to view attachment hi-pass Click to view attachment

only 3 show so a link to the photo album
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/ 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.
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 --
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
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
# Blender3D v249 OBJ File:
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

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
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 )
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.
at the end will be a link to the folder
all isis 3 cub's are re-imported back into isis after spiceinit
a file list of pds images
│   ├── 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.
five more and most likely the last until i find what is missing

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 ( ). 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.
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)

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 '
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

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 --
Click to view attachment
Click to view attachment

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 " )
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.

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--

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
-- optional --
i like to normalize and convert this to a 16 bit unsigned image
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
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
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 .

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)
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
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 )
shapefs- ( this dos not work well and needs a very old version of gimp )
i have collected a few OLD things and they do build
-- excerpt --
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

   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 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
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  

  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 this was from a paper - google found the zip but not the paper

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
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?

4th rock from the sun

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;

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!

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

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
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
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
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
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

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)

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
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-2020 Invision Power Services, Inc.