Hi,
When using ACES, Mplay has wrong gamma or something. Same as png and exr when saved from ipr.
Can we have some consistency on all of these?
Any quick fix at least for mplay?
ty
Mplay wrong gamma with ACES
Moderator: juanjgon
Hi,
It will be hard to tell without more information. The following would be needed:
• Octane OCIO preferences setup
• OCIO settings from the Octane Camera Imager
• Knowing about Mplay buffer specification and its CM settings
Link about ACES in Octane.
Unless there is an actual sensical reason, ACES is not required.
It will be hard to tell without more information. The following would be needed:
• Octane OCIO preferences setup
• OCIO settings from the Octane Camera Imager
• Knowing about Mplay buffer specification and its CM settings
Link about ACES in Octane.
Unless there is an actual sensical reason, ACES is not required.
- I dont know about mpplay and its settings, its all default.
- I have ocio set in windows env and everything works perfect.
See attached for camera imager.
- I have ocio set in windows env and everything works perfect.
See attached for camera imager.
So it seems u need to reset mplay settings randomly, so it gives u the aces button where u disable ocio cause its double or something and then u can save.
Can we fix all these? Can we have an a/b comparison into the ipr?
Can we save from ipr with proper gamma also? Can we at least fix that the png from ipr to be saved proper while aces? thanks
Can we fix all these? Can we have an a/b comparison into the ipr?
Can we save from ipr with proper gamma also? Can we at least fix that the png from ipr to be saved proper while aces? thanks
Usually, the OCIO/ACES color spaces transformations are not backed into the float EXR image files. All the software in the pipeline should be configured with the same OCIO config to have a stable color profile from the linear EXR files. That said, I'll take a look at all these topics because probably the image sent to MPlay should also be linear to let MPlay apply the OCIO correction itself from the Houdini color settings, as expected, as perhaps the 8bit png files could be exported with all the color correction features baked as a final image. I hope to know more about these issues soon.
-juanjo
-juanjo
This is how it should work. You don't want to bake the view transform into the EXR when snapshotting to Mplay, just as I wouldn't if I were saving it to disk from the IPR window and opening it in Nuke. Mplay is colour managed and looks for the OCIO environment variable just like Octane, so let it take care of the viewing.juanjgon wrote:Usually, the OCIO/ACES color spaces transformations are not backed into the float EXR image files. All the software in the pipeline should be configured with the same OCIO config to have a stable color profile from the linear EXR files. That said, I'll take a look at all these topics because probably the image sent to MPlay should also be linear to let MPlay apply the OCIO correction itself from the Houdini color settings, as expected, as perhaps the 8bit png files could be exported with all the color correction features baked as a final image. I hope to know more about these issues soon.
-juanjo
Yep, this is the idea. I'm working on it for the next Octane 2022.1 plugin build.adrianr wrote:This is how it should work. You don't want to bake the view transform into the EXR when snapshotting to Mplay, just as I wouldn't if I were saving it to disk from the IPR window and opening it in Nuke. Mplay is colour managed and looks for the OCIO environment variable just like Octane, so let it take care of the viewing.
-Juanjo
Ok. The next plugin build will export the data to MPlay in linear mode, so you should use the MPlay OCIO/color correction settings, as expected. Anyway, there is an option in the ROP node to use the old workflow in case you want to work with MPlay configured in linear 1.0 gamma mode.
Thanks,
-Juanjo
Thanks,
-Juanjo