I am creating an image using povray running under Linux. My command line is
this:

%x-povray -IVoyager.pov -D -L/var/povray/include +H768 +W1024

This results in a .tga file which is over 2 mb in size. However, displaying
this in a paint program shows a 100x100 image. I find this strange. I
suspect a .ini file is being used without my knowledge. How can I get around
this?

Oh, BTW, following the completion of my render, I get this:

.......................................................

Creating bounding slabs.
Scene contains 78133 frame level objects; 1 infinite.

Creating vista buffer.
Creating light buffers....
Rendering...
Done Tracing
Voyager.pov Statistics, Resolution 1024 x 768

As you can see, the resoultion appears to be correct ....???

jon

====================================================
Jon & Frances Berndt
email: jsb### [at] hal-pcorg, fan### [at] hal-pcorg
WWW: http://www.hal-pc.org/~jsb
League City, TX
====================================================

Post a reply to this message

Jon Berndt <jsb### [at] hal-pcorg> wrote:
: This results in a .tga file which is over 2 mb in size. However, displaying
: this in a paint program shows a 100x100 image. I find this strange. I
: suspect a .ini file is being used without my knowledge. How can I get around
: this?

  Are you sure you are looking at the right image? Are you sure that your
paint program doesn't zoom out big images by default (like some do when the
image to be open is bigger than the window of the program).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I am 99.9% sure that all is well with the image. After all, if it is over 2
megs, it can't be 100x100.
It must be something with your paint program. Perhaps it's displaying a
thumbnail of the image?

Margus

Jon Berndt wrote:
> 
> I am creating an image using povray running under Linux. My command line is
> this:
> 
> %x-povray -IVoyager.pov -D -L/var/povray/include +H768 +W1024
> 
> This results in a .tga file which is over 2 mb in size. However, displaying
> this in a paint program shows a 100x100 image. I find this strange. I
> suspect a .ini file is being used without my knowledge. How can I get around
> this?
> 
> Oh, BTW, following the completion of my render, I get this:
> 
> .......................................................
> 
> Creating bounding slabs.
> Scene contains 78133 frame level objects; 1 infinite.
> 
> Creating vista buffer.
> Creating light buffers....
> Rendering...
> Done Tracing
> Voyager.pov Statistics, Resolution 1024 x 768
> 
> As you can see, the resoultion appears to be correct ....???
> 
> jon
> 
> ====================================================
> Jon & Frances Berndt
> email: jsb### [at] hal-pcorg, fan### [at] hal-pcorg
> WWW: http://www.hal-pc.org/~jsb
> League City, TX
> ====================================================

Post a reply to this message

> I am 99.9% sure that all is well with the image. After all, if it is over
2
> megs, it can't be 100x100.
> It must be something with your paint program. Perhaps it's displaying a
> thumbnail of the image?

I don't know what happened, but everything seems to be OK, now. I'll try and
post the resulting image this evening.

Jon

Post a reply to this message

I could be possible that the paint program uses an external filter to load
the file. I had a similar problem with tif files, they were much lager then
they should be. I think this is because the filters output a vector image or
something like that, and the paint program converts it back to a bitmap.

I used Paint Shop Pro (on Windows 95), but with other paint programs
installed later that may have caused the problem.

In PSP, the WMF import size is set to 100x100 by default. You can make it
not to use external filters at File >Preferences >General> import filters.


> Jon Berndt <jsb### [at] hal-pcorg> wrote:
> : This results in a .tga file which is over 2 mb in size. However,
displaying
> : this in a paint program shows a 100x100 image. I find this strange. I
> : suspect a .ini file is being used without my knowledge. How can I get
around
> : this?
>
>   Are you sure you are looking at the right image? Are you sure that your
> paint program doesn't zoom out big images by default (like some do when
the
> image to be open is bigger than the window of the program).

--
Daniel Pirch
dpi### [at] gmxnet

Post a reply to this message

Jon Berndt wrote in message <384a755c@news.povray.org>...
>I am creating an image using povray running under Linux. My command line is
>this:
>
>%x-povray -IVoyager.pov -D -L/var/povray/include +H768 +W1024
>
>This results in a .tga file which is over 2 mb in size. However, displaying
>this in a paint program shows a 100x100 image. I find this strange. I
>suspect a .ini file is being used without my knowledge. How can I get
around
>this?


I ran into this problem as well with my custom compile of POV-Ray.  For
unknown reasons, the code for saving TGA images sometimes does not compile
properly, and as a result, the most significant byte of the image size is
not written properly.  The fix is as follows:

In file TARGA.C line 282 or so, fully parenthesize the four lines of code
for writing the image width and height, so that you get the following:

      /* write width and height  Bytes 12 - 15 */

      putc(((*width) % 256), handle->file);
      putc(((*width) / 256), handle->file);
      putc(((*height) % 256), handle->file);
      putc(((*height) / 256), handle->file);

Then recompile POV-Ray.  This should fix the problem.

Mark

Post a reply to this message

On Tue, 7 Dec 1999 00:49:35 -0500, "Mark Wagner"
<mar### [at] gtenet> wrote:

>I ran into this problem as well with my custom compile of POV-Ray.  For
>unknown reasons, the code for saving TGA images sometimes does not compile
>properly, and as a result, the most significant byte of the image size is
>not written properly.  The fix is as follows:
>
>In file TARGA.C line 282 or so, fully parenthesize the four lines of code
>for writing the image width and height, so that you get the following:
>
>      /* write width and height  Bytes 12 - 15 */
>
>      putc(((*width) % 256), handle->file);
>      putc(((*width) / 256), handle->file);
>      putc(((*height) % 256), handle->file);
>      putc(((*height) / 256), handle->file);
>
>Then recompile POV-Ray.  This should fix the problem.
>
>Mark

Mark, if this is a bug, and this is a fix (and they seem to be), would
you please post a proper bug report to povray.bugreports? Thank you.
This seems to be very platform- and compiler-specific, but still, if
it is a problem...

I would check this myself but I don't have a compiler installed (yeah,
I have Cygnus and Linux but I don't feel like messing with my already
installed Linux POV; call me a wimp :) )


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

In article <K+VMOJjc8SPbYBb12fbq=tY0T+bl@4ax.com> , Peter Popov 
<pet### [at] usanet>  wrote:

>>I ran into this problem as well with my custom compile of POV-Ray.  For
>>unknown reasons, the code for saving TGA images sometimes does not compile
>>properly, and as a result, the most significant byte of the image size is
>>not written properly.  The fix is as follows:
>>
>>In file TARGA.C line 282 or so, fully parenthesize the four lines of code
>>for writing the image width and height, so that you get the following:
>>
>>      /* write width and height  Bytes 12 - 15 */
>>
>>      putc(((*width) % 256), handle->file);
>>      putc(((*width) / 256), handle->file);
>>      putc(((*height) % 256), handle->file);
>>      putc(((*height) / 256), handle->file);
>>
>>Then recompile POV-Ray.  This should fix the problem.
>>
>>Mark
>
> Mark, if this is a bug, and this is a fix (and they seem to be), would
> you please post a proper bug report to povray.bugreports? Thank you.
> This seems to be very platform- and compiler-specific, but still, if
> it is a problem...

No, it is not a bug in POV-Ray! It is a compiler/library specific problem.
The code POV-Ray uses is legal in ANSI C and should work without problems if
the compiler is configured properly and supports ANSI C. It might also just
be a library problem, where the library uses signed char (usually "char" is
signed). I.e. if the library does an assignment like  "int i; char c = i;"
you will get such problems. If you have the source of the library, you can
fix it by searching in function fputc any assignment of the parameter from a
"char" to an "unsigned char".


     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