Printable Version of Topic

Click here to view this topic in its original format

Unmanned Spaceflight.com _ Image Processing Techniques _ shape from shade

Posted by: JohnVV Apr 7 2010, 04:03 AM

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
http://www.imagebam.com/image/192b7f75046179
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
http://www.imagebam.com/image/cebae275324716 http://www.imagebam.com/image/caade575324719 http://www.imagebam.com/image/02279575324721 http://www.imagebam.com/image/9bcac075324723 http://www.imagebam.com/image/c3896c75324725 http://www.imagebam.com/image/31b35275324727


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
http://www.imagebam.com/image/efe40b75325671

Just a bit of a bug !!!


Posted by: JohnVV Apr 8 2010, 12:27 AM

making progress
started with N1500060254_2.img
http://www.imagebam.com/image/e9cd5175459549
remapped to simpcyl.
http://www.imagebam.com/image/e4efe075459550
the Bump also remapped
http://www.imagebam.com/image/b8ce7275459552
and some screenshots
http://www.imagebam.com/image/152d4975459554 http://www.imagebam.com/image/3bf2c575459556 http://www.imagebam.com/image/8b2b7c75459558 http://www.imagebam.com/image/882d7c75459559
it is starting to look like it is going to work

Posted by: 4th rock from the sun Apr 8 2010, 02:53 PM

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.

Posted by: JohnVV Apr 13 2010, 07:26 AM

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
http://www.imagebam.com/image/a9465976222729
and the bump
http://www.imagebam.com/image/8b804276222732

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/images/screenshots/various/venus_VT_Venus_Normal_Map_1__John_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

Posted by: JohnVV Apr 17 2010, 03:42 AM

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
[attachment=21419:1k.bumptest.png]

Posted by: Bjorn Jonsson Apr 27 2010, 12:41 AM

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.

Posted by: JohnVV Apr 27 2010, 03:58 AM

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
http://www.imagebam.com/image/5333aa78123960

i run hw2
http://www.imagebam.com/image/6a107e78124092
get this ( a type of normalmap)
[attachment=21489:crop.png]
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)
[attachment=21490:crop.hi.png]
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
[attachment=21491:crop16bit.png]
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
[attachment=21492:crop.hi16bit.png]
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
[attachment=21493:crop.strip.png] hi-pass [attachment=21494:crop.hi....ass16bit.png]

Posted by: JohnVV Apr 27 2010, 04:22 AM

http://www.imagebam.com/image/87738578125704 http://www.imagebam.com/image/a9019878125706 http://www.imagebam.com/image/e4cb4278125707 http://www.imagebam.com/image/a14be978125708 http://www.imagebam.com/image/4896e678125712 http://www.imagebam.com/image/e9610878125713 http://www.imagebam.com/image/f237fa78125714
only 3 show so a link to the photo album
http://www.imagebam.com/gallery/4b4122b9b7be7392c0991f649094aac3/
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

Posted by: Bjorn Jonsson Apr 29 2010, 09: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:




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
http://www.imagebam.com/image/efe40b75325671

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.

Posted by: JohnVV Apr 30 2010, 02:06 AM

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 )
[attachment=21524:N1507742601_2a.jpg]
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. --
[attachment=21525:N1481766854_1a.jpg]

-- 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
[attachment=21526:cyclops_win.png]
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

Posted by: JohnVV May 3 2010, 04:33 AM

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
[attachment=21548:N1507742440.hi.png]

if any wants them i can post rapidshare or p2p( i like oneswarm )

Posted by: Bjorn Jonsson May 4 2010, 02:28 PM

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.

Posted by: JohnVV May 6 2010, 06:16 AM

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/

Posted by: JohnVV May 8 2010, 08:42 PM

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

Posted by: Bjorn Jonsson May 8 2010, 10:27 PM

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.

Posted by: JohnVV May 9 2010, 04:02 AM

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.
[attachment=21575:enw_orig_crop.jpg]
[attachment=21573:Screenshot_1.png]
[attachment=21574:Screenshot_2.png]
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)
[attachment=21576:Screen2.png]
now this is working better
[attachment=21577:Screen1.png]

i really should go and send off a mail to ' Tom SF Haines '

Posted by: JohnVV May 13 2010, 06:42 PM

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 )
[attachment=21621:test.png]
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
[attachment=21622:Screenshot.png]

i am using h&w2 ( seams to work the best for this )
the settings i am using are in the screenshot
-- run it --
[attachment=21623:Screenshot_1.png]

this is a normal map ( most will see that )
now there is a LOT of curvature in this image
-- for show in blender --
top
[attachment=21624:Screenshot_2.png]
side
[attachment=21625:Screenshot_3.png]

http://www.imagebam.com/image/447fb580400613

Posted by: JohnVV May 13 2010, 08:01 PM

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 )
[attachment=21628:d.png]
setting of 10 ( out of 1 to 20 )
[attachment=21627:dhi.png]

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

Posted by: Sajid May 13 2010, 08:20 PM

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.

Posted by: JohnVV May 13 2010, 08:39 PM

3)

convert the hipassed normal to a mesh then to a dem
[attachment=21629:cyc_inter.png]
this is how cyclops sees the hi-normalmap image from above
and it saves to a *.ply
import into blender
[attachment=21631:Screenshot_2.png]
side view
[attachment=21630:Screenshot_1.png]

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 )
[attachment=21632:Screenshot.png]
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
[attachment=21634:Screenshot_8.png]
the next step
cleaning this

Posted by: JohnVV May 13 2010, 11:46 PM

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 )
[attachment=21635:Screenshot_9.png]

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"
[attachment=21636:Screenshot_10.png]
[attachment=21637:Screenshot_11.png]

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

Posted by: JohnVV May 28 2010, 12:07 AM

an update
just a "testing " shot
http://www.imagebam.com/image/fb734c82242642

with only a few of the images in it .

Posted by: Bjorn Jonsson Jun 6 2010, 09:05 PM

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:



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:


Posted by: JohnVV Jun 7 2010, 03:02 AM

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 --
[attachment=21852:N1507742440_2.png]
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
[attachment=21853:N1507742440_2.jpg]
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/preview/sfs/sokrates_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

Posted by: 4th rock from the sun Sep 2 2010, 01:16 PM

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


Posted by: AndyG Sep 2 2010, 01:52 PM

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

Posted by: 4th rock from the sun Sep 2 2010, 10:17 PM

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!


Posted by: JohnVV Sep 2 2010, 11:24 PM

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


Posted by: JohnVV Feb 1 2012, 05:04 AM

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
[attachment=26345:IoBumpTest.jpg]

just a test for right now

Posted by: volcanopele Feb 1 2012, 06:11 AM

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.


Posted by: JohnVV Feb 1 2012, 06:53 AM

a height map but that spot IS an artifact from Shamshu Patera
[attachment=26347:map.jpg]
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
[attachment=26349:close.jpg]

Posted by: JohnVV Apr 17 2012, 09: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
http://www.imagebam.com/image/16f9e1185355190
the ISIS3 "shade" tool set at 270Deg and 45 deg height
http://www.imagebam.com/image/e42bde185355258
and the sfs from it with some pre processing in G'mic
http://www.imagebam.com/image/082df4185355389

Posted by: JohnVV Jan 15 2018, 06:13 AM

just a update on a rather old thread
i was asked about using SFS
starting image of Ceres PIA21750



a 8 bit copy of the 32 bit float image


and a hillshade using GDAL


yes i am using the same old mini.cpp
-- link
https://drive.google.com/file/d/1v_y_rmCC6p64F0GbpIaQckJZej-OZapt/view?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

Posted by: TrappistPlanets May 10 2021, 12:52 PM

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
http://www.imagebam.com/image/16f9e1185355190
the ISIS3 "shade" tool set at 270Deg and 45 deg height
http://www.imagebam.com/image/e42bde185355258
and the sfs from it with some pre processing in G'mic
http://www.imagebam.com/image/082df4185355389

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?

Posted by: TrappistPlanets May 10 2021, 01:05 PM

i have a SFS dem of umbriel


 

Posted by: TrappistPlanets May 10 2021, 01:07 PM

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

Posted by: JohnVV May 12 2021, 06:47 PM

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

Posted by: TrappistPlanets May 12 2021, 11:25 PM

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?

Posted by: JRehling May 21 2021, 03:07 AM

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

Posted by: TrappistPlanets Jun 10 2021, 11: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

here is a map verson i made from that dem (fixed inaccurate elevation, and issues in some craters)

Posted by: TrappistPlanets Oct 18 2021, 08:48 PM

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:




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?


Posted by: JohnVV Oct 19 2021, 01:22 AM

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

Posted by: TrappistPlanets Oct 19 2021, 10:48 AM

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

Posted by: JohnVV Oct 19 2021, 02:29 PM

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


Posted by: JRehling Oct 21 2021, 04:32 PM

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.

Posted by: TrappistPlanets Oct 21 2021, 11:10 PM

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)


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.

Posted by: JRehling Oct 21 2021, 11:24 PM

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/article/abs/pii/S0019103510003945

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.

Posted by: TrappistPlanets Oct 22 2021, 11:08 AM

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/article/abs/pii/S0019103510003945



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?

Posted by: JRehling Oct 22 2021, 02:31 PM

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.

Posted by: stevesliva Oct 22 2021, 04:47 PM

Just FYI... There was this other discussion: http://www.unmannedspaceflight.com/index.php?showtopic=4212&st=80&p=254805&#entry254805

Posted by: TrappistPlanets Oct 23 2021, 11:53 AM

QUOTE (stevesliva @ Oct 22 2021, 04:47 PM) *
Just FYI... There was this other discussion: http://www.unmannedspaceflight.com/index.php?showtopic=4212&st=80&p=254805&#entry254805

i moved it here sense no one replied there and this is a better place to talk about DEMs

Posted by: Phil Stooke Oct 23 2021, 07:00 PM

Schenk, P., McKinnon, W.B., Moore, J. and Nimmo, F., 2021, March. The Topography of Ganymede (and Callisto): Geology, Global Characteristics, and Future Exploration. In Lunar and Planetary Science Conference (No. 2548, p. 2228).

This is a recent discussion of topography on Ganymede and Callisto which shows how very limited the stereo coverage is. Here's a link:

https://www.hou.usra.edu/meetings/lpsc2021/pdf/2228.pdf

Nobody knows more about icy satellite topography than these authors.

Phil

Posted by: TrappistPlanets Oct 23 2021, 10:48 PM

QUOTE (Phil Stooke @ Oct 23 2021, 07:00 PM) *
Schenk, P., McKinnon, W.B., Moore, J. and Nimmo, F., 2021, March. The Topography of Ganymede (and Callisto): Geology, Global Characteristics, and Future Exploration. In Lunar and Planetary Science Conference (No. 2548, p. 2228).

This is a recent discussion of topography on Ganymede and Callisto which shows how very limited the stereo coverage is. Here's a link:

https://www.hou.usra.edu/meetings/lpsc2021/pdf/2228.pdf

Nobody knows more about icy satellite topography than these authors.

Phil

yeah, i have seen that before, i even tried finding the PC DEM coverage in other papers to make a Ganymede DEM map from the data, but i failed miserably

Posted by: JRehling Oct 23 2021, 11:26 PM

QUOTE (TrappistPlanets @ Oct 23 2021, 03:48 PM) *
I even tried finding the PC DEM coverage in other papers to make a Ganymede DEM map from the data, but i failed miserably


The paper itself makes this clear. They state that less than 20% of the surface has usable data. Those oddly-shaped pieces do not overlap, so it is impossible to calibrate their relative altitudes together. The paper is full of interesting comments about Ganymede's and Callisto's global topography around the overarching fact that our knowledge is spotty for now.

Posted by: JRehling Oct 24 2021, 07:00 PM

Here's the full text of a paper explaining the methodology necessary to use shape-from-shading to produce a local DEM for lunar surfaces. This is 2018 work even though we've had good images of half of the Moon for many decades. It depends upon generating a model of reflectance functions for the lunar surface, estimating the variations in local intrinsic albedo, accounting for said albedo, and the fact that estimates may be checked against data derivable from other sources.

https://www.sciencedirect.com/science/article/pii/S0924271617303878

Note, this is much, much more complicated than running a Photoshop filter on an image. It'll be a major research project to attempt the same for Ganymede, etc. And, simply put, a successful mapping campaign from JUICE would certainly enable the production of a detailed, global topographic map of Ganymede and make obsolete anything done prior to that, and we'll see such a map around 2035 if the mission is fully successful.

Europa Clipper will similarly, but perhaps not quite so well, give us a global topographic map of Europa. As Van says here, of "medium-resolution":
http://futureplanets.blogspot.com/2013/05/europa-clipper-update.html

JUICE and Europa Clipper will make a total of 21 flybys of Callisto, which would certainly upgrade our coverage of that world far beyond the current status, but almost certainly wouldn't be sufficient to produce a seamless global topographic map. It should give us detailed local topography in many places and perhaps detect any global deviations from sphericity, although Callisto might be a good bet for being one of the most nearly spherical bodies in the solar system.

About 15 years from now, we'll hopefully have Ganymede's topography characterized about as well as we now have for terrestrial planets, the maps for Mercury and Venusian will be better than now, we'll have a global topographic map of Europa that's good but not as detailed as we have for the terrestrial planets. Io and Callisto will remain partial and spotty.

Posted by: TrappistPlanets Nov 29 2021, 01:41 AM

i figured out how to dem process in gimp, but how do i remove streaks in the DEM


Posted by: JohnVV Nov 29 2021, 03:27 PM

QUOTE (TrappistPlanets @ Nov 28 2021, 08:41 PM) *
i figured out how to dem process in gimp, but how do i remove streaks in the DEM

i do not think that there is a good way to remove that cris-cros hatching in that image

a forrier transform might , there is a gimp plugin for that

but just finding the " noise" to remove will be difficult

Posted by: TrappistPlanets Nov 29 2021, 05:24 PM

QUOTE (JohnVV @ Nov 29 2021, 04:27 PM) *
i do not think that there is a good way to remove that cris-cros hatching in that image

a forrier transform might , there is a gimp plugin for that

but just finding the " noise" to remove will be difficult


what is the plugin called so i can find it?

Posted by: JohnVV Nov 29 2021, 05:41 PM

a google search found the MS windows binaries
https://github.com/rpeyron/plugin-gimp-fourier/releases/tag/v0.4.3-3

Posted by: TrappistPlanets Nov 29 2021, 05:58 PM

QUOTE (JohnVV @ Nov 29 2021, 06:41 PM) *
a google search found the MS windows binaries
https://github.com/rpeyron/plugin-gimp-fourier/releases/tag/v0.4.3-3


tried installing (did it correctly), restarting gimp and the option for it is not appearing
how do i make it work?

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)