Perhaps this will help explain the issue? https://stackoverflow.com/a/22279218
On Thu, Apr 25, 2019 at 1:57 PM Mathieu Prevot <[email protected]> wrote: > 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 >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
