clipka <ano### [at] anonymousorg> wrote:
> 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.

it would help if eval_pigment worked with uv-mapped meshes.

-Nekar Xenos-

Post a reply to this message