Till, Larry, list, did you manage to build a project (just opening a DPX image) ina debug mode, using release OpenImageIO ?
M Le ven. 26 avr. 2019 à 17:18, Mathieu Prevot <[email protected]> a écrit : > 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
