OTOY Forums

gordonrobb wrote: It's a bigger problem than that though, if you're trying to match any Standalone Matierials, the inputs for spec etc don't match either. I can always change the inputs to float.
.

But you only have this problem if you work with integer/hexadecimal RGB values. Why don't you work with the floating RGB values? ... then all should match if both Standalone and LW color pickers are set to linear.

Now you can even export a Standalone material to your LocalDB and import it in the LW plugin using the LiveDB material node

-Juanjo

gordonrobb wrote: What I don't understand though is whey Standalone is correcting the input, but Plugin doesn't

For Octane 3 I can think about an option to color correct the RGB texture node color values ... the problem is not the plugin, the problem is that the LW color pickers don't correct the colors entered as sRGB hex values, but the Standalone color picker has this correction in the hex input.

-Juanjo

I have this problem if I use an RGB colour. If I want to find the colour for (in this instance) Caterpillar Yellow, I can 'only' find the RBG, or Hex colour. That's the problem. And if i'm must picking a colour in the colour picker based on what looks good, that is not how it renders (unlike in Standalone, where what you see is what you get). Do you see what I mean? And the difference is greater the darker you go. To get a dark brown, I almost have to go totally black. And tiny differences make massive differences in the render.

gordonrobb wrote:I have this problem if I use an RGB colour. If I want to find the colour for (in this instance) Caterpillar Yellow, I can 'only' find the RBG, or Hex colour. That's the problem. And if i'm must picking a colour in the colour picker based on what looks good, that is not how it renders (unlike in Standalone, where what you see is what you get). Do you see what I mean? And the difference is greater the darker you go. To get a dark brown, I almost have to go totally black. And tiny differences make massive differences in the render.

The problem is always the same: the LW color picker is working in linear space, and the picked/shown color are not color corrected for a 2.2/sRGB gama output rendering.

The only way I know to enable the color correction in the LW pickers without affect the Octane rendered images is to set the output Display Color Space to sRGB, and enable the Affect Color Picker option, like you can see in the attached image, leaving all the other settings disabled and linear.

The problem: all is going to work fine with this configuration, but when you render with F9, LightWave is going to enable a sRGB color correction over the already color corrected and tonemaped Octane rendered image. This overcorrection doesn't affect the IPR, the rendering preview window, or the buffers exported from the Octane passes node or saved from LW. It only affects the LW render display window, but you can set it to Linear again in the top menu bar, as you can see in the attached image.

Try to work with this configuration and let me know if you get side effects in the Octane rendered images.

-Juanjo

I will fill a feature request for the next LW version to have a new option in the color space functions to set only the color correction for the color pickers, while all the other settings can be left as linear ... something like this:

Sorry to be a pain. It seems like it's only me that is bothered by this.

In your solution, would setting Display Colour Space to sRGB not then change the output of image maps as well (which have already been set to gamma 2.2 normally)

I will see what I can figure out using a combination of the colourcorrect node to set the rgb gamma, and the float input for spec type inputs. Thanks for your help, sorry to be a pain

Sorry to be a pain. It seems like it's only me that is bothered by this.

Don't worry. We read and learn but stay quiet as you two do a good job But of course this subject is very interesting. Keep on

Grand Merci
Pour la version 2.24 ^^

Was this intentional that the Mac version is still the old one? Or did you just forget to rename it?

Humpti wrote:Was this intentional that the Mac version is still the old one? Or did you just forget to rename it?

I think that the mac version doesn't have this problem. Anyway I will update it as soon as I return from vacation if any user has this issue on OSX.

-Juanjo