Is there a way to 'undefine' an image_map, once it has been loaded into memory
during the parsing of a scene? So that its memory is 'released'? AFAIU, using
#undef simply undefines the *identifier* for the image (not the image_map
itself), which is not what I'm talking about.

Here's a rather nutty example, to describe what I mean:

Let's say I want to use eval_pigment to pick out a single pixel's color at some
location in an image, in maybe 10,000 different image_maps(!)that are
consecutively numbered-- stepping through each image in a #for loop, for
example. Each image_map itself is no longer needed after that step, and could be
eliminated. Otherwise, those 10,000 images could take up a lot of memory.

Is the efficient way to do this simply a matter of re-#declaring each 'new'
image with the *same* identifier? (Assuming a proper-size array has already been
pre-#declared to hold the eval_pigment results):

#declare PIXEL_COLOR_ARRAY = array[9999];
#for(i,0,9999)
#local IMG = eval_pigment(...image_map and location...)
#declare PIXEL_COLOR_ARRAY[i] = IMG;
#end

Does the IMG variable just substitute one image_map for another, so that there's
only one image in memory at any one time? Or does the eval_pigment() macro
itself cause all 10,000 images to start accumulating into memory, without
'flushing' each image_map before it sees a new one? My understanding is that a
#macro does 'undefine' its #local variables automatically when the #macro use
has ended-- but again, that's just its *identifiers*, AFAIK-- not(?) any memory
that the #macro used.

Post a reply to this message

Am 12.07.2021 um 01:34 schrieb Kenneth:
> Is there a way to 'undefine' an image_map, once it has been loaded into memory
> during the parsing of a scene? So that its memory is 'released'? AFAIU, using
> #undef simply undefines the *identifier* for the image (not the image_map
> itself), which is not what I'm talking about.

As a general rule of thumb, whenever you "discard" an identifier's value 
(because you `#undef` it, assign a new value, re-define it as a macro, 
or whatever), any associated memory will automatically be released IF 
there doesn't exist another reference to that data.

Additional references will typically be created when you:

- assign the value to another variable, or
- "attach" the value to some other scene element, e.g. use an 
image-based pigment in an object.

Simply evaluating an image-based pigment will not create an additional 
reference.


There are a few exceptions to this:
- Some data will always be copied, rather than additional references 
created; and
- Some data will be cached because it is expected to re-occur later, and 
is sufficiently complicated to process that it would be a waste to do it 
all over again.

An example for the latter would be font files, which aren't discarded 
even when a `text` object is discarded, because POV-Ray anticipates that 
you might use the same font (and possibly also some of the characters) 
in other `text` objects.

POV-Ray doesn't cache image files, so you should be fine with what 
you're trying to do, even without any extra precautions.


TL;DR:

> Is the efficient way to do this simply a matter of re-#declaring each 'new'
> image with the *same* identifier? (Assuming a proper-size array has already been
> pre-#declared to hold the eval_pigment results):

Yup.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> Simply evaluating an image-based pigment will not create an additional
> reference.
>...
> POV-Ray doesn't cache image files, so you should be fine with what
> you're trying to do, even without any extra precautions.

That's all good news; thanks.
(Just to add a note: This particular usage...
#declare MY_IMAGE = pigment{image_map{...}}
does seem to cache the image_map for use later, without an apparent(?) increase
in memory when it is called multiple times in a scene...which is quite useful!
But it's a different construct from what we are talking about here.)

>
> There are a few exceptions to this:
> ...
> - Some data will be cached because it is expected to re-occur later, and
> is sufficiently complicated to process that it would be a waste to do it
> all over again.
>
> An example for the latter would be font files...

Just as a matter of curiosity: Is there a method within the SDL of purging even
such 'persistent' things from memory? I suspect not.

Post a reply to this message

Am 12.07.2021 um 17:57 schrieb Kenneth:

>> - Some data will be cached because it is expected to re-occur later, and
>> is sufficiently complicated to process that it would be a waste to do it
>> all over again.
>>
>> An example for the latter would be font files...
> 
> Just as a matter of curiosity: Is there a method within the SDL of purging even
> such 'persistent' things from memory? I suspect not.

Nope, not at the moment. If I'm not completely mistaken, such caches are 
discarded before the actual render starts though.

Post a reply to this message