Is it possible to convince LUT to use values outside range? You have to remember that we have different approach. We do not have real time render. So without LUT user receives HDR image, that can be fixed. With LUT we get exr image but limited to 1 so it can not be fixed. We apply LUT conversion on server side in luxcore pipeline. So from our point of view it is useless.
So the only solution I can find is to apply LUT conversion at client side as the last operation. But this means that we can not use LuxCore pipeline to do this but we have to implement it on our own.
Color LUT and floating point
Re: Color LUT and floating point
Just open the LUT file (it is a text file), you will see it includes values only between 0.0 and 1.0. And can not be otherwise because you can not define a LUT for a [0.0, +INF] interval, it would require and infinite amount of values.bartek_zgo wrote: ↑Tue Aug 10, 2021 9:16 am Is it possible to convince LUT to use values outside range?
If you want to be able to adjust exposure, LUT or tone mapping in general, you need to run the full image pipeline on the client. You need to transfer only the raw rendering product and than (interactively) run the image pipeline on the client.
If the problem is the no portable format of the film file, I can add a method to create a LuxCore Film out of an EXR so you can save the raw rendering in EXR on the server, transfer the rendering EXR to the client and than crate a Film on the client and run any kind of image pipeline with any kind of parameter there.
-
- Posts: 116
- Joined: Mon Oct 26, 2020 11:42 am
Re: Color LUT and floating point
Thanks Dade. I have read LUT specification and now I understand why it is working in this way. So we have to forget about using LUT files on server side.
I have to decide if not implement highlight compression on my own, or find some piece of code.
I have to decide if not implement highlight compression on my own, or find some piece of code.
Re: Color LUT and floating point
Hi, is there a specific reason why OCIO output loses dynamic range?
In medium to large scale productions the person working on Blender does not have the final say on color correction. The person working on Blender may approximate to the best of their ability (and this is important) but the final word is not theirs. There are those who do the editing, those who do the post-production, the colorist himself, the director and so on.... Each one of them thinks they're the most important link in the chain and each one of them wants maximum flexibility from the sequences.
After OCIO instead, the whole production has to abide by the rendering guy's decision because the image sequence has lost its original dynamic range.
I'm not sure that makes sense.
In medium to large scale productions the person working on Blender does not have the final say on color correction. The person working on Blender may approximate to the best of their ability (and this is important) but the final word is not theirs. There are those who do the editing, those who do the post-production, the colorist himself, the director and so on.... Each one of them thinks they're the most important link in the chain and each one of them wants maximum flexibility from the sequences.
After OCIO instead, the whole production has to abide by the rendering guy's decision because the image sequence has lost its original dynamic range.
I'm not sure that makes sense.
Re: Color LUT and floating point
It is not an OCIO limit, it is what LUTs are (with OCIO or without): they are defined in [0.0, 1.0] range.
Re: Color LUT and floating point
OK, how can we have hilight compression without Lut approach? Do you think there is a way using OCIO? We are writing something but it's a long way to get it working properly. Thanks again.
Re: Color LUT and floating point
Yes, I have some idea but it is an arbitrary/heuristic solution, I mean, it is an artistic approach so, or you have already an proven algorithm/solution, or the end result may be a bit unknow.