 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Ralph Smith who wrote:
>
>I've looked into a .tga height field file. It looks like only the red and green
>pixel components are
>used. The blue and alpha components are always 0. So, I guess that I can get a
>16 bit hf_gray_16
>file if I set the red and green bytes between 0 and 0xffff. If so, which is the
>most significant
>byte?
Red is more significant.
Note that it's not sufficient just to produce a rgb TGA file with the
16-bit grey data coded into the R and G components. You also have to
write whatever it is that tells POV to treat it as 16-bit grey,
otherwise POV is going to treat the data as rgb. The POV syntax is the
same for reading the two types of TGA data, so there must be something
in the file itself that distinguishes the two situations.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You also have to
> write whatever it is that tells POV to treat it as 16-bit grey,
> otherwise POV is going to treat the data as rgb. The POV syntax is the
> same for reading the two types of TGA data, so there must be something
> in the file itself that distinguishes the two situations.
I don't think there is. It just happens that a greyscale image, when read as
though it were 16-bit grey, conveniently produces the expected result. Think
about it: each pixel in a greyscale image contains colors rgb(0,0,0) through
rgb(255,255,255). Discarding the blue channel, we get 0x0000 through 0xffff,
with a full 256 possible numbers within that range, evenly distributed.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>
> In some places it required either one space or one newline in the header
> where the spec specified "whitespace". My code was doing something like
>
> print "P5 $width $height $depth" and POV-Ray was looking for a newline
> after the P5 or some such. I don't remember the exact details.
Valid point (although after the 'P5' no newline is required - there is
after the height though).
But also note if that 'print' command adds a Windows newline (i.e.
CR+LF) afterwards it generates an invalid PGM file.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 01 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams wrote:
>
> Doesn't that only work for 8-bit PPM files, whereas the documentation
> states that it works for 16-bit PPMs.
>
It works for 16bit PPM images as well (just checked). You get the
GREY_SCALE3() weighting of the color components in that case and not the
R*256+G one.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 01 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams wrote:
>
> Note that it's not sufficient just to produce a rgb TGA file with the
> 16-bit grey data coded into the R and G components. You also have to
> write whatever it is that tells POV to treat it as 16-bit grey,
> otherwise POV is going to treat the data as rgb.
No, in heightfields RGB images are always reduced by weighting the color
components - in case of 3x8bit images you get the R*256+G - for 3x16bit
the R*0.297 + G*0.589 + B*0.114.
Note the special treatment of the 8bit RGB is mostly for backwards
compatibility - although this will likely continue to work i would
recommend to use true 16bit formats to specify 16bit data.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 01 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Valid point (although after the 'P5' no newline is required - there is
> after the height though).
Yes, I didn't remember the details.
> But also note if that 'print' command adds a Windows newline (i.e.
> CR+LF) afterwards it generates an invalid PGM file.
That I knew. Actually, I think it was a P2 or P3 file I was generating
anyway. In any case, the point stands that in spite of the specs, it
doesn't get things right. I'm guilty as well - I've never written code
that reads pbmplus files that looks for comments. :-)
--
Darren New / San Diego, CA, USA (PST)
The samba was clearly inspired
by the margarita.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ralph Smith wrote:
> I generated a test gray-level image with hf_gray_16. This created a "image.bmp"
file. The
> documentation says that this is a "special 16 bit grayscale". I looked into this
file and it seems
> to be really an 8-bit file with all of the r-g-b values equal for each pixel. Is
that indeed the
> format of these files? I want to write some c++ code to generate these height field
files that
> povray can use.
>
> thanks,
> Ralph
>
I traditionally use .PNG format (+fn) for my heightfields. How do they tend to
come out using hf_gray_16 (8-bit or 16-bit images)?
--------------
David Wallace
TenArbor Consulting
"Just In Time Cash"
www.tenarbor.com
1-866-572-CASH
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
