"Rune" <run### [at] mobilixnetdk> wrote in message
news:3beffbe3@news.povray.org...
> "Adrien Beau" wrote:
> > Perhaps indicate here the command line switches
> > and ini settings that allow such formats?
>
> Well, this is where my knowledge doesn't suffice.
>
> For example, to get 16 bit grayscale png I'm not sure if one has to use
> +fn16 or if just +fn is enough when hf_gray_16 is specified in the
> global_settings.

I think the confusion is because of the 16 bit hf_gray_16 being in reality a
24 bit image.  I never understood if the PNG output was done in a different
way from the TGA, where it might also only use 16 bits of the whole.  When I
check for colors used I see something like a 256 color image instead, for
both PNG and TGA.
Anyway, the usual way is to use default 24 bit output, or +fn or +ft.  If it
were +fn16 you would get a 48 bit image.  Which BTW is mentioned in the Doc
under Height Field as being a better grayscale image.  I've yet to see that
to be true.
That said, all I ever get is 8 bit output for PNG grayscale images.  And I
don't think I have a viewer capable of seeing 48 bit images, they reduce to
24 in my image programs; either that or the output is always truncated.

Bob H.

Post a reply to this message

On Mon, 12 Nov 2001 12:53:58 -0600, Bob H. wrote:
> "Rune" <run### [at] mobilixnetdk> wrote in message
> news:3beffbe3@news.povray.org...
>> "Adrien Beau" wrote:
>> > Perhaps indicate here the command line switches
>> > and ini settings that allow such formats?
>>
>> Well, this is where my knowledge doesn't suffice.
>>
>> For example, to get 16 bit grayscale png I'm not sure if one has to use
>> +fn16 or if just +fn is enough when hf_gray_16 is specified in the
>> global_settings.

Yes.  (hf_gray_16 forces a PNG to 16-bpp.)
 
> I think the confusion is because of the 16 bit hf_gray_16 being in reality a
> 24 bit image.  I never understood if the PNG output was done in a different
> way from the TGA, where it might also only use 16 bits of the whole. 

It is done in a different way.  PNG images can be single-channel.  Here's
the output from pngcheck for a POV-generated hf_gray_16 PNG:

[ron]$ ./pngcheck sig2.png
OK: sig2.png (320x240, 16-bit grayscale, non-interlaced, 83.6%).

> When I
> check for colors used I see something like a 256 color image instead, for
> both PNG and TGA.

I think that's a limitation of whatever software you're using.

> Anyway, the usual way is to use default 24 bit output, or +fn or +ft.  If it
> were +fn16 you would get a 48 bit image.  Which BTW is mentioned in the Doc
> under Height Field as being a better grayscale image.  I've yet to see that
> to be true.

If 16-bpp PNG as an input format were working, I could demonstrate that it
is indeed true.  Since it isn't, at the moment, you'll have to take my word
for it.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

"Bob H." wrote:
> 
> I think the confusion is because of the 16 bit hf_gray_16 being in reality a
> 24 bit image.  I never understood if the PNG output was done in a different
> way from the TGA, where it might also only use 16 bits of the whole.  When I
> check for colors used I see something like a 256 color image instead, for
> both PNG and TGA.
> Anyway, the usual way is to use default 24 bit output, or +fn or +ft.  If it
> were +fn16 you would get a 48 bit image.  Which BTW is mentioned in the Doc
> under Height Field as being a better grayscale image.  I've yet to see that
> to be true.
> That said, all I ever get is 8 bit output for PNG grayscale images.  And I
> don't think I have a viewer capable of seeing 48 bit images, they reduce to
> 24 in my image programs; either that or the output is always truncated.

I think it is starting to get confusing ;-)

With 'hf_gray_16' and +fn, Povray 3.5 in contrast to earlier versions is
supposed to generate 1 channel 16 bit output, but there is still a bug
leading to wrong byte order.  It is not possible to generate 8 bit
grayscale output right now.

Without 'hf_gray_16' you get 3 channel rgb output either 8 bit/channel
with +fn/+fn8 or 16bit/channel with +fn16.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Thanks Ron an Christoph!

I'd also like some more information on the PPM format. First of all, does it
work on all systems and operating systems? Second, how does it work
with/without hf_gray_16 and with/without 16bit specified?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

When I try to use a PNG with 16 bits per color as a height field, why does
POV-Ray say, "Warning: Converting PNG image map to 8 bits/sample from higher
bit depth."?

Anders

Post a reply to this message

In article <3bf0398e$1@news.povray.org> , "Anders K." <and### [at] f2scom> 
wrote:

> When I try to use a PNG with 16 bits per color as a height field, why does
> POV-Ray say, "Warning: Converting PNG image map to 8 bits/sample from higher
> bit depth."?

Good question.  Maybe a damaged PNG image?

Can anybody confirm such a message with any other PNG image?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> > When I try to use a PNG with 16 bits per color as a height field, why
does
> > POV-Ray say, "Warning: Converting PNG image map to 8 bits/sample from
higher
> > bit depth."?
>
> Good question.  Maybe a damaged PNG image?
>
> Can anybody confirm such a message with any other PNG image?

In fact, I can reproduce it simply by rendering this file:

  // cmd: +w400 +h400 -a +fn16 +otesthf
  camera { orthographic location z look_at 0 right x up y }
  plane { z, 0 pigment { gradient x translate x/2 } finish { ambient 1 } }

which creates testhf.png, and then rendering this:

  height_field { png "testhf.png" }

Anders

Post a reply to this message

"Anders K." <and### [at] f2scom> wrote in message
news:3bf07c60$1@news.povray.org...
> > > When I try to use a PNG with 16 bits per color as a height field, why
> does
> > > POV-Ray say, "Warning: Converting PNG image map to 8 bits/sample from
> higher
> > > bit depth."?
> >
> > Good question.  Maybe a damaged PNG image?
> >
> > Can anybody confirm such a message with any other PNG image?
>
> In fact, I can reproduce it simply by rendering this file:
>
>   // cmd: +w400 +h400 -a +fn16 +otesthf
>   camera { orthographic location z look_at 0 right x up y }
>   plane { z, 0 pigment { gradient x translate x/2 } finish { ambient 1 } }
>
> which creates testhf.png, and then rendering this:
>
>   height_field { png "testhf.png" }

Ron has said it is broken in some way, I guess... well maybe not broken,
judging by the conversion message, but at least not possible for now.

Think I understand all this more anyhow, I was pretty sure my image software
is too feeble to decipher 16 bpp images so I'm convinced of that.  I'll look
for stuff that can read image info better.

Bob H.

Post a reply to this message

Rune wrote:
> 
> Thanks Ron an Christoph!
> 
> I'd also like some more information on the PPM format. First of all, does it
> work on all systems and operating systems? Second, how does it work
> with/without hf_gray_16 and with/without 16bit specified?
> 
	you can try  http://www.wotsit.org/ or Google...

-- 
Thierry     exposant de trucs bizarres     http://la.buvette.org/exPOV/

Post a reply to this message

On Mon, 12 Nov 2001 20:57:09 +0100, Rune wrote:
> Thanks Ron an Christoph!
> 
> I'd also like some more information on the PPM format. First of all, does it
> work on all systems and operating systems? Second, how does it work
> with/without hf_gray_16 and with/without 16bit specified?

Yes, it works on all systems and operating systems.  With hf_gray_16, it
outputs the red/green sort of heightfield we're used to seeing in TGA images.
(though I would argue that it should output a 16-bit grayscale (PGM) image.)
Without hf_gray_16 and with +fp16, it outputs a 48-bpp RGB image in the 
format supported by netpbm and other fine programs (note that Photoshop is
not a "fine program" by this metric.  For a supposedly professional program,
their support for 48-bpp file formats is abysmal.)  With hf_gray_16 and +fp16, 
the output is broken: its header claims to be for a 48-bpp PPM image, but the 
data is that of a 24-bpp PPM image in the red/green format.

The bugs noted in the above paragraph have been entered into the Team's 
bug-tracking system and will be fixed at some point.  This is how it should
work when it's fixed:

+fp and no hf_gray_16:   24-bpp PPM
+fp and hf_gray_16:      16-bpp PGM
+fp16 and no hf_gray_16: 48-bpp PPM
+fp16 and hf_gray_16:    16-bpp PGM

I realize that this provides no way to make an 8-bpp PGM image, just as there
is no way to make an 8-bpp grayscale PNG, but that's an argument we've 
already had and it's just a fact of life.  Use postprocessing if that's what
you want (16-bpp to 8-bpp conversions are legal for the IRTC, if I remember
correctly.)

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message