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

Mike Hough <Ama### [at] aolcom> wrote:
: 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.

  If you wrote a post that offended him, even if it was unintentional, it's
not him who should apologize to you, but the other way around.

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

  "I make a mistake and get corrected, so I will never again post any bug
report." Makes sense.

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

Post a reply to this message

On Tue, 2 Oct 2001 22:29:02 -0500, Mike Hough wrote:
>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.

No, the offset in the map is because UTM is not "square" unless you're on
a meridian.  If you account for the projection, that problem goes away.  I
used to write GIS software; I dealt with USGS products all the time.  

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

SDTS DEM Positional Error (Source: USGS)
One positioning error is isolated to the spatial domain module of the SDTS
file. This module contains the UTM corner coordinates of the file's bounding
rectangle. Because of coordinate rounding errors, these bounding corner
coordinates may be off as much as one meter in x and/or y from their proper
positions. This rounding error, however, does not affect the positions of
the internal DEM post coordinates. Because the bounding rectangle was
calculated independently from the internal coordinate positions, it is
possible that some internal post coordinates may actually lie as much as one
meter outside the footprint of the bounding rectangle. Programs that do not
attempt to register the DEM tiles using coordinates of the spatial domain
module will not be affected by this coordinate rounding error.

The other positioning error affects the coordinates of the internal DEM
posts for SDTS 10-meter and 30-meter DEMs. This problem results from the use
of an incorrect origin for the SDTS UTM grid calculated for each 7.5-minute
tile. Rather than placing grid posts at 10- or 30-meter increments from a
consistent origin within the respective UTM zone, the 10- or 30-meter
step-over in northing and easting was calculated from the minimum easting
and maximum northing (northwest corner) of the target DEM cell. The error
for each SDTS tile will vary depending on the orientation of the UTM grid to
the 7.5-minute latitude and longitude of the original DEM corners. The x or
y error between any grid post's correct horizontal position and calculated
position will not exceed the spatial resolution of that particular DEM. This
error will be consistent for all elevations within a 7.5-minute tile but may
vary across tiles. When this error varies across tiles, column or row
drop-out may be evident along the common edge of those tiles.

There is no simple offset or translation that can be applied to the existing
SDTS DEMs to correct for these conversion errors. The USGS is presently
considering the proper action to be taken regarding this problem. These
problems have been fixed in the SDTS conversion software, therefore, any
SDTS DEMs created after January 1, 2001 will contain correct positioning.


My understanding is that this was a problem when using SDTS DEM files with
Bryce.  Bryce may very well not account for the projection but I thought
this could be what you were seeing.

Post a reply to this message

On Wed, 3 Oct 2001 15:47:38 -0500, Mike Hough wrote:
>
>My understanding is that this was a problem when using SDTS DEM files with
>Bryce.  Bryce may very well not account for the projection but I thought
>this could be what you were seeing.

Nope, those are tiny position errors.  What I was seeing is that the
edges of the tile aren't horizontal and/or vertical, which is a sign that
the program didn't take the projection into account.  Unfortunately (well,
actually quite fortunately, as far as I'm concerned) I don't work for the 
GIS company anymore, and it's been long enough that I don't have any of
the necessary resources for converting from UTM to degrees/minutes/seconds
anymore.  

In any event, as long as the tiles are small enough you can probably use
an appropriate rotation to make them almost right.  I just thought I'd
point it out in case you were counting on +Y being north or some such thing.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

Anyone else got anything personal to say about my character?

Post a reply to this message