Additional colour spaces for LuxRenderGUI (ACES + Rec2020)

Discussion related to the development & design of the LuxRender Graphical User Interface
coordinator: none (position is open)

Moderators: Dade, coordinators

Additional colour spaces for LuxRenderGUI (ACES + Rec2020)

Postby irieger » Thu Jan 12, 2017 5:13 pm

Hello,

I'm following the LuxRender project for several years now but as I never found time to dive into 3D work I wasn't using it. But as I recently started learning Blender with the main interest on Shading/Rendering/Compositing (my background is mostly (movie) colour science and computer science). As I'm already very familiar with ACES for colour grading I wanted to have an ACES option in Lux instead of manually entering the primaries.

Attached is a patch that adds ACEScg (AP1) and Rec 2020 primaries and the ACES whitepoint.

When adding the colour spaces and test them in the GUI I saw that not using the high precision option in the GUI will round the white point. Can this be prevented? Same problem after loading an flm file earlier with ACEScg set manually with high precision option on, after loading the option was off and the white point was rounded.


While adding the colour spaces I realized that it is quite hard to compile Lux (on Ubuntu). For example I needed to screw around in FindTBB.cmake in embree (dade BVH-branch, saw it fixed somewhere in the official embree I think, is some Ubuntu bug) and cmake/FindEmbree.cmake in lux/luxrays to give it a path via $ENV{EMBREE_ROOT} (I think using ENV is the common way in many FindPACKAGE.cmake files).

Also tried the repo with the linux static building tools but this failed at several steps with OpenEXR, OpenImageIO and Qt (commented some stuff out to see how far I can get). In the end the manual compilation finished. Was able to load an flm and test my change, but loading a scene sample scene working fine in v1.6 resulted in a crash. What is the linux distribution used as a reference to easily compile? Is there a general guide how to dive into building Lux? I plan to have a closer look at the tonemapping/color pipeline on the export side of Lux and would like to get a stable build environment.

PS: Is there still work done on the classic GUI? I'm going to look into LuxCoreUI / luxrays repo soon anyways, just curious what the state is.
Attachments
lux-aces.patch
Patch to add ACES and Rec 2020 colour spaces and ACES whitepoint
(5.32 KiB) Downloaded 25 times
Regards,
Ingmar
irieger
 
Posts: 2
Joined: Wed Jan 11, 2017 5:38 pm

Re: Additional colour spaces for LuxRenderGUI (ACES + Rec202

Postby Dade » Fri Jan 13, 2017 6:56 am

irieger wrote:PS: Is there still work done on the classic GUI? I'm going to look into LuxCoreUI / luxrays repo soon anyways, just curious what the state is.


An effort of porting the classic GUI to LuxCore has been started here: https://bitbucket.org/luxrender/luxrays ... at=default

However no one is working on this task at the moment.
User avatar
Dade
Developer
 
Posts: 8363
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

Re: Additional colour spaces for LuxRenderGUI (ACES + Rec202

Postby Meelis » Sun Apr 02, 2017 2:37 am

Hi

Not 100% sure, but looks like when i entered in lxs file

whitepoint 0.32168 0.33767
x 0.713 0.165 0.128
y 0.293 0.830 0.044

The classic LuxRender BIDIRVMCPU crashed when saving 16bit png
The exr was saved but png size was 0 bit.

https://youtu.be/m9AT7H4GGrA?t=9m30s
User avatar
Meelis
 
Posts: 1007
Joined: Sat Oct 17, 2009 2:16 am

Re: Additional colour spaces for LuxRenderGUI (ACES + Rec202

Postby irieger » Sun Apr 02, 2017 3:22 am

Meelis wrote:Not 100% sure, but looks like when i entered in lxs file

whitepoint 0.32168 0.33767
x 0.713 0.165 0.128
y 0.293 0.830 0.044

The classic LuxRender BIDIRVMCPU crashed when saving 16bit png
The exr was saved but png size was 0 bit.

Sadly I can't really help you there. Haven't really had the chance to look deeper into the LuxRender inner workings regarding color management. Just added this two options to have some more output options to play with but as it is only the old API stuff I think there isn't that much work done here anyway.


What does this have to do with this topic? Blender does nothing wrong there. It just has the same default as many other software. Even before filmic it was easy to switch for example to RRT which does something similar. sRGB standard transform just doesn't do any tonemapping, so any highlights will clip. Lux offers different tonemappers and by default already does some tonemapping, so nothing wrong there either.
Regards,
Ingmar
irieger
 
Posts: 2
Joined: Wed Jan 11, 2017 5:38 pm

Re: Additional colour spaces for LuxRenderGUI (ACES + Rec202

Postby Meelis » Sun Apr 02, 2017 4:17 am

Yes Lux can save 32bit exr file and do reinhard tonemapping.
Maybe the linear tonemapper has something to gain. Reinhard sometimes lacks contrast.

Is the clamp method preserve hue similar to what magic ACES has for manipulating emitter brightness and layer gain?
The render has different look if i set the colorspace white in lxs file or if i set it after from Lux UI.
For an example setting colorspace white in lxs to 0.41 0.356 gives from blue sky blue reflection for shiny surfaces, doing it from Lux UI not so much (or the blue covers all the surfaces even where sun dominates). I think the used color space has big impact for the render look.
User avatar
Meelis
 
Posts: 1007
Joined: Sat Oct 17, 2009 2:16 am


Return to LuxGUI

Who is online

Users browsing this forum: No registered users and 1 guest