Matthieu, can you confirm: * Does `oiiotool -info -v yourfile.dpx` also crash (with the same filename as you used before, of course)? Or does it only crash when the OIIO API calls are made from your program?
> On Apr 24, 2019, at 1:51 PM, Mathieu Prevot <[email protected]> wrote: > > Hello. Many thanks Till for your previous posts and proposition. > > I'm curious to know if the problems can be reproduced. > Here are the binaries of oiio, openexr and few dependencies, as well as their > source and the powershell script I use to configure/build/install those > libraries. > There is also the oiioTest project which I use to open the DPX 10bits image. > The debug and release configuration are those I used to far. The debug should > work and the release should trigger the memory exception, at least certainly > when you ask to inline whenever possible. > I'm using boost 1.70, the available for download binaries. Everything in x64. > > https://1drv.ms/f/s!AlUmbfQiLoTZhFUTthzeUkWoB3rc > <https://1drv.ms/f/s!AlUmbfQiLoTZhFUTthzeUkWoB3rc> > > I built the libraries with the v141 toolset (the latest that comes with > VS2017; it also comes with VS2019). > I built the oiioTest with v142 as well as v141, and I observed the same > result in both cases. > I'll do them again to be certain. > I'll try Larry's patches to get to know more, and then post here again. > > I'll also try Till's binaries, but I can tell already that those binaries are > missing: > RAW_R.DLL (?) > BOOST_FILESYSTEM-VC141-MT-X64-1_66.DLL (no problem to get those boost > libraries) > BOOST_THREAD-VC141-MT-X64-1_66.DLL > LZMA.DLL (?) > Maybe a script would be easier to use than binaries. > > M > > > Le mer. 24 avr. 2019 à 20:30, till dechent <[email protected] > <mailto:[email protected]>> a écrit : > My guess would be that VS2019 being the problem is unlikely since Mathieu > also tried with the vs141 toolset. > > To narrow things down between a compile issue and a code issue you could grab > my binaries and see if your code works with them: > https://github.com/ttddee/oiio-msvc2017 > <https://github.com/ttddee/oiio-msvc2017> > > Or maybe try a build without the command line and go straight from CMake to > Visual Studio to compile from there. > > I have a Windows machine here so if you need me to try anything, happy to > help! > > > > Am Mi., 24. Apr. 2019 um 18:41 Uhr schrieb Larry Gritz <[email protected] > <mailto:[email protected]>>: > I'm sorry to ask you to be my debugging robot, but since I can't seem to > reproduce on my end... > > > So let's try another thing. At the call site, > > std::cout << "reading (float) file: " << filename << "\n"; > string filename2 = filename; > std::cout << "filename2 addr = " << (void*)&filename2 << std::endl; > std::cout << "filename2 len = " << filename2.size() << std::endl; > std::cout << "filename2 = '" << filename2 << "'\n"; > auto in = ImageInput::open(filename2); > > And inside get_rest_arguments: > > bool > Strutil::get_rest_arguments(const std::string& str, std::string& base, > std::map<std::string, std::string>& result) > { > std::cout << "str addr = " << (void*)&str << std::endl; > std::cout << "str len " << str.size() << std::endl; > std::cout << "str chars = '" << str << "'" << std::endl; > std::string::size_type mark_pos = str.find_first_of("?"); > std::cout << "result of find_first_of is " << mark_pos << std::endl; > ... rest of function as before ... > > So I'm just trying to establish that we're really getting a reference to the > same string we thing we were passing, and also whether any access to str > (including the length) is problematic, or just accessing the characters. > > > Now, I have one other hypothesis in the back of my mind. You said you were > using VS2019. I know that people have been using 2015 and 2017, but I'm > wondering if 2019 is the issue here. In particular, is there any chance that > VS2019 has changed the representation of std::string (akin to how gcc changed > its std::string representation in the ~gcc5 time frame)? And perhaps is it > possible that OIIO's dll itself was compiled with one string representation > but your program (separate compilation unit) used an incompatible one, so > that you are passing what you think is a reference to a std::string but the > OIIO code it's calling has a different idea of the internal layout of a > std::string? > > Or is there any other way that the caller and callee (which are in different > compilation units and different dlls) might have a different idea of what a > std::string means? > > Ring any bells for anyone? > > >> On Apr 24, 2019, at 1:22 AM, Mathieu Prevot <[email protected] >> <mailto:[email protected]>> wrote: >> >> Yes, there might be something wrong in my locales, `str` could not be read ( >> "error reading characters of string" , in my previous post) and `filename` >> was undefined. >> However, that's not necessarily the problem, the memory is allocated and I >> have the same size as in debug (79 characters). >> Before ImageInput::open, I print filename to stdout, and I see a correct >> result. >> >> cout << "reading (float) file: " << filename; >> auto in = ImageInput::open(filename); >> >> The right way to be able to read filename is to make a local copy; also I >> make certain that I got the correct type (string), even though string has a >> default constructor from const char. >> >> cout << "reading (float) file: " << filename; >> string filename2 = filename; >> auto in = ImageInput::open(filename2); >> >> It might be related to the character set, but I don't think since it did not >> change from debug to release. >> https://stackoverflow.com/questions/9349342/about-the-character-set-option-in-visual-studio >> >> <https://stackoverflow.com/questions/9349342/about-the-character-set-option-in-visual-studio> >> >> >> In order to acertain this, I did set the character set to "not set" and >> tried also "unicode", but I stil got the same memory error. >> Here the compile command with "not set" ( /D "_UNICODE" /D "UNICODE" are >> removed): >> >> /permissive- /Yu"pch.h" /GS /GL /W3 /Gy /Zc:wchar_t /I"c:\lib\tiff\include" >> /I"c:\lib\openexr\include" /I"c:\lib\oiio\include" /Zi /Gm- /O2 /sdl >> /Fd"x64\Release\vc142.pdb" /Zc:inline /fp:precise /D "NDEBUG" /D "_CONSOLE" >> /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /std:c++17 /FC >> /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" >> /Fp"x64\Release\oiioTest.pch" /diagnostics:classic >> >> `auto` was `const char*`, therefore did not change a thing. >> >> With the new lines you suggested, the memory error happens at the first str >> usage, ie., str.size(). >> >> std::cout << "str len " << str.size() << " = '" << str << "'" << >> std::endl; // memory error here >> std::string::size_type mark_pos = str.find_first_of("?"); >> std::cout << "result of find_first_of is " << mark_pos << std::endl; >> >> I tried the local copy with: >> >> std::string str2 = str; // memory error here >> std::string::size_type mark_pos2 = str2.find_first_of("?"); >> std::string::size_type mark_pos = str.find_first_of("?"); >> >> The memory error happens at the str2 affectation; str has size 79 >> (expected), and cannot be read, str2 has size 0, allocated 0. >> >> Not sure where to go next. >> Mathieu >> >> >> Le mer. 24 avr. 2019 à 08:26, Larry Gritz <[email protected] >> <mailto:[email protected]>> a écrit : >> Do you know what your "locale" is? Anything unusual? >> >> I'm also wondering about the /D "_UNICODE" /D "UNICODE" >> What happens if you don't do that? >> >> Your line, >>> auto path = >>> "C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00001926.DPX"; >> >> I wonder if you instead used >> >> const char* path = >> "C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00001926.DPX"; >> >> if that changes anything? >> >> The other idea I had is in get_rest_arguments (src/libutil/strutil.cpp), >> could you instrument it like this just to see what happens: >> >> bool >> Strutil::get_rest_arguments(const std::string& str, std::string& base, >> std::map<std::string, std::string>& result) >> { >> std::cout << "str len " << str.size() << " = '" << str << "'" << >> std::endl; >> std::string::size_type mark_pos = str.find_first_of("?"); >> std::cout << "result of find_first_of is " << mark_pos << std::endl; >> ... rest of function as before ... >> >> and see if there is anything interesting printed immediately prior to the >> crash? >> >> >> >>> On Apr 23, 2019, at 2:53 PM, Mathieu Prevot <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I use a debug oiio, and release project; in that case I managed to get a >>> call stack. >>> >>> `str` in `bool Strutil::get_rest_arguments(const std::string& str, >>> std::string& base, std::map<std::string, std::string>& result)` >>> has a problem ("error reading characters of string"). >>> >>> OpenImageIO.dll!OpenImageIO_v2_1::Strutil::get_rest_arguments(const >>> std::basic_string<char,std::char_traits<char>,std::allocator<char> > & str, >>> std::basic_string<char,std::char_traits<char>,std::allocator<char> > & >>> base, >>> std::map<std::basic_string<char,std::char_traits<char>,std::allocator<char> >>> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >>> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> >>> > >>> >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> >>> > const >>> ,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > > >>> & result) Line 270 C++ >>> >>> OpenImageIO.dll!OpenImageIO_v2_1::ImageInput::create(const >>> std::basic_string<char,std::char_traits<char>,std::allocator<char> > & >>> filename, bool do_open, const OpenImageIO_v2_1::ImageSpec * config, >>> OpenImageIO_v2_1::string_view plugin_searchpath) Line 512 C++ >>> >>> OpenImageIO.dll!OpenImageIO_v2_1::ImageInput::open(const >>> std::basic_string<char,std::char_traits<char>,std::allocator<char> > & >>> filename, const OpenImageIO_v2_1::ImageSpec * config) Line 106 C++ >>> > oiioTest.exe!DPXio::ReadFloat(char *) Line 31 C++ >>> >>> Here my function: >>> >>> auto DPXio::ReadFloat(const char* filename) -> SparseArray<float>* >>> { >>> auto in = ImageInput::open(filename); >>> if (!in) return nullptr; >>> >>> auto spec = in->spec(); >>> DPXfloat.SetSize(spec); >>> in->read_image(TypeDesc::FLOAT, DPXfloat.Values); >>> in->close(); >>> >>> return &DPXfloat; >>> } >>> >>> and it is called this way: >>> >>> auto sut = new DPXio(); >>> auto path = >>> "C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00001926.DPX"; >>> //auto path = >>> "C:/sensomovie/C200/A014C203_190414BL_CANON_16bits/A014C203_190414BL_CANON_00001331.DPX"; >>> >>> std::cout << (FileExist(path) ? "File OK: " : "No such file: ") << path >>> << "." << endl; >>> >>> auto result = sut->ReadFloat(path); >>> if (result == nullptr) >>> cout << "null result" << endl; >>> else >>> { >>> cout << "colors: " << result->Colors << endl; >>> cout << "width: " << result->Width << endl; >>> cout << "height: " << result->Height << endl; >>> } >>> >>> The compilation arguments (I'm using VS2019 enterprise, toolset Visual >>> Studio 2019 (v142), but I have the same with v141): >>> >>> /permissive- /Yu"pch.h" /GS /GL /W3 /Gy /Zc:wchar_t /I"c:\lib\tiff\include" >>> /I"c:\lib\openexr\include" /I"c:\lib\oiio\include" /Zi /Gm- /O2 /sdl >>> /Fd"x64\Release\vc142.pdb" /Zc:inline /fp:precise /D "NDEBUG" /D "_CONSOLE" >>> /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi >>> /MD /FC /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" >>> /Fp"x64\Release\oiioTest.pch" /diagnostics:classic >>> >>> M >>> >>> >>> Le mar. 23 avr. 2019 à 23:39, till dechent <[email protected] >>> <mailto:[email protected]>> a écrit : >>> Yes I built version 2.0.6 as a release (x64) and it worked. I also tried >>> the DPX you provided and all was good. >>> >>> Am Di., 23. Apr. 2019 um 21:44 Uhr schrieb Mathieu Prevot >>> <[email protected] <mailto:[email protected]>>: >>> Please, can those who could open images with `ImageInput::open(filename)` >>> tell if it was a release or debug build (of their own binary, not oiio's) ? >>> If it was a debug, can you test with a release build ? >>> >>> Many thanks >>> M >>> >>> Le lun. 22 avr. 2019 à 16:35, Mathieu Prevot <[email protected] >>> <mailto:[email protected]>> a écrit : >>> Tested with boost 1.68 and 1.70, both are OK with oiio debug, and opening >>> the DPX file works correctly in that configuration. >>> Only when I build and use oiio release, it fails (with both boost versions). >>> >>> I'm not sure where to go to continue the investigation. >>> >>> For repro, my build script; which needs to be run in the ooio-master folder >>> as is. msbuild needs to be in $path. >>> >>> $target = "Visual Studio 15 2017 Win64" >>> >>> function configure { >>> >>> I:\IntelSWTools\compilers_and_libraries_2019.3.203\windows\tbb\bin\tbbvars.bat >>> intel64 vs2017 >>> cmake.exe -G $target -T v141, host=x64 -j16 ` >>> >>> -DCMAKE_PREFIX_PATH="I:/lib/tiff;I:\lib\boost-1.70;I:/lib/zlib;I:/lib/libpng;I:/lib/openexr;I:/lib/libjpegturbo" >>> ` >>> >>> -DTBB_ROOT_DIR="I:/IntelSWTools/compilers_and_libraries/windows/tbb" ` >>> -DCMAKE_INSTALL_PREFIX="I:/lib/oiio-release" ` >>> -DJPEGTURBO_PATH="i:/lib/libjpegturbo" ` >>> -DUSE_QT=0 -DOIIO_BUILD_TESTS=1 -DUSE_PYTHON=0 ` >>> -DPYTHON_EXECUTABLE="I:/intelpython2/python.exe" ` >>> .. >>> } >>> >>> function build { >>> #"build oiio debug" >>> #MSBuild.exe OpenImageIO.sln /verbosity:m /m >>> "build oiio release" >>> MSBuild.exe OpenImageIO.sln /p:Configuration=Release /verbosity:m /m >>> } >>> >>> function install { >>> #"install oiio debug" >>> #MSBuild.exe INSTALL.vcxproj /verbosity:m /m >>> "install oiio release" >>> MSBuild.exe INSTALL.vcxproj /p:Configuration=Release /verbosity:m /m >>> } >>> >>> function clean { >>> if (test-path build) { >>> remove-item -recurse -force build >>> } >>> New-Item -ItemType Directory build >>> } >>> >>> clean >>> Set-Location build >>> configure >>> build >>> install >>> Set-Location .. >>> >>> >>> Regards >>> M >>> >>> >>> >>> Le sam. 20 avr. 2019 à 19:10, Larry Gritz <[email protected] >>> <mailto:[email protected]>> a écrit : >>> I'm not sure what else I can do unless I either have a case I can reproduce >>> on my end, or a more full stack trace or at least indication of what >>> specific line in the OIIO is where the exception is thrown (just knowing >>> precisely where the crash happens may be enough do diagnose or defensively >>> program around). >>> >>> >>>> On Apr 19, 2019, at 2:11 AM, till dechent <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> ImageInput::open() works for me with the downloaded DPX on version 2.0.6. >>>> >>>> Am Do., 18. Apr. 2019 um 18:41 Uhr schrieb Stephen Blair >>>> <[email protected] <mailto:[email protected]>>: >>>> It doesn't crash on Windows for me, but that's with OpenImageIO-Arnold >>>> 2.1.0dev >>>> >>>> On Thu, Apr 18, 2019 at 1:07 PM Larry Gritz <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> Hi, thanks. I'm able to open that DPX file on my end (not on Windows), so >>>> I don't think it's a corrupt file. >>>> >>>> Can you build all of OIIO in Debug mode (not Release) and use the debugger >>>> to find out what file and line is where the actual crash is occurring? The >>>> screenshot you provided only shows where in your unit test it was, so the >>>> actual crash could be practically anywhere inside what happens within the >>>> open() call. >>>> >>>> I'm sorry I'm not easily able to help, I don't have access to a Windows >>>> machine. >>>> >>>> Can somebody else out there who uses OIIO on Windows please do us a favor >>>> and download this DPX file in the links below, then try anything that >>>> forces an open (e.g., 'iinfo -v -stats blah.dpx') and report what happens? >>>> Does this crash for everybody? If anyone can reproduce, do you have any >>>> ideas or can you get closer to finding what line within the OIIO code is >>>> the source of the problem? >>>> >>>> -- lg >>>> >>>> >>>>> On Apr 18, 2019, at 1:16 AM, Mathieu Prevot <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Following the documentation "4.1 Image Input Made Simple"; >>>>> I'm having an exception at opening a dpx file and tiff file from simple >>>>> code: >>>>> >>>>> auto in = ImageInput::open(filename); // here >>>>> if (!in) return; >>>>> >>>>> Exception thrown at 0x00007FFDBEBDA388 in testhost.exe: Microsoft C++ >>>>> exception: Microsoft::VisualStudio::CppUnitTestFramework::CSEException >>>>> >>>>> More detailed information: >>>>> https://1drv.ms/u/s!AlUmbfQiLoTZhFQir--TvMglJ0iT >>>>> <https://1drv.ms/u/s!AlUmbfQiLoTZhFQir--TvMglJ0iT> >>>>> >>>>> Images: >>>>> https://1drv.ms/f/s!AlUmbfQiLoTZhFKpXHJcchpi0hBY >>>>> <https://1drv.ms/f/s!AlUmbfQiLoTZhFKpXHJcchpi0hBY> >>>>> >>>>> I'm using the master version of oiio in windows with tiff 4.0.10, openexr >>>>> 2.3.0, zlib 1.2.11, libpng 1.6.35, boost 1.70, libjpegturbo 2.0.3, tbb >>>>> 2019.3; cmake 3.13.4, VS2017. >>>>> >>>>> I'm running this in a c++ unit test, (with some c code since data will be >>>>> used in an interop context). >>>>> >>>>> TEST_CLASS(DPXioTests) >>>>> { >>>>> public: >>>>> TEST_METHOD(Instance) >>>>> { >>>>> auto sut = new DPXio(); >>>>> Assert::IsNotNull(sut); >>>>> } >>>>> >>>>> TEST_METHOD(ReadDPX) >>>>> { >>>>> auto sut = new DPXio(); >>>>> auto path = >>>>> "C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00001926.DPX"; >>>>> if(!FileExist(path)) >>>>> { >>>>> wstringstream s; >>>>> s << "No such file: " << path << "."; >>>>> Logger::WriteMessage(s.str().c_str()); >>>>> return; >>>>> } >>>>> try >>>>> { >>>>> auto result = sut->Read(path); >>>>> Assert::IsNotNull(result); >>>>> Assert::IsTrue(result->Colors >= 3); >>>>> Assert::IsTrue(result->Height == 2160); >>>>> Assert::IsTrue(result->Width == 4096); >>>>> } >>>>> catch (Exception& e) >>>>> { >>>>> auto lastErrorID = GetLastError(); >>>>> if (lastErrorID != 0) >>>>> { >>>>> LPVOID errorBuffer{}; >>>>> FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | >>>>> FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, >>>>> nullptr, lastErrorID, MAKELANGID(LANG_NEUTRAL, >>>>> SUBLANG_DEFAULT), (LPTSTR)&errorBuffer, 0, nullptr); >>>>> wstringstream s; >>>>> s << "Exception: " << e.what() << ". ID: "<< >>>>> lastErrorID << ". Message: " << errorBuffer<< "."; >>>>> Logger::WriteMessage(s.str().c_str()); >>>>> } >>>>> else >>>>> { >>>>> wstringstream s; >>>>> s << "Exception: " << e.what(); >>>>> Logger::WriteMessage(s.str().c_str()); >>>>> } >>>>> } >>>>> } >>>>> }; >>>>> >>>>> >>>>> Mathieu >>>>> _______________________________________________ >>>>> Oiio-dev mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>> >>>> -- >>>> Larry Gritz >>>> [email protected] <mailto:[email protected]> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>> >>> -- >>> Larry Gritz >>> [email protected] <mailto:[email protected]> >>> >>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> >> -- >> Larry Gritz >> [email protected] <mailto:[email protected]> >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
