Am 01.01.2015 um 14:24 schrieb kevva:
> Whilst I do know the texture/pigment, it is to be an image, taken possibly by a
> real camera. Then a trace command or something similar could then be used to
> identify the colour of a particular pixel. Then, with the use of some creative
> pov code, I could create a second box with a colour that would have been
> manipulated by pov code. This box would then be set in just such a place so that
> the camera would see the box as a single pixel in the new pov made image. I
> could then devise a new colour to appear in the image, that pov would then
> produce. Thus, I could manipulate any image that I would choose using pov code
> to do it. Think of the possibilities I/we would be able to do anything to any
> image, so long as I/we could program it in. e.g. I could enhance a low
> resolution picture into a high res picture. If I could find a way of extracting
> all the stills from a film, manipulate them, then I could maybe enhance a low
> res film into a very high resolution film. Filling in data that can be found on
> other frames in the same scene. If this trace command where possible then it
> could be that this idea would become possible. The options are then only bounded
> by our imaginations. All done in pov code.

What you're looking for is the "eval_pigment" function.

> But as in the last version of VB that I used to program in (This was some time

> in this case) and writing in the new value. But rather than counting the number
> of bytes one could count the number of valid representations e.g. strings or
> floats perhaps. But I do feel that an update of the file handling is somewhat
> overdue.

While all contemporary file systems and operating systems support 
overwriting portons of a file with new content, this is always (with 
maybe a few exotic exceptions) limited to byte-for-byte replacement. To 
replace any sequence of bytes in a file with a sequence of bytes of 
different length, there is no other way than to (a) create a copy of the 
file with the desired changes and then replace the existing file with 
the new one, or (b) read in the remainder of the file, then overwrite 
the entire remainder of the file from the point of replacement.

Thus, implementing a bytewise replacement instruction is trivial, while 
a word-, line- or whatever-wise replacement instruction is non-trivial, 
time consuming, and would be an unnecessary waste of time to use 
multiple times on the same file.

As for a bytewise replacement instruction, it would only fit a very 
small portion of use cases, as the files operated on will typically be 
text-oriented rather than byte-oriented.

Post a reply to this message