News. I did some cleanup of libraries, and I managed to use a full stack release (oiioTest, oiio, openEXR, etc) to open ad DPX 10 bits file.
But the cropped file still fails to be opened (debug/release). I can't see why. Weirdly, I'm using v141 toolset (VS2017) to build oiio, but I had to use v142 (VS2019 toolset) to make things work. with v141 for oiioTest, it complains that it can't find dlls, even though they are in the path. Inlining whenever possible works now fine. I'm sharing this powershell script that produce your debug and release path to your dlls (or so) automatically, starting from a certain dll (eg., OpenImageIO.dll). That's very practical. https://github.com/mprevot/powershell/blob/master/find-dependentsPath.ps1 To summarize: indeed toolset and correct set of binaries seems to be critical, and it's not about OpenImageIO code. Even though things are not completely resolved, that's a very good step forward. I have both VS2017 and VS2019 installed, and even though I'm using VS2017 toolset to build oiio and other libraries through cmake, all happen as if VS2019 toolset was used. And this is only visible with this oiioTest project so far. Any thought, script, etc is welcome. I think it would be good to have a nice ecosystem to make oiio work correctly in Windows 10 (like a good build flow, working tests etc). It might be nice also to have tests not for the sources, but also for the environment (rebug, release, toolset, etc). M Le jeu. 25 avr. 2019 à 21:56, Mathieu Prevot <[email protected]> a écrit : > I think I got a bullseye. No more memory exception at this place, only new > ones in imageioplugin. > Just remove the & at "string &arg" at the args. > > M > > Le jeu. 25 avr. 2019 à 21:41, Mathieu Prevot <[email protected]> a > écrit : > >> The iinfo.exe modification rules out the compiler parameters discepancies. >> >> I also thought that we got entry points in both debug and release, and >> mixing them should not be a problem (I never had), it could be if both >> debug and release binaries are used. >> >> I believe that going to more functional code (with string arguments >> passed by value) will do the trick. >> >> M >> >> >> Le jeu. 25 avr. 2019 à 21:29, Larry Gritz <[email protected]> a écrit : >> >>> What about filename2 char addr ?? >>> >>> I'm trying to figure out if the caller and callee, both pointing to the >>> *same* string, might have a different notion of the pointer within that >>> string that says where the characters live. >>> >>> What it smells like is that the caller and callee (your program, versus >>> OIIO dll, compiled separately) disagree on the meaning of the internals of >>> a std::string. (If this is the case, passing the std::string by value >>> instead of by reference is also not likely to help things.) >>> >>> This makes me continue to suspect that it's a difference in compilers or >>> compiler settings that is the culprit here. >>> >>> As an example in Linux/gcc land, there was a point where the internals >>> of std::string changed, as an incompatible ABI change, and there, too, you >>> can get into trouble if, for example, one module is compiled with gcc 4.8 >>> and the other is compiled with gcc 6.3 (with the new ABI), in very much the >>> same way as what appears to be going on here. >>> >>> -- lg >>> >>> >>> On Apr 25, 2019, at 12:14 PM, Mathieu Prevot <[email protected]> >>> wrote: >>> >>> filename2 addr = 00000072A38FFBB0 >>> filename2 len = 79 >>> filename2 = >>> 'C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00002043.DPX' >>> str addr = 00000072A38FFBB0 >>> str len 79 >>> str char addr = FFFFFFFFFFFFFFFE >>> >>> throws at >>> std::cout << "str first char = " << int(str[0]) << std::endl; >>> >>> Exception thrown: read access violation. >>> std::basic_string<char,std::char_traits<char>,std::allocator<char> >>> >::operator[](...) returned 0xFFFFFFFFFFFFFFFE. >>> >>> >>> M >>> >>> >>> Le jeu. 25 avr. 2019 à 20:57, Larry Gritz <[email protected]> a écrit : >>> >>>> Right, when it accesses the characters in the callee, it fails for some >>>> reason. >>>> >>>> So the additional line I wanted to add prints the address of the >>>> characters, before trying to access them. I want to know if the caller and >>>> callee disagree on *where* those characters are in memory, or are they both >>>> looking at the same memory but for some other reason the callee can't touch >>>> them? >>>> >>>> Oh, one more! >>>> >>>> std::cout << "str addr = " << (void*)&str << std::endl; >>>> std::cout << "str len " << str.size() << std::endl; >>>> std::cout << "str char addr = " << (void*)str.c_str() << std::endl; >>>> std::cout << "str first char = " << int(str[0]) << std::endl; >>>> std::cout << "str chars = '" << str << "'" << std::endl; >>>> >>>> Can it access the first character, or is it "running off the end of the >>>> string", so to speak, when it fails. >>>> >>>> >>>> >>>> On Apr 25, 2019, at 11:52 AM, Mathieu Prevot <[email protected]> >>>> wrote: >>>> >>>> In the callee, whatever I try to do it throws. >>>> Hence I know I'll get something from my code, and nothing from oiio >>>> function. >>>> I tried to ask a local copy of str, it just throws at `string localstr >>>> = str;` >>>> >>>> I think it should be wiser to pass string by value and not by reference. >>>> >>>> Any thought, objection ? >>>> M >>>> >>>> Le jeu. 25 avr. 2019 à 20:43, Larry Gritz <[email protected]> a écrit : >>>> >>>>> Hmmm. OK, one more test: >>>>> >>>>> In both of the places (caller and callee), can you add one more line >>>>> in this spot: >>>>> >>>>> std::cout << "str addr = " << (void*)&str << std::endl; >>>>> std::cout << "str len " << str.size() << std::endl; >>>>> std::cout << "str char addr = " << (void*)str.c_str() << std::endl; >>>>> std::cout << "str chars = '" << str << "'" << std::endl; >>>>> >>>>> ??? >>>>> >>>>> >>>>> >>>>> On Apr 25, 2019, at 10:36 AM, Mathieu Prevot <[email protected]> >>>>> wrote: >>>>> >>>>> The output with the modified sources as you requested: >>>>> >>>>> filename2 addr = 000000C9E28FF930 >>>>> filename2 len = 79 >>>>> filename2 = >>>>> 'C:/sensomovie/C200/A011C118_19041345_CANON/A011C118_19041345_CANON_00002043.DPX' >>>>> str addr = 000000C9E28FF930 >>>>> str len 79 >>>>> str chars = ' >>>>> >>>>> Access violation reading location 0xFFFFFFFFFFFFFFFE >>>>> >>>>> It seems it complains about being/not able to read the string, even >>>>> though the address and length are correct. >>>>> >>>>> M >>>>> >>>>> >>>>> Le jeu. 25 avr. 2019 à 18:51, Larry Gritz <[email protected]> a >>>>> écrit : >>>>> >>>>>> So that minimal example also fails? >>>>>> >>>>>> Did you add those extra printf lines on the OIIO side that I >>>>>> suggested a couple messages ago? What did they print? >>>>>> >>>>>> OK, next experiment: >>>>>> >>>>>> Copy those lines inside main() from my minimal example below, and >>>>>> paste them into OIIO src/info/iinfo.cpp, right in its main() before it >>>>>> does >>>>>> anything else. The point of this test is to see what happens when we are >>>>>> absolutely sure that the program calling this sequence is built with all >>>>>> the same compile flags and headers as the OSL library itself. Then build >>>>>> OIIO in whatever configuration was producing failures reliably before, >>>>>> and >>>>>> try by running "iinfo" (it's not the "real" iinfo now, it's just a >>>>>> harness >>>>>> for running that minimal example). What happens, and what does it print >>>>>> with those debugging statements? >>>>>> >>>>>> >>>>>> >>>>>> On Apr 25, 2019, at 6:44 AM, Mathieu Prevot <[email protected]> >>>>>> wrote: >>>>>> >>>>>> In the oiioTest project, there is no test framework, no specific c++ >>>>>> standard is specified (an noe was specified at oiio build). >>>>>> I'm using v141 toolset in both (the default VS2017 toolset). >>>>>> The truly minimal program fails too. >>>>>> Can you use the source and script I provided to reproduce the memory >>>>>> error ? >>>>>> >>>>>> M >>>>>> >>>>>> >>>>>> Le mer. 24 avr. 2019 à 23:59, Larry Gritz <[email protected]> a >>>>>> écrit : >>>>>> >>>>>>> That's interesting. Definitely makes me think it's some kind of >>>>>>> mismatch between your module and OIIO, since the all-OIIO code (using >>>>>>> oiiotool, which calls the same libOpenImageIO APIs underneath) seems >>>>>>> fine. >>>>>>> >>>>>>> Are you sure that OIIO and your code was definitely built with the >>>>>>> same compiler version? Same flags indicating the C++ standard to use or >>>>>>> any >>>>>>> other such things that may be relevant for MSVS? >>>>>>> >>>>>>> What I would recommend next is trying to find the *minimal* >>>>>>> separately-compiled program that exhibits the problem. Eliminate your >>>>>>> testing framework and all other cruft. Would the following truly minimal >>>>>>> program also fail? >>>>>>> >>>>>>> #include <OpenImageIO/imageio.h> >>>>>>> int main (int argc, char *argv[]); >>>>>>> { >>>>>>> const char* filename = >>>>>>> "C:\sensomovie\C200\A011C118_19041345_CANON\A011C118_19041345_CANON_00000001.DPX" >>>>>>> auto in = ImageInput::open(filename); >>>>>>> if (in) { >>>>>>> printf ("Opened successfully\n"); >>>>>>> printf ("Opened successfully, format is %s\n", >>>>>>> in->format_name()); >>>>>>> } else { >>>>>>> printf ("Fail\n"); >>>>>>> return 1; >>>>>>> } >>>>>>> return 0; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> On Apr 24, 2019, at 2:27 PM, Mathieu Prevot < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> No, it only crashes when I use the API in release, I use the API in >>>>>>> debug it works too. The output: >>>>>>> >>>>>>> .\oiiotool.exe -info -v >>>>>>> C:\sensomovie\C200\A011C118_19041345_CANON\A011C118_19041345_CANON_00000001. >>>>>>> DPX >>>>>>> Reading >>>>>>> C:\sensomovie\C200\A011C118_19041345_CANON\A011C118_19041345_CANON_00000001.DPX >>>>>>> C:\sensomovie\C200\A011C118_19041345_CANON\A011C118_19041345_CANON_00000001.DPX >>>>>>> : 4096 x 2160, 3 channel, uint10 dpx >>>>>>> channel list: R, G, B >>>>>>> DateTime: "2019:04:13 16:14:30" >>>>>>> Orientation: 1 (normal) >>>>>>> PixelAspectRatio: 1 >>>>>>> Software: "CANON" >>>>>>> dpx:Colorimetric: "Unspecified video" >>>>>>> dpx:DittoKey: 1 >>>>>>> dpx:EndOfImagePadding: 0 >>>>>>> dpx:EndOfLinePadding: 0 >>>>>>> dpx:FramePosition: 1 >>>>>>> dpx:FrameRate: 59.9401 >>>>>>> dpx:HeldCount: 1 >>>>>>> dpx:ImageDescriptor: "RGB" >>>>>>> dpx:InputDeviceSerialNumber: "373449900026" >>>>>>> dpx:Interlace: 0 >>>>>>> dpx:Packing: "Filled, method A" >>>>>>> dpx:SequenceLength: 2931 >>>>>>> dpx:ShutterAngle: 0 >>>>>>> dpx:SourceDateTime: "2019:04:13 16:14:30" >>>>>>> dpx:SourceImageFileName: "A011C118_19041345_CANON.CRM" >>>>>>> dpx:TemporalFrameRate: 59.9401 >>>>>>> dpx:TimeCode: "00:42:11;23" >>>>>>> dpx:Transfer: "Unspecified video" >>>>>>> dpx:UserBits: 0 >>>>>>> dpx:UserData: 67, 65, 78, 79, 78, 95, 82, 65, 87, 95, 68, 69, >>>>>>> 86, 69, 76, 79, ... [63488 x uint8] >>>>>>> dpx:Version: "V2.0" >>>>>>> oiio:BitsPerSample: 10 >>>>>>> smpte:TimeCode: 00:42:11:23 >>>>>>> >>>>>>> Mathieu >>>>>>> >>>>>>> Le mer. 24 avr. 2019 à 23:24, Larry Gritz <[email protected]> a >>>>>>> écrit : >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> 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]> >>>>>>>> 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 >>>>>>>>> >>>>>>>>> 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]>: >>>>>>>>> >>>>>>>>>> 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]> 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 >>>>>>>>>> >>>>>>>>>> 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]> 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]> 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]> 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]>: >>>>>>>>>>>> >>>>>>>>>>>>> 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]> 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]> >>>>>>>>>>>>>> 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]> 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]>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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]> 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]> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Images: >>>>>>>>>>>>>>>>> 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] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Oiio-dev mailing list >>>>>>>>> [email protected] >>>>>>>>> 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 >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >>>> >>> _______________________________________________ >>> 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 >>> >>
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
