"Peter J. Holzer" wrote:
> 
> Only 33 % if you use base 64 encoding. How do you get a factor of 3-4?
> 

I thought of a human readable form.

> 
> If you want to automate the process (e.g., for distributing a render
> over several computers) having to maintain a list of files is
> cumbersome. However, I think that having Povray to generate a list of
> all the files it read is enough for that task. It also has the advantage
> that you can easily generate Makefile rules from the output.

Exactly, it's much more flexible.

> > Remember that floating point numbers in binaries are not platform
> > independant.
> 
> Neither are integers. If you define a portable binary format, you will
> have to define the format of all its components, too.
> 

Reading integer files cross platform is not difficult, you just have to
take care of the byte order, which is easy and does not take much time,
see for example the png file format.  I don't know any file format which
works this way for floating point numbers.

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

Christoph Hormann wrote:
> 
> "Peter J. Holzer" wrote:
> >
> > Only 33 % if you use base 64 encoding. How do you get a factor of 3-4?
> >
> 
> I thought of a human readable form.

Not very useful for a human to be able to read the value
of the bytes of a PNG or JPG file!  :-)

-- 
Adrien Beau   adr### [at] freefr   http://adrien.beau.free.fr/

Post a reply to this message

Ze!nPs### [at] yahoocom writes:

> Povray should allow for including an image directly into the source
> file.  
> 

One way to do this would be to allow base64-encoded data (or similar)
in all places where you can put the name of an image file.

Post a reply to this message

On 2001-10-21 07:13, Christoph Hormann <chr### [at] gmxde> wrote:
> "Peter J. Holzer" wrote:
>> 
>> Only 33 % if you use base 64 encoding. How do you get a factor of 3-4?
>> 
> 
> I thought of a human readable form.

A human readable ASCII form for images? Like PPM ASCII or XPM? You get
much more than a factor of 3-4 for these compared to JPG (I just
converted a 600x600 pixel JPG (83k) to PPM: 4.2M, or a factor of 51!),
and they aren't really human readable except for tiny sizes. 

>> > Remember that floating point numbers in binaries are not platform
>> > independant.
>> 
>> Neither are integers. If you define a portable binary format, you will
>> have to define the format of all its components, too.
> 
> Reading integer files cross platform is not difficult, you just have to
> take care of the byte order, which is easy and does not take much time,
> see for example the png file format.  I don't know any file format which
> works this way for floating point numbers.

Just chose one: IEEE-754 big-endian for example.

Converting between different FP formats usually isn't more than
bitshifting, either. For the common case (IEEE-754 big- or little
endian) you can implement a "fast path" which reads directly or only
swaps bytes, for the rest you can implement a portable C version (this
is not completely trivial, but shouldn't be too difficult either - I
might take a stab at it just as a "proof of concept"). Or you can ignore
them completely, just as you can ignore ones-complement integers and
PDP-endian longs[1].

	hp

[1] Ok, I admit that I don't know any current architecture which doesn't
use strict big/little-endian twos-complement integers, but I know at
least two (Alpha in VAX-compatibility mode, Cray) which don't use
IEEE-754. However, Povray must be compiled in IEEE-754 mode on the Alpha
to work at all (The alpha will trap on denormalized numbers otherwise)
and I don't know enough about the Cray to know if that's a problem.

-- 
   _  | Peter J. Holzer    | Oder glaubst du "Bugtraq" waere eine
|_|_) | Sysadmin WSR       | Science-Fiction TV-Serie ueber Schaben
| |   | hjp### [at] hjpat         | im Weltall?
__/   | http://www.hjp.at/ |	-- Juergen P. Meier in dcsm

Post a reply to this message

On 2001-10-21 16:14, Peter J. Holzer <hjp### [at] hjpat> wrote:
> On 2001-10-21 07:13, Christoph Hormann <chr### [at] gmxde> wrote:
>> "Peter J. Holzer" wrote:
>> I don't know any file format which works this way for floating point
>> numbers.
> 
> Just chose one: IEEE-754 big-endian for example.

s/chose/choose/, of course.

	hp

-- 
   _  | Peter J. Holzer    | Oder glaubst du "Bugtraq" waere eine
|_|_) | Sysadmin WSR       | Science-Fiction TV-Serie ueber Schaben
| |   | hjp### [at] hjpat         | im Weltall?
__/   | http://www.hjp.at/ |	-- Juergen P. Meier in dcsm

Post a reply to this message

Peter J. Holzer <hjp### [at] hjpat> wrote:
: A human readable ASCII form for images? Like PPM ASCII or XPM? You get
: much more than a factor of 3-4 for these compared to JPG (I just
: converted a 600x600 pixel JPG (83k) to PPM: 4.2M, or a factor of 51!),

  What a fair comparison. PPM and XPM are uncompressed while JPG is highly
compressed.
  You should have tested uuencoding the JPG.

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

Well, an option to compile a list of all the include files (including
images and density files) would be nice, with a recursive quality
additionally.    I'll have to look into that code at some point. It
would be a nice feature for say- Povray 3.6(heh, yeah right)  or 4.0 

I would be perfectly happy to be able to include images, in-line with
the code. This would provide at least two immediate advantages I can
see at the moment. 

#1. the possibility of making a single .pov file that doesn't depend
on any other files. 

#2. The possibility of dynamically generating images during the parse
phase.


If this were combined with say, a possible feature for binary file i/o
directives, you could add support for reading in almost any image file
format without having to patch the povray source code. 

I personally don't mind  the file size issues so much. You don't HAVE
to include images in line with the ascii source code, so if file size
is your concern you can just leave the files seperate. 

Triangle meshes consume a lot of file space in ascii format as well.
So it's not really setting a new precedent in that direction.

Yeay! free ramen noodles! I guess I'll end this message now so I can
eat them.

-Zen

Post a reply to this message

On 2001-10-21 19:30, Warp <war### [at] tagpovrayorg> wrote:
> Peter J. Holzer <hjp### [at] hjpat> wrote:
> : A human readable ASCII form for images? Like PPM ASCII or XPM? You
> : get much more than a factor of 3-4 for these compared to JPG (I just
> : converted a 600x600 pixel JPG (83k) to PPM: 4.2M, or a factor of
> : 51!),
>
>   What a fair comparison. PPM and XPM are uncompressed while JPG is
> highly compressed. You should have tested uuencoding the JPG.

Please read the last few messages again. My argument *was* that
base64-encoding (or uuencoding, which is almost the same thing) expands
a file only a factor of 1.33, not by 3-4, as Christoph claimed. But
Christoph corrected me that he was not talking about base64-encoding JPG
but about "human readable" ASCII picture formats.

	hp

-- 
   _  | Peter J. Holzer    | Oder glaubst du "Bugtraq" waere eine
|_|_) | Sysadmin WSR       | Science-Fiction TV-Serie ueber Schaben
| |   | hjp### [at] hjpat         | im Weltall?
__/   | http://www.hjp.at/ |	-- Juergen P. Meier in dcsm

Post a reply to this message

On Fri, 19 Oct 2001 19:03:11 GMT, Ze!nPs### [at] yahoocom wrote:

>Yes I know it's been done before in a special patched version of
>povray at some point. But very poorly. (POB format)
>
>Basically, What I'd like to be able to do is compile a scene- with all
>it's various include files and image files and data files- into a
>single compressed binary file. Or at least into a single in line ascii
>file - like say.. a pdf. 
>

Dunno about the included images, but I guess you could write a .pov
file that (when run) would open a specified .pov file and then start
echoing lines from this input .pov file to a specified output file.
Whenever an "include" is hit, it would open the included file,
start reading from that, outputting its contents to the output file
instead of the "include" statement.

This would result in one .pov file containing verything except for
images and fonts.  I suppose you could write in a macro to list
all images and fonts references that occur in a pov file but that
would be a parse monster.

One other problem, if youy use the technique of having a .pov
file write a temp file and then include the just-created temp
file, the above method would fail.

Interesting problem.

Post a reply to this message

On Thu, 25 Oct 2001 23:43:32 GMT, nospam wrote:
> One other problem, if youy use the technique of having a .pov
> file write a temp file and then include the just-created temp
> file, the above method would fail.

My guess would be that nothing but a full-blown POV parser can predict what
a POV program will do, and that can only do so by running the program and
seeing what happens.  I suspect it's quite easy to map this problem to the
halting problem.

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