Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> > But AFAIK PoV-Ray's height_field functionality can't handle
> > grayscale 16-bit PNGs...
>
> AFAIK, yes it can.

I've had trouble with 16 bit PNGs as well.  The height_field come out as if it
were noise.

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:

> > A recent thread on p.b.i. drew my attention to http://www.buining.com -
> > those 16-bit PNG elevation maps of Earth, the Moon and Mars look
> > tempting! But AFAIK PoV-Ray's height_field functionality can't handle
> > grayscale 16-bit PNGs... are there any tool for conversion into 16-bit
> > heightfield TGAs available?
>
> I think this should work:
>

OK, I'm *completely* new to making 16-bit HFs. And so far, I'm feeling like a
complete dunce.  :-S  Even after reading the POV documentation. Help!

I downloaded the EarthDEM2160.png image file from the given link--a hi-rez,
16-bit elevation map of the earth's continents. Or so says the site--I have no
way of checking the bit depth, computer-knowledge-impaired as I am. (Photoshop
5.0 brings it up as an 8-bit image.)

So, do I understand that the proper series of events is, first to use Jaime's
technique of rendering this image in POV--as a hi-rez render, and setting my INI
file to Output_File_Type=N?  Doing so, I get a nice .png rendering...in 16 bits,
I assume. (Do I need to set Bits_Per_Color = 16 in the INI file as well? Haven't
done that yet.)

Then, do I take that rendered image and stick it into a a HF scene?  Like thus--

global{.....}
camera{......}
light_source(.....}
height_field{png "rendered_HF_image.png" scale <1,.2,1> // smooth
     texture{......}
            }

I get a HF, but it looks rather rough (to my eyes), like the vertical resolution
is still 8-bit.  Don't really know for sure.

Do I have the steps correct?

Ken W.

Post a reply to this message

> file to Output_File_Type=N?  Doing so, I get a nice .png rendering...in 16 bits,
> I assume. (Do I need to set Bits_Per_Color = 16 in the INI file as well? Haven't
> done that yet.)
> 
> I get a HF, but it looks rather rough (to my eyes), like the vertical resolution
> is still 8-bit.  Don't really know for sure.

Yes, you do need Bits_Per_Color=16. Or just +fn16, which sets image type 
to PNG and 16 bits :) I remember the short +stuff easier than the 
Long_Ini_Settings... (and faster to type)

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

>
> Yes, you do need Bits_Per_Color=16. Or just +fn16, which sets image type
> to PNG and 16 bits :) I remember the short +stuff easier than the
> Long_Ini_Settings... (and faster to type)

Thanks!

Either I'm vision-impaired, or I just haven't seen that little tidbit in the POV
docs, in either the hf_gray_16 section or the one on HFs. Perhaps it should be
obvious... though my initial thought was that setting the original rendering to
hf_gray_16 would take care of that.

Details, details...

So if the file_type has to be manually set to .png, and the Bits_Per_Color to
16--what exactly does global{hf-gray-16} do?? Besides making the image
gray-scale?  Hmm, perhaps that IS its only purpose, to eliminate unnecessary
color channels. Gee, I feel smarter already!

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

>
> So, do I understand that the proper series of events is, first to use Jaime's
> technique of rendering this [downloaded] image in POV--as a hi-rez render,
> and setting my INI file to Output_File_Type=N...

Duh!  It just occurred to me--I'm finally starting to use my brain--that I can
use the 16-bit downloaded grayscale image AS-IS to make the height_field. No
hf_gray_16 rendering step required. The HF renders nicely.

So I have a question (truly out of ignorance): What is the purpose of
re-rendering  that 16-bit image using the hf_gray_16 rendering step that was
mentioned? Seems unnecessary and redundant (other than to apply interpolate 2
to it?) I DO understand that a preliminary rendering step is of course
necessary (using one of POV's patterns, for example) if there is no 16-bit
image to begin with.

I'm confused; please enlighten this poor unfortunate soul.

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> So I have a question (truly out of ignorance): What is the purpose of
> re-rendering  that 16-bit image using the hf_gray_16 rendering step that was
> mentioned?

A more enlightened reading of Jaime's original post tells me that I was
completely confused about what he meant (and I probably confused others by my
question.) It's clear now; he was describing a solution to the question in the
original post, a technique for taking a 16-bit .png image and re-rendering it to
be a different file type, one that could be used to make a 16-bit HF in case the
..png image itself didn't work.

But as others have said, a 16-bit .png image works as-is.

All clear. I'm off and running!

Ken W.

Post a reply to this message

> A more enlightened reading of Jaime's original post tells me that I was
> completely confused about what he meant (and I probably confused others by my
> question.) It's clear now; he was describing a solution to the question in the
> original post, a technique for taking a 16-bit .png image and re-rendering it to
> be a different file type, one that could be used to make a 16-bit HF in case the
> ..png image itself didn't work.

   Sorry, I forgot to say you should use TGA output: I assumed this was 
obvious...

> But as others have said, a 16-bit .png image works as-is.

   Seems so... but I had to use this conversion to TGA for my "hf2iso" 
include, as I was having problems when using 16bit PNGs that I didn't 
understand. These magically disappeared when using TGAs... perhaps due to 
another reasons, I must admit.

--
Jaime

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:


>
> > But as others have said, a 16-bit .png image works as-is.
>
>    Seems so... but I had to use this conversion to TGA for my "hf2iso"
> include, as I was having problems when using 16bit PNGs that I didn't
> understand. These magically disappeared when using TGAs... perhaps due to
> another reasons, I must admit.
>
> --
> Jaime

Thanks! I'll try that and then compare the two renders.

Ken W.

Post a reply to this message

Kenneth nous apporta ses lumieres en ce 2008/03/27 21:24:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> 
>> Yes, you do need Bits_Per_Color=16. Or just +fn16, which sets image type
>> to PNG and 16 bits :) I remember the short +stuff easier than the
>> Long_Ini_Settings... (and faster to type)
> 
> Thanks!
> 
> Either I'm vision-impaired, or I just haven't seen that little tidbit in the POV
> docs, in either the hf_gray_16 section or the one on HFs. Perhaps it should be
> obvious... though my initial thought was that setting the original rendering to
> hf_gray_16 would take care of that.
> 
> Details, details...
> 
> So if the file_type has to be manually set to .png, and the Bits_Per_Color to
> 16--what exactly does global{hf-gray-16} do?? Besides making the image
> gray-scale?  Hmm, perhaps that IS its only purpose, to eliminate unnecessary
> color channels. Gee, I feel smarter already!
> 
> Ken W.
> 
> 
> 
> 
> 
hf_gray_16 turn the display black and white and the file output to a specialy 
formated TGA file with the hight encoded in the red and green chanels. Low part 
in the green and high part in the red. It still an 8 bit per channel file.
If you open it in a graphic viewer, you see a red shape striped with green 
gradients. The blue channel is set to zero everywhere.

-- 
Alain
-------------------------------------------------
A modest man is usually admired; if people ever hear of him.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> Kenneth nous apporta ses lumieres en ce 2008/03/27 21:24:

> >
> > So if the file_type has to be manually set to .png, and the Bits_Per_Color to
> > 16--what exactly does global{hf-gray-16} do?? Besides making the image
> > gray-scale?  Hmm, perhaps that IS its only purpose, to eliminate unnecessary
> > color channels. Gee, I feel smarter already!
> >
> > Ken W.
> >
> >
> hf_gray_16 turn the display black and white and the file output to a specialy
> formated TGA file with the hight encoded in the red and green chanels.

It doesn't *automatically* switch the file output to TGA--that still has to be
set manually, in the INI file or on the command line.

> Low part in the green and high part in the red. It still an 8 bit per
> channel file. If you open it in a graphic viewer, you see a red shape
> striped with green gradients. The blue channel is set to zero everywhere.

Yes, I see that now.  Thanks. It *is* a strange-looking image, when pulled up in
Photoshop. The red channel looks like the image, but the green channel looks
like distorted noise!  But somehow it all works.

Concerning the Bits_Per_Color setting:  I did a series of TGA tests, setting
Bits_Per_Color to 2,then 4,8,16 and then leaving it out altogether.  The
resulting images (and the HFs made from them) all look identical.  Which leads
me to believe that Bits_Per_Color is ignored, and automatically set to 16 when
global_settings{hf_gray_16} is used.

Ken W.

Post a reply to this message