Bill,
Yes, that is the basic idea... whatever is going to be the least demanding
on system memory will work best. Use actual thumbnails when possible; load
images into memory only when needed.
Thanks for the additional info. One question: Does alwaysBuffer
really mean anything if an image is added directly into a stack [as
opposed to adding it by reference]? It seems to me an image included
in a stack file is always in memory once the stack is opened.
Another method to consider is to keep the images out of the stack; encrypt
the images on disk (encrypt command); and decrypt them (decrypt command) as
they are loaded. This will make them slightly larger on disk and use more
memory, but it will keep your stack small and stable.
Yes, it is a possibility.
Keep in mind that without extreme workarounds (i.e., using certain DirectX
routines), images are never really secure on a computer; a press of the
Print Screen button will put that picture on the clipboard. By embedding
them in a stack or encrypting the image files on disk, you're only making it
a little less difficult to access them.
I understand. It's a lot like anti-hacker protection: it's never
going to be 100% effective, and there comes a point of diminishing
returns where the additional protection is not worth the programming effort.
But here's a larger [& somewhat off topic] question:
Suppose one is creating a portfolio of photographic
art. Furthermore, assume the "original" photographs are sold as
"one-of-a-kind" photos, with the proviso that the original electronic
photo image is "destroyed" after a print is made. How does one
provide a likeness of the image (in 5 MPix detail) without providing
access to the image file itself?
Rob Cozens, CCW
Serendipity Software Company
Vive R Revolution!
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
