[RFE] OpenEXR for image-based lighting

[Kai]

Hi,

in order to render a photo-realistic scene located in an actual "room" for data visualization I want to do image-based lighting (a simple light source won't do for the targeted image fidelity).
I already took a sequence of photographs with varying exposures/stops/EVs with a camera and created a high dynamic range image in the OpenEXR format from it.
The image will be uploaded to OpenGL and sampled using a path tracer implemented via OpenGL Compute Shaders with lwjgl3.

Now, the only problem I got is how to read the OpenEXR file in the Java application. There is the OpenEXR framework itself on GitHub https://github.com/openexr/openexr which seems to be doing just what I need, but it is a native framework written in C++.

I searched the web for solutions in Java, but the only one I found was the seemingly incomplete https://code.google.com/p/openexr4j/.

Maybe you know of an alternative solution or else I would hereby request to have OpenEXR integrated with lwjgl as a separate module (like with OpenAL).
The sad story about that is however, that OpenEXR does not seem to expose a C-API, only a C++-API. 

[Cornix]

Isnt that an image format?
If so, all you need to do is extract the pixel information and upload it to an openGL texture.

I dont know how the format is build, but since it is an open format you should be able to read up on it somewhere on the internet. With this information you should be able to implement a decoder yourself.

[Kai]

Yes, it is both the name of a library and of an image format.
And it is rather a complicated endeavour to decode it, keeping in mind that it also features lossless data compression to reduce the image size on disk before decoding them.
So, to not reinvent the wheel, my suggestion is to have it included into lwjgl. 

[Cornix]

Writing a port for a different programming language is not reinventing the wheel.
Using all kinds of C and C++ libraries in java is, on the other hand, quite a bad idea since it goes against the very idea of the language.

[spasi]

The problem with ports is you're stuck at the feature level at the time of porting and you inherit all bugs and other issues from the original codebase. It's a non-stop race to keep it synchronized after that. In Java's case, you're also very likely to suffer in terms of performance, especially for these kinds of libraries that handle a lot of raw data and may have SIMD-powered implementations.

A binding on the other hand has a lot less surface to cover, just the public API. You do pay the JNI overhead, but it's negligible for well-design APIs and native FFI support in Java 9 or 10 will completely remove it.

I did an OpenEXR build as a test, the API is extensive and pure C++. Even if you only need the IO parts, there are several classes that require bindings. OpenEXR is a popular format, used by many game engines (e.g. both CryEngine and UE support it afaik) and other applications. It may only be interesting to very few LWJGL users, but still it will be useful to support bindings to C++ libraries in general. For example, Bullet is also a C++ only API.

Anyway, it's not a priority right now, but I'll try to add C++ support to the bindings generator, after Objective C.