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]
> <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]
> 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
