To try a bit further I tried to render a random image but with sRGB Primaries under the colormanagement tab and the metadata looks more like in Nuke and no matter on wich support I preview the file the result is consistent.
To try a bit further I tried to render a random image but with sRGB Primaries under the colormanagement tab and the metadata looks more like in Nuke and no matter on wich support I preview the file the result is consistent.
Your workflow should be correct. Most likely the applications you’re previewing with are applying another sRGB curve. I’m getting identical .png vs VFB results when saving the .png with baked view transform and gamma 1. For a preview, I used Chaos Player (PS works fine too) and set the Color Space to sRGB (so that it does not apply a curve). Also, I don’t think looking up the metadata for .pngs is of any use - not sure if .pngs can even store such data.
Yes if I preview in ChaosPlayer I don’t have any issue but its pretty much the only software where I get a proper result.
For a little bit of context, our Artist need to upload their review image on our web server. If I upload the .png from nuke I don’t have colors issue, if I upload the .png from the VFB colors don’t match vfb.
To try It on your own you can drag any png file from VFB in a google Tab.
I have a few questions to try and unravel this:
What’s the Max and V-Ray versions you’re working with?
What did you check the metadata with?
The screenshots don’t look like nuke, we’d like to use the same tools as you did for the sake of consistency of results.
There are things that don’t quite look right to me: f.e. you can’t expect an ACES-primaries saved image (you seem to do so in the VFB) to display properly outside of ACES-compatible applications (i.e. the VFb or Nuke will display it right, surely not a web page or windows paint, as they aren’t OCIO managed.).
Alas, without more info i can’t be sure of anything.
If you have a prepared max scene that renders something the way you expect it, please send it over (along with the OCIO config you are using for it.).
- We are currently working with Max2023 and V-Ray 6.00.08
- We checked the metadata using ImageMagick in linux with this command " identify -verbose/.yourimage.png
The screenshots are the result of this command.
We don’t expect a pixel perfect result saving png files with ACES collapsed and upload it in web application but we should have a much closer look of what we have in the VFB (if we upload the png file from nuke on web browser we have a much more convincing result compared with the png saved from VFB).
I’ve worked with the workflow as mentionned above.
I’ll attach a basic scene with a Macbeth chart
2 png files :
1 VrayMacBeth.png - is saved from VFB with Save in image checked.
2 NukeMacBeth.png - this one is created with an EXR file saved from the VFB and ACES converted in Nuke then saved in .png
of course we use the same OCIOProfile in both software.
As you can see if you drop these image in a web browser or even in ChaosPlayer they don’t look the same at all (From my understanding they should be).
It looks like you’re saving an sRGB encoded (i.e. gamma 2.2) png from nuke, and a linear one from the VFB.
Nuke will show them to be identical on load, and behave identically too for the same load settings (raw or sRGB).
A browser may instead expect it as sRGB, load it linear, and show it brighter as a result.
Bake the gamma in the PNG (in post, as ACES doesn’t have the option for 8/16 bit integer files) and you’ll be fine.
The ACEScg display transform includes the display correction the 2.2 gamma serves under sRGB (so much so you see the render correctly in the VFB on an sRGB display, while the display correction says “OCIO”, not Gamma, nor sRGB. The view transform is responsible for it.).
As mentioned in my initial post, the issue is with non OCIO-managed applications, like a browser.
You could possibly force an additional 2.2 gamma in the VFB by using a curve approximating it as CC, or ofc as a LUT.
Oh okay got it, so if we want to use only the VFB we have to use either a curve or a LUT or we’ll have to do a post render automation to convert and save it.
3dsMax2024 solves this issue with pngs.
in 2023 I would just save to jpeg or some other format that does not carry gamma info. tiff if you need it loseless?
It looks like the image format doesn’t matter and I can’t upgrade to max2024 unfortunetly.
We will propably use OpenColorIO for our web color management for now I just did a script in the ChaosPlayer API to Open/save image as PNG with ACES collapsed it did the trick, and users don’t have extra manipulation to submit images for review
