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
