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

In article <fnMIOTUUN9bxt3LPOpYLvXWLF9LA@4ax.com>, Glen Berry 
<7no### [at] ezwvcom> wrote:

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

This is already done...each filter has a set of flags for the types of 
information it uses, and only that information is saved. Or were you 
talking about only saving information for pixels that will be used? That 
probably wouldn't have much of a gain, since most filters use all of the 
pixels...

-- 
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 <qqm### [at] schlattfmiuni-konstanzde>, Thomas 
> Willhalm <tho### [at] willhalmde> wrote:
> > 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?

My small hard disc ;-)

I wasn't aware that most filters use much more than a few pixels at a time.
In future, I will be more patient and watch the implementations coming 
before I doubt their usefulness.

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote:
: True for most of these, but the COLOUR type is an array of 3 floats, not 
: doubles.

  So we get:
  786432*(3*4+3*8+2*8+8+6*8+3*8) = 103809024 bytes = 99 Megabytes.

  Not much difference.

: Currently, only the needed data is saved.

  But if the function uses all the parameters, it will take the maximum
amount?

  If the function is applied in a pixel-by-pixel basis, regardless of the
other pixels, why can't it be done on the fly, as someone else suggested?
It would certainly save lots of memory and/or disk space usage.
  And I don't think that writing and then reading 100 Megs of data to/from
disk is the fastest operation possible...

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

Warp <war### [at] tagpovrayorg> wrote...

>   If the function is applied in a pixel-by-pixel basis, regardless of the
> other pixels, why can't it be done on the fly, as someone else suggested?
> It would certainly save lots of memory and/or disk space usage.

However, limiting filters to a single pixel of data greatly limits the
functionality.  Almost all photoshop filters (including relatively simple
ones of the "filter factory" type) use access multiple pixels at a time.

-Nathan

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: However, limiting filters to a single pixel of data greatly limits the
: functionality.  Almost all photoshop filters (including relatively simple
: ones of the "filter factory" type) use access multiple pixels at a time.

  That's right, but I was referring to the coloring function only. The other
filters will still need data from the whole image, but hopefully not that
much.

-- 
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 <390abfe6@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   That's right, but I was referring to the coloring function only. 

Coloring function? You mean filters that only adjust the colors? Some of 
those would depend on multiple pixels too.
Filters are applied in order...you can't do 1-pixel filters first and 
only save the data in a file if a filter like blur is used. You would 
have to add a completely different filtering system to the code, it 
would make code maintenance and filter coding harder, and would really 
not have much of a benefit.
I really don't see the problem with the file caching idea...it is used 
for photon mapping, radiosity, etc. It is also what is used in image 
editing programs. I would like to see it extended to allow load_file and 
save_file, so the render doesn't have to be redone every time...the size 
really only becomes a problem on large render sizes with every possible 
filter, something that would be quite rare. Most filters only require 
color information, and only the necessary data is saved. If space is so 
tight that you can't have a program generate a temporary file about 
10.5MB (1024*768*(5*2-byte color components + one 4-byte depth 
component, color and depth seem to be the most commonly used)), I 
suggest you clean out your hard drive. :-)


> The other filters will still need data from the whole image, but 
> hopefully not that much.

?
They will still need all the data they needed before...and if one 
multi-pixel filter is used, all of the filters would have to be done the 
way things currently are done.

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