This scene renders a height_field using a 16-bit PGM file in POV 3.1G while
the same scene in 3.5 looks scrambled.  Does this have something to do with
the new PPM libraries?  I'll try uploading the file for this scene to the
binaries group but I suspect it may be too big...

light_source {<0, 20, 0> color rgb <1, 1, 1>}

camera {location <0, 1, 0>

look_at 0
}

height_field {
pgm "KingstonEast.pgm"
smooth
translate <-.5, 0, -.5>
scale <1, .1, 1>
pigment {color rgb <1, 1, 1>}
}

Post a reply to this message

On Thu, 20 Sep 2001 02:31:02 -0500, Mike Hough wrote:
>This scene renders a height_field using a 16-bit PGM file in POV 3.1G while
>the same scene in 3.5 looks scrambled.  Does this have something to do with
>the new PPM libraries?  I'll try uploading the file for this scene to the
>binaries group but I suspect it may be too big...

Mike, your PGM file has a couple of problems.  First, xv thinks it's
truncated (and pgmtoppm spins forever trying to read it, which backs up
xv's assertion.)  Second, the lines are too long: the pgm spec says lines
must be 70 characters or less.  I don't know if either of these is what
causes POV to choke on the file, but none of my other tools want to work
with it either.

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

> Mike, your PGM file has a couple of problems.  First, xv thinks it's
> truncated (and pgmtoppm spins forever trying to read it, which backs up
> xv's assertion.)

The file was created by Bryce which can also read the image.  Paint shop pro
reports the image as being 128x128 both prior to and after opening.  POV-Ray
3.1 reads and reproduces the file correctly as well.  Short of counting each
entry in the map, it seems that it does have the number of values indicated
in the header.

> Second, the lines are too long: the pgm spec says lines
> must be 70 characters or less.

Although it does say this for writing files, it also says that programs that
read this format should be as lenient as possible, accepting anything that
looks remotely like a graymap.  POV-Ray 3.1 would except longer lines.

There may have been another problem with PGM files.  I seem to recall having
to remove the comments (text following # character) in order for the file to
parse.  I would double check it but my beta has expired.

Post a reply to this message

In article <3bb9f17a@news.povray.org> , "Mike Hough" <Ama### [at] aolcom> 
wrote:

> I would double check it but my beta has expired.

Beta 4 has been available for some time now.


    Thorsten

Post a reply to this message

On Tue, 2 Oct 2001 03:59:11 -0500, Mike Hough wrote:
>> Mike, your PGM file has a couple of problems.  First, xv thinks it's
>> truncated (and pgmtoppm spins forever trying to read it, which backs up
>> xv's assertion.)
>
>The file was created by Bryce which can also read the image.  Paint shop pro
>reports the image as being 128x128 both prior to and after opening.  POV-Ray
>3.1 reads and reproduces the file correctly as well.  Short of counting each
>entry in the map, it seems that it does have the number of values indicated
>in the header.

But it doesn't:

[ron@fwi News]$ wc -w KingstonEast.pgm
  16382 KingstonEast.pgm

There should be 16384 words for the data, plus 2 for the size, one for the
max, and one more for the header.  It's short by 6 words.  However, this
might be an issue with the encoding; perhaps you can zip your image and
repost it in the binaries group?

>> Second, the lines are too long: the pgm spec says lines
>> must be 70 characters or less.
>
>Although it does say this for writing files, it also says that programs that
>read this format should be as lenient as possible, accepting anything that
>looks remotely like a graymap.  POV-Ray 3.1 would except longer lines.

3.5 should, too.  I'm just looking for reasons why your file doesn't even
work properly with xv or pgmtoppm, let alone POV 3.5.  I don't dispute that
there might be a problem with 16-bpp heightfields in 3.5; PNG has a known 
bug that's probably related.  But first I have to get a good PGM image.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

I downloaded beta 4.  Inserting a # on a new line after the 'magic number'
P2 creates the error "invalid width or height read from ppm image".  This
seems to indicate that comments are not being ignored and that beta 4 is
expecting width or height values immediately following the magic number.
Placing the # after the width and height is accepted.

Post a reply to this message

> There should be 16384 words for the data, plus 2 for the size, one for the
> max, and one more for the header.  It's short by 6 words.  However, this
> might be an issue with the encoding; perhaps you can zip your image and
> repost it in the binaries group?

I doubt this is an encoding problem, since the file is ASCII text.  Why
would it need a word to represent the header and the size?  I'm not sure of
the max either.  They are ASCII codes.  Technically it should be possible to
write a PGM file in a word processor and have it work.  It almost seems like
the file is being read in binary.  I'm going to upload a much smaller PGM
file to the binaries group that's easier to dissect.

Post a reply to this message

On Tue, 2 Oct 2001 17:36:35 -0500, Mike Hough wrote:
>> There should be 16384 words for the data, plus 2 for the size, one for the
>> max, and one more for the header.  It's short by 6 words.  However, this
>> might be an issue with the encoding; perhaps you can zip your image and
>> repost it in the binaries group?
>
>I doubt this is an encoding problem, since the file is ASCII text.  Why
>would it need a word to represent the header and the size?  I'm not sure of
>the max either.  They are ASCII codes.  Technically it should be possible to
>write a PGM file in a word processor and have it work.  It almost seems like
>the file is being read in binary.  I'm going to upload a much smaller PGM
>file to the binaries group that's easier to dissect.

By "a word" I meant a group of characters delimited by whitespace, not 
two bytes.  That's what wc -w counts.  Trust me, that file was short by 
six numbers.

However, I'll test with the file you've just provided and see if the problem
looks like the problem with PNG files.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C)bicubic_patch{type 1u_steps 6
v_steps 6R(1)R(3)R(5)R(7)translate 9*z-2pigment{rgb z}}#end#macro _(__)#local X=
asc(substr(C,__,1))-65;<mod(X,4)div(X,4)>#end#local O=union{Q("ABEFUQWS")Q(//RON
"WSXTLOJN")}Q("JNKLCGCD")union{O}union{O translate 3*x}light_source{x 1}//PARKER

Post a reply to this message

On Tue, 2 Oct 2001 17:36:35 -0500, Mike Hough wrote:
>> There should be 16384 words for the data, plus 2 for the size, one for the
>> max, and one more for the header.  It's short by 6 words.  However, this
>> might be an issue with the encoding; perhaps you can zip your image and
>> repost it in the binaries group?
>
>I doubt this is an encoding problem, since the file is ASCII text.  Why
>would it need a word to represent the header and the size?  I'm not sure of
>the max either.  They are ASCII codes.  Technically it should be possible to
>write a PGM file in a word processor and have it work.  It almost seems like
>the file is being read in binary.  I'm going to upload a much smaller PGM
>file to the binaries group that's easier to dissect.

You know, your attitude could use a LOT of adjustment.  I know what a PGM
file is.  I know what an ASCII PGM file is.  Believe it or not, I've even
read the spec for PGM files.  I have tools to work with PGM files: a few
weeks ago, I build the entirety of the netpbm distribution from scratch,
including all of the libraries it depends on (even GhostScript) because I
wanted to be up-to-date on the latest happenings in the PNM world.  I 
really dislike being talked down to by someone who can't even understand
when I tell him what's wrong with the file he posted.

Nevertheless, because someone else might someday want to use a PGM file
in POV-Ray, I've fixed the bug you reported.  I haven't fixed the comment
bug yet, because that is a huge can of worms that I just don't want to 
open tonight.  I also haven't made POV be able to handle binary 16-bit
PGM files on input.  But the other bug is fixed.

Your DEM-to-PGM program, by the way, doesn't correct for the projection
and leaves a huge flat border on one side of the output.  I'd find a 
better conversion program if I were you.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

Did you mean to delete this message?  I didn't appreciate it and don't
understand how you could have fixed a bug if my report was erroneous.  I
misunderstood what you meant by a 'word' and believe it was an honest
mistake.  The file must have not have made it correctly from the attachment
because the original definitely has the correct header, size, max, and
fields.  I checked this by multiplying the lines by the columns of the pixel
data and adding the other four fields ((1027-3)*16) + 4.

Btw, the offset in the map was an error with the orginal DEM files the USGS
released.  The non-square data is saved as a part of a square to prevent
distortion without scaling.

I'll be sure not to post anymore bugs because it's simply not worth this.

Post a reply to this message