|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am interested in publishing a program that would in turn call upon POV Ray
to render an output image.
The image, actually a series of images, would be something like a building
'walk-through'.
Is there ant way in which the source .POV file could be encrypted so that
the user would not have access to this source.
This problem comes from my potential use of materials that are covered by a
copywrite, where the copywrite owner dictates that I may freely use and
publish the material in a final image format but may not divulge the source
data.... tricky !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Vincent-Jones <geo### [at] galaxynetcom> wrote:
: Is there ant way in which the source .POV file could be encrypted so that
: the user would not have access to this source.
Nope.
Povray itself have to get, some way or another, a valid pov source code to
read. So if povray can get it, then the user can get it as well.
Of course one way of "dumb-encrypting" the file would be to code it in
some way into a string or into an array of numbers and then making a loop
that writes parts of the encoded code into a file and then includes that
file (this could be made in parts so that only a part of the file is in
non-encrypted form at a time).
This, of course, would stop only the most newbies from getting your code.
It would not require much knowledge about the pov-script to modify the loop
a bit so that it writes everything to a file and that's it.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
if you are writing the program that will send it to povray, you could
make your own encription file that is decoded to a temporary pov file at
runtime and then erased when the image is done....?
Warp wrote:
>
> David Vincent-Jones <geo### [at] galaxynetcom> wrote:
> : Is there ant way in which the source .POV file could be encrypted so that
> : the user would not have access to this source.
>
> Nope.
> Povray itself have to get, some way or another, a valid pov source code to
> read. So if povray can get it, then the user can get it as well.
>
> Of course one way of "dumb-encrypting" the file would be to code it in
> some way into a string or into an array of numbers and then making a loop
> that writes parts of the encoded code into a file and then includes that
> file (this could be made in parts so that only a part of the file is in
> non-encrypted form at a time).
> This, of course, would stop only the most newbies from getting your code.
> It would not require much knowledge about the pov-script to modify the loop
> a bit so that it writes everything to a file and that's it.
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ryan constantine <rco### [at] yahoocom> writes:
> if you are writing the program that will send it to povray, you could
> make your own encription file that is decoded to a temporary pov file at
> runtime and then erased when the image is done....?
Copying the temporary pov file while POV-Ray is working would be easy.
You could pipe the source code directly to POV-Ray, but again it is
easy to get the code: Simply replace POV-Ray by a script that saves
the file to disk.
As warp already wrote:
"So if povray can get it, then the user can get it as well."
You can only make it a little bit obscure how to get it.
Thomas
--
http://thomas.willhalm.de/ (includes pgp key)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas Willhalm wrote:
>
> As warp already wrote:
> "So if povray can get it, then the user can get it as well."
> You can only make it a little bit obscure how to get it.
>
Isn't this true for any encryption, though? At varying levels of difficulty, of
course.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Margus Ramst <mar### [at] peakeduee> wrote:
: Isn't this true for any encryption, though? At varying levels of difficulty, of
: course.
In this type of cases, yes.
It's easy to understand with a better example:
Suppose that you want to distribute an image so that people could only
watch it but not modify it, save it to another format, etc.
As you can quickly deduce, this is impossible. If the user can watch the
image, he can, for example, take a screenshot of it and save it to whatever
format he likes.
Even if he couldn't, he could decompile the program that shows the image
to see how does it decrypt the data and then do it by himself (of course this
is a lot more difficult if the program is an executable binary; but in this
case we are talking about an easy-to-understand interpreted scripting
language).
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Btw, just for curiosity:
It might be possible in Windows to create a program that shows an
image which can't be taken a snapshot of: Using DirectDraw to draw the image
directly on screen.
A snapshot will only get a uniform color designed to that area in the
desktop instead of the image itself. This happens with my TV card. It uses
DirectDraw to show the TV image on screen, but if I try to take a snapshot
of the screen, I only get a magenta square where the TV image should be
(I suppose that this is because the snapshot is not taken directly from
video memory).
Of course the TV program itself has a snapshot feature to overcome this
problem (I think it takes the image directly from the data sent by the card).
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it David Vincent-Jones who wrote:
>I am interested in publishing a program that would in turn call upon POV Ray
>to render an output image.
>The image, actually a series of images, would be something like a building
>'walk-through'.
>Is there ant way in which the source .POV file could be encrypted so that
>the user would not have access to this source.
>This problem comes from my potential use of materials that are covered by a
>copywrite, where the copywrite owner dictates that I may freely use and
>publish the material in a final image format but may not divulge the source
>data.... tricky !
>
Wouldn't it also be quite tricky to develop such a system that didn't
violate the terms of povlegal.doc?
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> It might be possible in Windows to create a program that shows an
> image which can't be taken a snapshot of: Using DirectDraw to draw the image
> directly on screen.
The image must still be written to video memory, so if you can read video memory
you can read the image, no? It is quite possible to take screenshots from - say
- DirectDraw games, so in what way would the video display be diffrent?
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The problem that I am facing is that some of my source data will be
extracted directly from proprietary .dxf files that are currently being
commercially sold.
The only really critical area that would need concealing would be the
<x,y,z> co-ordinates.
Of course I have to convert the data to a .pov script for usage but the data
owner insists that the data must be secured so that the .pov script cannot
be used to reverse engineer the original file.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |