Lars wrote:

> Any recommendations on good tools to smooth and manipulate 16bit
> grayscale images under win2000?  Photoshop is quite limited in it's
> 16bit handling, and I'm not having any luck with Wilbur--it seems to
> produce a lot of empty images and lose data.  HLA didn't run under
> windows 2000.

Have you looked at Leveller? - http://www.daylongraphics.com/

-- 
Ken Tyler

Post a reply to this message

Lars wrote:
> 
> [...]
> I'm guessing that probably wouldn't change the boxing effect I see in
> smoothed images, but that might help with trying to get the non smoothed
> image looking less stepped.  That's what I've been trying to do
> recently, but I am having problems finding a good image processing tool
> that can handle 16bit grayscale images.  I've been taking an 1000 x 1000
> 8bit image (TGA converted from a DEM) and upscaling it to 5K x 5K,
> allowing Photoshop to do bicubic interpolation to create the additional
> 16bit data between the original 8 bit image source pixels.  

There are various types of so-called 'DEM' data formats which need
different conversion programs.  A lot of them are in a quite simple ASCII
form, but some are more complicated.  Nearly all are 16 bit data in the
original so the 8 bit you get are probably result of the conversion.  

> Any recommendations on good tools to smooth and manipulate 16bit
> grayscale images under win2000?  Photoshop is quite limited in it's
> 16bit handling, and I'm not having any luck with Wilbur--it seems to
> produce a lot of empty images and lose data.  HLA didn't run under
> windows 2000.

gforge/HF-Lab should compile with Cygwin without problems.  

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 06 Feb. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

> Have you looked at Leveller? - http://www.daylongraphics.com/

I downloaded the demo and played with it for a bit, and honestly 
couldn't figure too much out!  :)  The cost was an issue for me, so I 
didn't look at it too seriously, but I'll look at it a bit further if 
you think it will work.  

> Have you tried dem2pov? 

I haven't--I'll look into it.  I used a DEM->TGA converter to begin 
with, but I do need to edit the files after they are converted from 
DEM--move features around, adjust them, add new features, etc.  So I 
need some way to edit them once they become 16bit files.  (editing them 
in 8 bit and then trying to convert them to 16bit after is what I was 
doing, but I've been running into the smoothness / stepping issue).  
Many of the DEM converters didn't look like an option for me, since I 
wouldn't have any way to manipulate the data afterwards.

I saw a couple more programs on the povray.org site, but many were dead 
links--earthscape, klevel, smooth, etc.  :(   If I can't find something 
that exists already, I might just write my own 8 to 16 bit converter 
with smoothing.  Or maybe set up a DOS box to run HLA.  

It sounds like the consensus so far is that I should attack this from 
the trying to get a smooth 16bit image angle and not use the heightfield 
smooth function.  None of my experiments to date have suceeded in 
getting the smooth function to work without the boxes effect in some 
degree.

Post a reply to this message

> There are various types of so-called 'DEM' data formats which need
> different conversion programs.  A lot of them are in a quite simple ASCII
> form, but some are more complicated.  Nearly all are 16 bit data in the
> original so the 8 bit you get are probably result of the conversion.  

I'm having to deliberately convert them to 8 bit, since that's the only 
way I have of editing them after I convert them.  If I had image editing 
software that could read and manipulate 16bit grayscale images, I'd 
start from there and probably not have the problem at all.  But so far, 
I've been unable to find anything that can manipulate 16bit grayscale 
images.  I tried UTSCSA's ImageTool 2.0, but it can't handle the large 
file sizes needed.

So the lack of a 16bit image editor is the reason why I have to go to 8 
bit, edit, then convert to 16, using bicubic interpolation while 
increasing the pixel scale to smooth out the results.  But it's not 
smoothing enough.  So I need something that can either edit the 16bit 
images, or at least run a good smoothing algorithm on the converted 
16bit image.

I'm assuming that if I could get the full dynamic range of 16bit 
grayscale, my stepping issue should go away.  If not, well, then I'm 
back to the drawing board.

Post a reply to this message

Thanks for the suggestions so far.  

I've been able to create a full depth, smoothed 16bit test image for the 
heightfield.  Unfortunately, even with 16bits, the stepping remains 
quite noticable.  I've got many many more steps than before, but they 
don't blend and remain quite clear.  The edges of each change in 
elevation are highlighted and it looks like a million slug trails over 
the landscape--or maybe those architectural models where they make hills 
from layers and layers of flatboard.  I think the problem lies in the 
terrain is mostly flat, with subtle slow changes in elevation causing 
the stepping.  Plus it doesn't seem to smooth between to areas, instead 
making a dimensional bump between two values.  Places with more 
pronounced altitude changes don't look as bad.  So I think 16bit 
elevation data has failed to solve the problem.  It appears I need to 
find a way to get smooth to behave, or find a different approach.

Using Heightfield "Smooth" tends to produce a more muddied look-- it 
appears as if there are only three levels of lighting--dark, med and 
light with no gradation between them.  It looks very posterized.  It's 
almost as if the normals are quantized and only allowing for three 
levels of specular lighting effect.  Plus the boxes problem remains 
(which might be related--more gradations might make the boxes harder to 
notice).   I've tried changing my scale factor, in case it was a 
precision issue, but no change.  

Anyone have any further ideas on heightfield smooth?

Thanks
Lars

Post a reply to this message

In povray.general Lars <sel### [at] pacbellnet> wrote:
: Anyone have any further ideas on heightfield smooth?

  Did you try with a lower resolution? For example divide width and height
by 10. (You don't have to use it; just try it to see what happens).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Also, if you happen to be on Linux (or some other Gnome-enabled UNIX), you 
might want to try 

  http://terraform.sourceforge.net

which features a quite-capable terrain editor with some (limited) povray 
integration ...

Greetings
--> R

Ken wrote:
> 
> 
> Lars wrote:
> 
>> Any recommendations on good tools to smooth and manipulate 16bit
>> grayscale images under win2000?  Photoshop is quite limited in it's
>> 16bit handling, and I'm not having any luck with Wilbur--it seems to
>> produce a lot of empty images and lose data.  HLA didn't run under
>> windows 2000.
> 
> Have you looked at Leveller? - http://www.daylongraphics.com/
>

Post a reply to this message

>   Did you try with a lower resolution? For example divide width and height
> by 10. (You don't have to use it; just try it to see what happens).

do you mean the rendering or the height field source?   

Reducing the res of the HF source doesn't change the boxing effect, only 
I get larger boxes.  I tried resolutions from 500x500 up to 10000 x 
10000, both 8 and 16 bit depths.  They all show the posterization and 
boxing when smooth is enabled, just with differing size boxing.

Reducing the rendering output size makes everything lower res, and 
eventually the boxes disappear as they become sub-pixel in size.  The 
world looks reasonable at 640x480 or whatever, since each box is 0.002 
pixels across!  So the scale of the boxes is constant in relation to the 
world scale.

Post a reply to this message

Is it possible to output the HF vertices? If so, you could make the
triangles and figure the normals yourself. The fact that a HF parses so
quickly suggests to me that some type of cheat is used to figure the
normals. If you put the HF where you wanted it and then calculated the
"real" normals, you would surely get a better result.

If not, I think it would be pretty easy to build your own heightfield with
eval_pigment. Haven't tried that, though.

Hope this helps.
 -Shay

Lars <sel### [at] pacbellnet> wrote in message
news:MPG.16d84912e546d13b989680@news.povray.org...

Post a reply to this message

In article <3c72a800@news.povray.org>, "Shay" <sah### [at] simcopartscom> 
wrote:

> Is it possible to output the HF vertices? If so, you could make the
> triangles and figure the normals yourself. The fact that a HF parses so
> quickly suggests to me that some type of cheat is used to figure the
> normals. If you put the HF where you wanted it and then calculated the
> "real" normals, you would surely get a better result.
> 
> If not, I think it would be pretty easy to build your own heightfield with
> eval_pigment. Haven't tried that, though.

Or just use one of the height field macros from shapes.inc. ;-)

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message