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