Windows Build Errors

[DashW]

The MSVC Windows build of LumaHDRv currently suffers from several issues

1. "Cannot open include file: 'sys/time.h' in luma_decoder.h" - It seems that this header is not referenced in the code and is not necessary. Since there is no equivalent header on Windows, this include should be removed.

2. CMake does not generate a Win64 Visual Studio solution for LumaHDRv, so if libvpx is configured for the Win64 toolchain, the libvpx library will not link. Either CMake should provide the option to generate a Win64 solution, or the Win32 limitation should be documented.

3. Projects lumaenc, lumadec, test_simple_enc, and test_simple_dec fail to link, with the error "cannot open input file 'Release\luma_decoder.lib' and 'Release\luma_encoder.lib'". The luma_encoder and luma_decoder projects are configured to build dynamic library DLL files, not static library lib files.

[gabrieleilertsen]

Luma HDRv is mainly targeted for Unix systems. However, it should be fully possible to compile under Windows too, since all dependencies can be resolved. However, I'm afraid that Windows installation may require some additional tweaking to install properly. When I wrote the instructions for Windows in the readme, I was able to compile the libraries accordingly, but it may be different on another system. I currently don't have access to a Windows machine, so it is a bit difficult for me to look into Windows related issues.

I hope that you were able to resolve the issues.

[DashW]

Fixes for the above issues:

1. Removed the offending include statement.
2. Recompiled all dependencies for 32-bit.
3. Added __declspec(dllimport) defines for luma_encoder and luma_decoder (MSVC doesn't produce lib files without this syntax)

However, I'm now blocked because I believe I'm trying to compile against an incompatible version of OpenEXR, so waiting on an answer to issue #1 .

[DashW]

So this was finally fixed with some tweaks to OpenEXR.

To resolve the linker issues, I first renamed all versioned namespaces like Imf_2_2 to their parent namespaces like Imf, and then, since I was using dynamic linkage, I had to make sure that OpenEXR was using __declspec(dllexport) by enabling flags like OPENEXR_DLL.

Luma now compiles and links successfully on Windows. I may submit a PR in the next couple of days with the removed include statement and the new __declspec defines mentioned in the above comment. I'll only submit full Windows build instructions once I've repeated the build process from scratch one more time.

[DashW]

So I've just successfully completed my first HDR render. Our use case is 360 VR, so we have a sample scene of approx 2200 frames at 4096x4096@30fps, Initally, the 32-bit exe was consistently running out of memory with this frame size (throwing std::bad_alloc), however this was fixed by recompiling the exe with the /LARGEADDRESSAWARE flag, increasing the memory address space from 2 to 4 GB. I may submit a push request with this flag added to the CMake list, or I may just look straight into recompiling for 64-bit.

For this 74-second clip, render time took around 18 hours. This was a Debug-compiled exe with Debug-compiled OpenEXR, however the bottleneck seemed to be the libVPX library which was Release-compiled, so I'm not sure if it's going to be possible to significantly improve render time.

The only other note I can add is that I was getting frequent low-luminance warnings. Our frames are rendered from a CGI renderer with full floating-point accuracy, but colors are in the LDR range 0.0-1.0. I'm currently using the recommended YouTube configuration settings with a pre-scaling value of 20... @gabrieleilertsen would you recommend a larger pre-scaling value to avoid these luminance warnings?

[gabrieleilertsen]

Hi! Yes, VPX is slow. With the latest version, that I included in the repository, I think it is supposed to be faster than using earlier versions. However, it still takes long time, especially if you're encoding at that resolution. In the future, I may look into other alternatives, especially since open source implementations of HEVC are starting to become available.

About the luminance warning, it indicates that you need a much larger scaling. You will probably be able to see quantization artifacts if you get that warning. Pixels should be scaled to approximately correspond to scene luminance. You can for example look at some reference pixels to estimate what scaling is needed, comparing to some knowledge on what is expected. For example, you can compare to this list of luminance values. In its default settings, the codec encodes luminances between 0.005-10000 cd/m². This means that, if your maximum pixel value is 1, you can scale by 10000 without loosing information. Possibly, you should use a larger scaling if your sequences have a very high dynamic range, which means that the very brightest pixels are clipped.

I also saw the pull request. Thanks for contributing. I will look into the changes when I have time. The problem is that I don't have a Windows machine to do test compilation...