Yes, the latest night build. I added the whole ffmpeg binaries in the shared folder,
or you can get just ffmpeg.zip here: https://1drv.ms/u/s!AlUmbfQiLoTZhFkvGOhIjESNuCQH Le jeu. 25 avr. 2019 à 17:17, till dechent <till.dech...@gmail.com> a écrit : > I tried running your project but I am missing avcodec-58.dll. > > That is probably coming from FFMpeg? > > Am Do., 25. Apr. 2019 um 14:44 Uhr schrieb Mathieu Prevot < > mathieu.pre...@gmail.com>: > >> 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 <l...@larrygritz.com> 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 <mathieu.pre...@gmail.com> >>> 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 <l...@larrygritz.com> 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 <mathieu.pre...@gmail.com> >>>> 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 <till.dech...@gmail.com> 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 < >>>>> l...@larrygritz.com>: >>>>> >>>>>> 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 <mathieu.pre...@gmail.com> >>>>>> 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 <l...@larrygritz.com> 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 < >>>>>>> mathieu.pre...@gmail.com> 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 <till.dech...@gmail.com> >>>>>>> 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 < >>>>>>>> mathieu.pre...@gmail.com>: >>>>>>>> >>>>>>>>> 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 < >>>>>>>>> mathieu.pre...@gmail.com> 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 <l...@larrygritz.com> 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 < >>>>>>>>>>> till.dech...@gmail.com> 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 < >>>>>>>>>>> step...@solidangle.com>: >>>>>>>>>>> >>>>>>>>>>>> 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 <l...@larrygritz.com> >>>>>>>>>>>> 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 < >>>>>>>>>>>>> mathieu.pre...@gmail.com> 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 >>>>>>>>>>>>> Oiio-dev@lists.openimageio.org >>>>>>>>>>>>> >>>>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Larry Gritz >>>>>>>>>>>>> l...@larrygritz.com >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>>>> Oiio-dev@lists.openimageio.org >>>>>>>>>>>>> >>>>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>>> Oiio-dev@lists.openimageio.org >>>>>>>>>>>> >>>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>> Oiio-dev@lists.openimageio.org >>>>>>>>>>> >>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Larry Gritz >>>>>>>>>>> l...@larrygritz.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Oiio-dev mailing list >>>>>>>>>>> Oiio-dev@lists.openimageio.org >>>>>>>>>>> >>>>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>> Oiio-dev mailing list >>>>>>>>> Oiio-dev@lists.openimageio.org >>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Oiio-dev mailing list >>>>>>>> Oiio-dev@lists.openimageio.org >>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Oiio-dev mailing list >>>>>>> Oiio-dev@lists.openimageio.org >>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Larry Gritz >>>>>>> l...@larrygritz.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Oiio-dev mailing list >>>>>>> Oiio-dev@lists.openimageio.org >>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>>> >>>>>> _______________________________________________ >>>>>> Oiio-dev mailing list >>>>>> Oiio-dev@lists.openimageio.org >>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>> >>>>>> >>>>>> -- >>>>>> Larry Gritz >>>>>> l...@larrygritz.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Oiio-dev mailing list >>>>>> Oiio-dev@lists.openimageio.org >>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>>> >>>>> _______________________________________________ >>>>> Oiio-dev mailing list >>>>> Oiio-dev@lists.openimageio.org >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>>> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> Oiio-dev@lists.openimageio.org >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>>> >>>> -- >>>> Larry Gritz >>>> l...@larrygritz.com >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> Oiio-dev@lists.openimageio.org >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> Oiio-dev@lists.openimageio.org >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >>> >>> -- >>> Larry Gritz >>> l...@larrygritz.com >>> >>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> Oiio-dev@lists.openimageio.org >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
