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

Chris Huff <chr### [at] yahoocom> wrote:
: 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. :-)

  I counted about 105 MB, not 10.5 MB. That's a whole lot more.

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

>   I counted about 105 MB, not 10.5 MB. That's a whole lot more.

It sure is, you are off by a factor of 10.

1024*768 = 786432
5 color components per pixel at 2 bytes each, plus one depth value at 4 
bytes:
14 bytes per pixel

786432*14 = 11010048 bytes per 1024*768 image processed with filters 
using depth and color(the two most commonly used variables).

11010048/1048576(the number of bytes in a megabyte) = 10.5 MB.

Remember that only the necessary information is saved...I think 
"find_edges" and "normal" are the only ones which use normal 
information, and none use UV coordinates or intersection point. 
Including the post_process filters I made, the only ones which use depth 
are "stars", "normal", "find_edges", "focal_blur", and "depth". Most 
only use color information, which has to be stored in some form anyway. 
If only those filters are used, you have a 7.5MB temporary file for a 
1024*768 image.

-- 
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> wrote:
: 5 color components per pixel at 2 bytes each

  You said earlier that the color components are stored as floats.

: Remember that only the necessary information is saved...

  I was calculating the worst case scenario, where everything is needed.

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

> Chris Huff <chr### [at] yahoocom> wrote:
> : 5 color components per pixel at 2 bytes each
> 
>   You said earlier that the color components are stored as floats.

Of course, that should be 4 bytes.
That would be 15MB for filters which only use color, and 21MB for 
filters using color and depth. Not tiny files, but certainly a lot 
smaller than 100MB. And since the are *temporary* files, they are gone 
when the render finishes.


> : Remember that only the necessary information is saved...
> 
>   I was calculating the worst case scenario, where everything is needed.

That scenario is currently impossible to reach, the filters don't exist 
for it...and if it was possible, most of them would be wasted anyway, 
since some(like depth or normal) would completely replace previously 
processed images.

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