Chaos Corona Forum
General Category => General CG Discussion => Topic started by: RobSteady on 2016-10-24, 15:11:39
-
My saved render always look a little bit different than the one in the frame buffer (working with Octane & FStorm).
It does not look like a gamma problem, the difference seems too subtle for that - I'm using Gamma 2,2 and when saving the render "automatic" is checked.
The saved image has a little bit less contrast and colors are slightly different; overall it's less punchy.
I've looked several hours on the web but didn't find a solution. Is anyone else having this issue?
"Buffer" is a screenshot from the Frame Buffer in Max.
"Saved" is the saved render.
-
It's color-gamut difference. Framebuffer is non-colormanaged, so what you see is the highest gamut your Display/System outputs (wrongly, since the result is computed for sRGB only).
What you see in Photoshop or opening in managed editor (Windows Photo viewer, but not "Photo" app in Windows10) is sRGB clamped version, the actually correct one. It has no color profile, and in such case, managed applications assume it's sRGB out of convention. Photoshop will ask you if you specify so in Color settings. You should always have those settings set to "Ask when opening/Ask when importing".
If you want to see 100perc. identical image like the one in framebuffer (but this is wrong one, it's over-saturated because of color space shift), you have to assign larger color space when importing to Photoshop (for 10000perc. the same, it's the monitor profile, but AdobeRGB will suffice), and then convert to working-space of you choice right after or after you're finished editing (ideally sRGB for web).
What's your Display ?
You can't find much about it on internet because color-management is non-existant topic in CGI community for some historical reason, and 99perc. people do not even know what it is.
-
If Photoshop is set to use sRGB and assigns this upon opening there should be absolutely no difference. A difference would only occur if the colors were transformed, for example if you convert to a different profile.
If you open both images in PS and assign the same profile to both there should be absolutely no difference, the images should be 100% identical... and they're not.
Were you saving either of the images from PS? Neither of them has a profile assigned so I assume you saved 'Saved.png' from Corona's VFB... Does it still look differently if you save a tif or bmp? If there's still a difference there's something else going on.
-
If Photoshop is set to use sRGB and assigns this upon opening there should be absolutely no difference. A
It only looks the same to people whose displays are close to color gamut of sRGB or their space (Windows) is set to use one, i.e deliberately clamping on colors you can visually see on display.
The difference on highend-displays is night-marish. Like, seriously brutal over-saturation.
-
Thanks for explaining in detail, Juraj.
Using a BenQ BL3200 and an Eizo, both managed by Spyder 4.
What's your workflow? Or, what's the best workflow for this setup?
-
If Photoshop is set to use sRGB and assigns this upon opening there should be absolutely no difference. A
It only looks the same to people whose displays are close to color gamut of sRGB or their space (Windows) is set to use one, i.e deliberately clamping on colors you can visually see on display.
The difference on highend-displays is night-marish. Like, seriously brutal over-saturation.
On the same display - which we can safely assume is the case - there should be no difference.
If a screenshot of Corona's VFB captures, for example, a grey value of 128/128/128 and Corona saves a grey of 130/130/130 then there's something else going on, regardless of profiles, displays etc. Since there IS a difference between the images, it's important to make sure there was no color transform done so we can compare RGB values. If one of these images was, for example, opened in PS and converted to a different profile for viewing prior to saving the PNG then that's probably the reason why they're different. If no color transforms were done then there's something else happening and discussing profiles and displays is pointless.
To find out what's happening here:
1. Make a screenshot of Corona's VFB, save this as bmp or tiff.
2. Save Corona's VFB as bmp or tiff.
3. Open both in PS, and whatever you do with profiles, make sure they're both using the same profile. If you see a difference, chances are Corona's VFB saves out the images differently.
-
On the same display - which we can safely assume is the case - there should be no difference. Discussing profiles and displays is pointless.
If you make screenshot of framebuffer, or any non-color managed application, you will capture the image in the shifted color gamut unless you whole environment is clamped down (and then you had no reason to buy anything other that TN calculator for display).
There could still be another shift depending how his whole environment is set-up, or how he actually did the screenshot.
I've tested 100 times how Corona (or Vray, or VFB+ any renderer embedded in 3dsMax environment without color management) saves and displays color. As long as pure sRGB pipe-line is maintained, Corona preserves color and tone 100perc. correctly. Which is not exactly a win situation, using damn sRGB in 2016.
Here is a screenshot examples: Blue color can actually be brutally more saturated. The assign sRGB is the correct one matching the input colors (in form of values or textures). The framebuffer is what you see on wider-gamut displays, and is also what a screenshot will look like.
Or if you assign higher-gamut spectrum to saved render. Both of them are incorrect of course in terms of input, but consistent if you want PS=Framebuffer to look the same in wide-gamut environment without actual color accuracy.
(https://forum.corona-renderer.com/index.php?action=dlattach;topic=13592.0;attach=53850;image)
(https://forum.corona-renderer.com/index.php?action=dlattach;topic=13592.0;attach=53858;image)
(https://forum.corona-renderer.com/index.php?action=dlattach;topic=13592.0;attach=53852;image)
(https://forum.corona-renderer.com/index.php?action=dlattach;topic=13592.0;attach=53856;image)
If you want your input colors to match output in Corona, you have to assign sRGB only. Only this option currently preserves accuracy.
If you want the same colors as in framebuffer, assign your display profile, and then convert to working space (sRGB for example). You will get your framebuffer look, but inconsistent colors with input.
Please don't share this examples anywhere, it's from non-published project, but one that best illustrates the issue.
-
What's your workflow? Or, what's the best workflow for this setup?
I wanted to write an extended article (you can read some of the stuff on forum, but it's hard to search for) on color-management for color-accuracy in 3d rendering but generally...it's painful.
I'll wait until Ondra integrates some CC (he promised he could do so, it's definitely doable, Maxwell has it).
Short answer: IGNORE framebuffer. Seriously. Or dumb down your whole environment (Windows, Display) to lowest common denominator: sRGB space.
You should finalize colors in Photoshop. Always, and ever.
-
to make this more interesting: Corona actually uses faster color mapping in the frame buffer display than when saving (it is more precise for saving to preserve for example 100% accuracy in 16bit and float image formats). So there might be actually some color shifts even caused by corona. To test this, try copying the image to 3dsmax frame buffer (copy to max button in VFB) - if there is some shift in the appearance as captured by printscreen, then please report it to us ;)
-
Hey guys.
Thanks so much for all the info.
I wanted to ask if this workflow is still valid today.
I got a new Benq monitor that uses its own profile, so when I open the images in Photoshop they appear more desaturated and slightly darker.
What I'm doing now is assigning the Benq profile and then converting to sRGB, as explained above.
However, with 32bit it doesn't seem to work as well as with 8 bit.
Is there anything better now in 2020?
Thanks.
Guido.
-
No, since 2016 nothing has changed. 3dsMax or Corona are still not color managed. Autodesk Maya is color managed ;- ).
Windows 10 is slightly better color managed than it used to, but it's not perfect (it's not even close to where Mac OSX is for example).
-
Hi there.
I am having a similar problem. The scene background image looks brighter (and the colors are shifted too) in the VFB than in Photoshop, where it was prepared. The bitmap is connected to the CoronaTonemapControl map with the Exposure/Tone Mapping/LUT disabled. It shouldn't be color profile related, as I tried saving the image in PS with sRGB profile attached and also without any color profile, it always looks brighter in the VFB.
When I save the render and open it in Photoshop, the background looks exactly like in the Corona VFB (brighter with the shifted colors compared to the original state, so there is actually something happening to the image).
The Gamma in 3DS max is set to 2.2.
Any ideas on why is this happening?
Thanks in advance.
-
with sRGB profile attached and also without any color profile
That's absolutely the same for 3dsMax.
As long as 'everything' has shifted colors, it's color gamut related. If it's only your background (and rest of image is fine), it's your Corona setup.
-
Thank you, Juraj for your swift answer.
You were right, it was the LUT and tone mapping which were changing the visual appearance of my background image. I thought that the CoronaTonemapControl map would avoid that from happening, but now I see that it doesn't work like that. Could anybody explain to me please, what is the right workflow then? Because adding the background image a posteriori in PS won't work for me if there are reflections and refractions involved (interior render with a view to the exterior through a window).
Thanks in advance.
-
ToneMapControl map is bit finicky.. anytime you make framebuffer change, you have to restart the render for it to negate everything.
That is particularly issue with LUTs and when and how you use them in process. Unless you're making an animation you might be better off adding that LUT in Photoshop.
(Btw, reflections/refractions for compositing will be added in upcoming Corona version).
-
ToneMapControl map is bit finicky.. anytime you make framebuffer change, you have to restart the render for it to negate everything.
Yes, I knew that if you change the tone mapping parameters during the render, it would affect the background image. But that's not my case. In my case, that LUT and the tone mapping parameters do affect the background image right from the beginning.
That is particularly issue with LUTs and when and how you use them in process. Unless you're making an animation you might be better off adding that LUT in Photoshop.
Please correct me if I'm wrong, but if I render the image with its background with no LUT or Tone mapping, and apply them afterward in PS, the result would be the same, right? Or you meant that I'd need to apply a mask in PS in order to avoid that from happening?
(Btw, reflections/refractions for compositing will be added in upcoming Corona version).
And what would be the right workflow until then? Could you explain to me please how would you do that? Thank you very much!
-
Can you share a grab of your setup, since the tonemapping and LUT should not affect the background when it is set to disable those for the HDRI in question. Thanks!
-
Here it comes: the original image from PS, the renders without and with the LUT applied and the settings. It's not the interior render I was talking about but I think on this example it's more evident. I reset the corona values to the default (switching to the scanline and back) but it wouldn't actually do anything.
Thank you for your help!
EDIT:
I forgot to mention that the background image is connected to the Direct visibility override slot, I suppose that it doesn't matter, does it?
-
I haven't tested a set up like this, but I believe the Tonemap control should be the last in the chain, and then the Tonemap goes into the Environment or Direct Visibility override. So it would be bitmaps into Corona Select into Tonemap.
As things are at the moment, the Corona Select is still set to be adjusted by the tonemapping, since it isn't going through a tonemap (but, haven't tested with a set up like this :) )
-
@Radim Razzak, did you read the warning in tonemap control texmap? It can't reverse everything. Exposure and most of tone mapping are not the problem, but i never had success in reverting LUTs, it just doesn't work.
-
I haven't tested a set up like this, but I believe the Tonemap control should be the last in the chain, and then the Tonemap goes into the Environment or Direct Visibility override. So it would be bitmaps into Corona Select into Tonemap.
As things are at the moment, the Corona Select is still set to be adjusted by the tonemapping, since it isn't going through a tonemap (but, haven't tested with a set up like this :) )
Thank you Tom, I tried what you suggested but unfortunately, the result is all the same.
-
@Radim Razzak, did you read the warning in tonemap control texmap? It can't reverse everything. Exposure and most of tone mapping are not the problem, but i never had success in reverting LUTs, it just doesn't work.
Yes, I read it. But then the question still stands: what is the correct workflow in the interior setup with a view to the interior through a window? Thank you!
-
I just tested in a simple scene, and it does indeed prevent the Tonemapping (haven't looked at LUTs, just a quick test with exposure) with either set up of tonemaps on the bitmaps through the select, or the select itself through a tonemap (though it's less setting up to just have the Corona Select go into the Tonemap).
As noted, not everything is reversible, which could be what you are running into here, especially with LUTs
-
I just tested in a simple scene, and it does indeed prevent the Tonemapping (haven't looked at LUTs, just a quick test with exposure) with either set up of tonemaps on the bitmaps through the select, or the select itself through a tonemap (though it's less setting up to just have the Corona Select go into the Tonemap).
As noted, not everything is reversible, which could be what you are running into here, especially with LUTs
OK, thanks for the explanation, Tom. Nevertheless, is there any workaround or my best bet is to render without the LUT and applied it afterward in PS to the masked geometry only?
-
Best bet as you say, if that particular LUT is not "reversing" fully, is to do it in post - you could apply the LUT in post, using masks so it isn't applied to the background part; or you could use alpha to just add the background in post, letting you apply the LUT in the VFB.
-
OK, I'll give it a try, let's see if I can solve that in post using masks then. The other approach you mentioned (rendering without the background and using alpha in PS)... I already tried that and unfortunately got several issues with reflection/refraction/translucency (even though I had the "Direct visibility override" checked and black color selected). Anyway, thanks a lot for all your help, Tom.
-
MOVED TO GENERAL DISCUSION
(So, since Corona works internally with WideRGB, is this workflow accurate?:
1- Save the image of VFB in EXR 32bits float without any tonemapping,
2- Open the EXR in Photoshop asignin wideRGB color space and using proof colors in sRGB to visualize it while we are editing the image. (we asign wideRGb because is the raw of corona understandign that corona works with wideRGB, and because photoshop have more colors to prevent banding or clamping while editing). Convert to 16bit compressing highlight and making tone mapping.
3- Convert to sRGB (in perceptual or colorimetric mode) and if we are not happy with the conversion, go back and edit saturation in the areas that gamut warning of proof colors are pointing, to prevent unwanted changes with the conversion.
4- Save the image in a JPG file with sRGB profile.
5-Send it to client.
Is this the correct workflow for 32bits?
Thanks!<)