Probably the most important place we use it is in maketx! The headers of textures contain the SHA-1 of original pixels (and some salt thrown in for certain options) so that the TextureSystem can recognize textures that are exact duplicate of each other (this comes up surprisingly often in a production environment).
The use of SSL is for performance, aimed strictly at reducing the amount of time it took to maketx large textures. In timings, it performed better than our native one, and since OpenSSL was so widely available, I just used its call rather than do the work to speed ours up. You can disable it with USE_OPENSSL=0 at build time. There is no harm in doing so, other than somewhat slower maketx speed. I'll redo some timings on large textures and see how much difference it makes. On Mar 5, 2015, at 8:59 PM, Shane Ambler <[email protected]> wrote: > > I really hadn't looked at oiio using openssl before, the sha1 from > openssl being chosen for performance reasons. > > Also libOpenImageIO links against libssl and libcrypto which seems > unnecessary. By comparison git uses sha1 and only links to libcrypto. > > As part of the ImageBufAlgo compare - is idiff the only place that the > sha1 is used within the oiio package? > > While I know every machine has some variation of ssl installed, an > image library isn't a likely candidate for needing ssl which can raise > questions. Can the built-in sha1 be improved? Is it worth the effort? > Is there other bsd friendly hashing source code available that could be > included? > > I guess after all the openssl flack has settled down everything using > ssl is getting a checkup. > > -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
