 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] yahoo com> wrote:
: r, g, b - unclipped RGB colors.
: x, y, z - intersection point.
: u, v - UV coordinates.
: depth - distance to intersection point.
: inorm_x, inorm_y, inorm_z - surface normal at intersection point.
: pnorm_x, pnorm_y, pnorm_z - perturbed surface normal.
: dir_x, dir_y, dir_z - ray direction(if I succeed in adding it to
: the available information).
Don't tell me all this is stored into memory in order to be able to apply
the post processing?
Hmm... Let's count.
If we make a 1024x768 image that would be 786432 pixels.
I suppose that the floating point numers are of 'double' type, which means
8 bytes (in PC and most other systems).
This means that for each pixel the rgb info will take 3*8 bytes, the
intersection point 3*8 bytes, the uv-coordinates 2*8 bytes, the depth 8
bytes, surface normals and perturbed normals 6*8 bytes and finally the ray
direction 3*8 bytes.
Summing all this up we get:
786432*(3*8+3*8+2*8+8+6*8+3*8) = 113246208 bytes = 108 Megabytes.
Taking into account that the average computer has 128 Megabytes of memory,
that would eat it up pretty efficiently.
If all this is not stored into memory, then forget this :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Btw, I think this is a good idea. Keep up the good work :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <390835eb@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Don't tell me all this is stored into memory in order to be able to
> apply the post processing?
>
> Hmm... Let's count.
> If we make a 1024x768 image that would be 786432 pixels.
> I suppose that the floating point numers are of 'double' type, which
> means 8 bytes (in PC and most other systems).
True for most of these, but the COLOUR type is an array of 3 floats, not
doubles.
> This means that for each pixel the rgb info will take 3*8 bytes, the
> intersection point 3*8 bytes, the uv-coordinates 2*8 bytes, the depth
> 8 bytes, surface normals and perturbed normals 6*8 bytes and finally
> the ray direction 3*8 bytes.
> Summing all this up we get:
> 786432*(3*8+3*8+2*8+8+6*8+3*8) = 113246208 bytes = 108 Megabytes.
>
> Taking into account that the average computer has 128 Megabytes of
> memory, that would eat it up pretty efficiently.
>
> If all this is not stored into memory, then forget this :)
Currently, only the needed data is saved. Each post_process has a set of
flags indicating which data it needs, and only that data is
saved/loaded. This would be harder to do with the color_function filter,
since you would have to detect which functions and/or variables are
used, but it should still be possible.
Also, I don't know if this is the way it already is done, but it should
be possible to save to a file and only read in the data as it is used.
This would slow down some post_processes though...it would probably be
best as an option that people could turn on for lower-memory systems.
--
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] yahoocom> writes:
> In article <390835eb@news.povray.org>, Warp <war### [at] tagpovrayorg>
> wrote:
>
> > Don't tell me all this is stored into memory in order to be able to
> > apply the post processing?
[...]
> > Summing all this up we get:
> > 786432*(3*8+3*8+2*8+8+6*8+3*8) = 113246208 bytes = 108 Megabytes.
> >
> > Taking into account that the average computer has 128 Megabytes of
> > memory, that would eat it up pretty efficiently.
> >
> > If all this is not stored into memory, then forget this :)
>
> Currently, only the needed data is saved. Each post_process has a set of
> flags indicating which data it needs, and only that data is
> saved/loaded. This would be harder to do with the color_function filter,
> since you would have to detect which functions and/or variables are
> used, but it should still be possible.
> Also, I don't know if this is the way it already is done, but it should
> be possible to save to a file and only read in the data as it is used.
> This would slow down some post_processes though...it would probably be
> best as an option that people could turn on for lower-memory systems.
Mmmh, I don't like the idea of saving a temporary file that has several
times the size of the final image. Perhaps you should consider to apply
the filter on the fly. I know that you need more than one pixel a time for
several of the exististing and proposed filters. Perhaps it is possible
to determine which one you need and forget the others.
Thomas
--
http://thomas.willhalm.de/ (includes pgp key)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas Willhalm wrote:
> Mmmh, I don't like the idea of saving a temporary file that has several
> times the size of the final image. Perhaps you should consider to apply
> the filter on the fly. I know that you need more than one pixel a time for
> several of the exististing and proposed filters. Perhaps it is possible
> to determine which one you need and forget the others.
>
What about the possibility of aborting/continuing a trace ? It's already a
problem with the current post-processing implementation (focal blur behaves
strangely when a trace that have been aborted is resumed).
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <390835eb@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Don't tell me all this is stored into memory in order to be able to apply
> the post processing?
If you look into the MegaPOV 0.4 source code you will find that a maximum of
160 bytes per pixel are in memory (using the default COLORs are float (4
byte) and DBL is double (8 byte)). However, there are several flags in
there which I guess reduce the amount of data stored per pixel.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 27 Apr 2000 18:35:08 +0200, Thomas Willhalm <tho### [at] willhalmde>
wrote:
>Mmmh, I don't like the idea of saving a temporary file that has several
>times the size of the final image. Perhaps you should consider to apply
>the filter on the fly. I know that you need more than one pixel a time for
>several of the exististing and proposed filters. Perhaps it is possible
>to determine which one you need and forget the others.
A few thoughts come to mind:
Not all filters can be performed "on the fly."
Photoshop, probably the most respected image processing program on the
planet, uses its own swap file to store temporary image data while
processing an image. This swap file easily grows to many times the
size of the original image. It's just the nature of image processing.
I will admit that the POV post_processing represents an unusual
situation, in that we have so many additional attributes per pixel, in
addition to the typical R, B, and G values. If all these values are
stored in a temp file, it will indeed be many times larger than the
final output file. On the bright side, at least this file will be
deleted, and isn't permenant. :)
Also this large array of potential attributes to work with, offers
many interesting possiblities for filters that can't be implemented
in a 2D program like Photoshop. For example, we have the potential to
create a *much better* "trace contour" filter than the one in
Photoshop. The one in Photoshop is based solely on altering the tonal
range of the image, with no knowledge of the actual geometry of the
scene. In our case we can not only take tonal information into
account, but we have access to the actual geometry of the scene. We
can find exactly where the edge of an object is, and not have to guess
based on a change in pixel brightness.
So yes, some filters would need large amounts of memory or temp/swap
files, but there is probably little we can do about it, especially for
some of the proposed filters. We could probably at least arrange to
store only the attributes that a given filter actually needs, instead
of storing everything. That way, a extremely large temp file would
only be generated if you used a filter that required one.
Later,
Glen Berry
( Remove the "7" from 7no### [at] ezwvcom to email me. )
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry wrote:
> Photoshop, probably the most respected image processing program on the
> planet, uses its own swap file to store temporary image data while
> processing an image. This swap file easily grows to many times the
> size of the original image. It's just the nature of image processing.
And let's face it, not all computers are created equal or have the same
amount of ram available. There are a few scenes I have had to abort
development on simply because I did not have the system resources to
support the features and number of objects I was trying to work with.
I am certainly not going to blame the program for my system's shortcomings.
If you want to play with "big boy" computer programs you should be ready
to spend the money on the equipment needed to support them.
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken actually agrees with something I said? Let me mark this on the
calendar. It's a rare day. :)
Later,
Glen Berry
( Remove the "7" from 7no### [at] ezwvcom to email me. )
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <qqm### [at] schlattfmiuni-konstanzde>, Thomas
Willhalm <tho### [at] willhalmde> wrote:
> Mmmh, I don't like the idea of saving a temporary file that has several
> times the size of the final image.
It is better than trying to keep it all in RAM!
> Perhaps you should consider to apply the filter on the fly. I know
> that you need more than one pixel a time for several of the
> exististing and proposed filters. Perhaps it is possible to determine
> which one you need and forget the others.
This would probably be quite difficult...currently, a filter can access
any position in the data "images". To do this, you would have to do it
during rendering, and would probably have to place restrictions on the
possible things the filters can do. Either that, or recalculate the data
as it is required...which could get extremely slow. Most people have
enough disk space.
And what is wrong with a temporary file anyway?
--
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
