[BUG] UTF-8 filename support for writing EXR images

[fabiencastan]

Describe the bug I can read images from paths with non-ascii caracters but not write. Tested only on Windows.

To Reproduce Write an EXR image into a non-ascii path. I have not tested writting using another file format.

Evidence

Microsoft C++ exception: Iex_2_5::IoExc at memory location

with message: "File output failed."

The error happens at this line: https://github.com/OpenImageIO/oiio/blob/1003d1a287e066b9c7f6d2c42a5c477485a8b97a/src/openexr.imageio/exroutput.cpp#L357

m_output_stream.reset(new OpenEXROutputStream(name.c_str(), m_io));

The exception is launched from OpenEXR:

>	OpenImageIO.dll!OpenImageIO_v2_1::OpenEXROutput::open(const std::string & name, const OpenImageIO_v2_1::ImageSpec & userspec, OpenImageIO_v2_1::ImageOutput::OpenMode mode) Line 353	C++

Platform information:

• OIIO branch/version: 2.1.16.0 (and OpenEXR-2.5.0)
• OS: Windows
• C++ compiler: MSVC 2019
• Any non-default build flags when you build OIIO: No

[lgritz]

I think that this should work properly... The OpenEXR reads and writes are all mediated by IOProxy, which is careful on Windows to handle UTF-8 filenames. So I'm not sure exactly what could go wrong. I do notice that you're using OIIO 2.1, and while I can't find any changes since then that ought to be relevant, it would be interesting to try with master or 2.2 to see if this is something that has already been fixed.

I just added this PR: https://github.com/OpenImageIO/oiio/pull/2780

It doesn't "fix" the problem of UTF-8 files -- because I can't find anything that ought to be broken with it -- but it does beef up the error reporting for files that can't be opened.

If you are able, can you apply this patch to master or 2.2 on your end and test it out? It may fix (probably if coincidentally other fixes have addressed the problem since the version of 2.1 you were using), or if still broken, perhaps the enhanced error reporting will give us a clue about what to try next.

[lgritz]

@fabiencastan Let me know if #2780 gets you any closer to identifying the specific problem you're having.

[zavinator]

This can be confusing, because using c_str can work good for extended ascii filenames with some other libraries (FreeImage for example). Maybe there should be a warning in docs (if it's not already there)...

An example (using Qt for strings):

This works OK:

QString filename; // <- extended ascii filename
OIIO::ImageBuf buf1(filename.toStdString());
OIIO::ImageBuf buf2(filename.toUtf8().data());

This works not:

OIIO::ImageBuf buf1(filename.toStdString().c_str());
OIIO::ImageBuf buf2(filename.toLocal8Bit().data());

[lgritz]

Does anybody know if this is still an issue or if it has been improved?